Hi Christopher,
I need multiple instances only of the database.
Cheers,
Daniel
Message: 9
Date: Tue, 22 Jul 2008 05:31:10 -0700 (PDT)
From: Christopher Painter [EMAIL PROTECTED]
Subject: Re: [WiX-users] Multiple Installs without Un-Install?
To: General discussion for Windows Installer XML
Do you have any idea when you might be able to fix this issue? If
priority is low, can you think of a possible workround? I don't really
want to use an admin install.
Regards
Simon Powell
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jason
Dear WiX,
We have a build process for a statistical application which uses WiX to
create a MSI for distribution over Active Directory. This process creates a
files.wxs fragment using tallow.exe, and then parses it through a Perl script
to create a .wxs file which candle.exe and
You could modify the maintenance UI experience to have an option for creating
additional database instances which would then execute your script again but
I'm wondering if it wouldn't be simpler to just write a small application
utility and put it in the start menu to allow a user to perform
Eric Latendresse wrote:
D:\Development\SuiteBuild_Development\BuildProcess.build(209,4):
Failure scanning \C:\Program Files (x86)\Windows Installer XML
v3\bin\Microsoft.
Tools.WindowsInstallerXml.NAntTasks.dll\ for extensions.
The format of the file
Alan Sinclair wrote:
In the past I've found CAB files in the MSI's Binary table, and used
Orca to extract the CAB, then used Windows Explorer to get at the
contents. But the MSIs produced by the WiX toolset on a project I've
inherited don't have a CAB visible anywhere. The binaries are
John Hall wrote:
I have written a tool that auto-generates .wxs files for some parts of
my project - we ship a lot of example scripts. It only handles files and
generates one component per file. The tool maintains a database (well,
an XML file) that lists all the GUIDs ever allocated, and adds
This would be a pretty easy scenario to handle. Check the WXS against the XML
and if a component is missing, throw an error and suggest the puncture
component pattern ( transitive=true condition=false, 0 byte files for storage )
--- On Wed, 7/23/08, Bob Arnson [EMAIL PROTECTED] wrote:
From:
Hi All,
Does anyone know the syntax to register a particular DLL automatically with a
MMC (as a snapin)? I know the DLL works correctly as a snapin - if you register
it manually it works correctly.
Also, how to create a shortcut to this MMC snapin in the start manu?
Kind Regards,
Paul
Paul
Christopher Painter wrote:
This would be a pretty easy scenario to handle. Check the WXS against the
XML and if a component is missing, throw an error and suggest the puncture
component pattern ( transitive=true condition=false, 0 byte files for
storage )
Throw an error isn't the
There's a snap-in CA that Wix offers, but I believe it's for powershell, not
MMC. I couldn't get it to work for me in any evet for the MMC stuff. I
have a managed code MMC 3.0 snap in that I install. You have to make the
registry entries yourself using the snap-in's COM guid. You will also
Cool thanks.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher
Karper
Sent: 23 July 2008 16:37
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Register DLL for use with Microsoft Management Console
There's a
FWIW, I personally would rather manage the process by exception, instead of
*always*.
Chris
On Wed, Jul 23, 2008 at 11:33 AM, Bob Arnson [EMAIL PROTECTED] wrote:
Christopher Painter wrote:
This would be a pretty easy scenario to handle. Check the WXS against
the XML and if a component is
Once again you pedantically pick through my comment without actually offering
anything constructive yourself. Do you feel better now? FWIW it would be nice
if you applied your own comment to programs like HEAT because when I saw run a
heat harvest command and get a JIT exception, that's
Christopher Karper wrote:
There's a snap-in CA that Wix offers, but I believe it's for powershell, not
MMC.
There's an extension in WiX v2 for MMC but nobody's had the occasion to
migrate it to WiX v3...
--
sig://boB
http://joyofsetup.com/
Christopher Karper wrote:
FWIW, I personally would rather manage the process by exception, instead of
*always*.
Yes, some help is usually better than none.g It's all about managing
expectations. If it's possible to automatically generate the original
setups, not being able to generate
I was thinking that the missing file would be the exception. Can you clarify
what you have in mind?
--- On Wed, 7/23/08, Christopher Karper [EMAIL PROTECTED] wrote:
From: Christopher Karper [EMAIL PROTECTED]
Subject: Re: [WiX-users] Merge Module Help
To: General discussion for Windows
Christopher Painter wrote:
Once again you pedantically pick through my comment without actually offering
anything constructive yourself.
Wow, I'm really put in my place, aren't I?
--
sig://boB
http://joyofsetup.com/
-
I should be able to get the fix into this week's build.
The workaround would be to edit the problematic File table keys in the MSI so
that they match the case of the filenames in the cabinet.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Powell, Simon
John Hall wrote:
I have written a tool that auto-generates .wxs files for some parts
of my project - we ship a lot of example scripts. It only handles
files and generates one component per file. The tool maintains a
database (well, an XML file) that lists all the GUIDs ever
allocated,
John Hall wrote:
Ah, we don't do patches, which is why it works for me :)
That's also an option.g That's what ClickThrough does, using early
major upgrades every time. In that case, you don't even need stable IDs.
--
sig://boB
http://joyofsetup.com/
Hey, wait a minute here.
First, Automating Component/@Guids requires a bullet-proof solution. The
side-effects of violating the Component Rules are nasty on two fronts a) once
violated there are no real good ways out (something will get messed up on the
user's machine) and b) you don't usually
ClickThrough also ensures that there is no overlap between the versions.
That's important to remember as well.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, July 23, 2008 09:17
To: General discussion for Windows Installer
Hey David,
It looks like build 2.0.5325.0 (
http://wix.cvs.sourceforge.net/wix/wix2.0/inc/wixver.h?r1=1.35r2=1.36).
This matches the check-in date for the change below.
http://wix.cvs.sourceforge.net/wix/wix2.0/src/tallow/tallow.cs?r1=1.4r2=1.5
1. How do you manage updates to the database in source control? Do people
update the file before building or does the build machine checkout/checkin
automatically? If the latter, what source control systems does it support...
(you can see where I'm going smile/)?
2. How is this better than
IMHO, when you automate part of the process, you take responsibility for the
automation always being correct. To me that means the automation needs to be
able to handle all of the scenarios. Patching is one of the scenarios. Run
the deduction to the end and you see what a difficult problem
1. How do you manage updates to the database in source
control? Do people update the file before building or does
the build machine checkout/checkin automatically? If the
latter, what source control systems does it support... (you
can see where I'm going smile/)?
We use cvsnt as our
The user wants to have the ability to install a database from any remote
machine. Also, additional databases would be installed at some other point
in time (e.g. perhaps 3 months later the user decides they need a second
database).
Ideally, the MSI would un-install itself after it finished
Dear Brian,
Thanks for the info.
David
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Rogers
Sent: 23 July 2008 17:40
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] source and src from
Ideally, the MSI would un-install itself after it finished creating the
database.
This might be off topic, but curiosity got the best of me; given that to be the
case, why would this be in an MSI at all?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
It sounds like your MSI doesn't really install a product but is just a wrapper
for some sort of configuration utility that is designed to create database
instances and quit.
Does that sound right?
--- On Wed, 7/23/08, Daniel Zak [EMAIL PROTECTED] wrote:
From: Daniel Zak [EMAIL PROTECTED]
What feedback? All I saw was a childish quip/troll post.
Personally I'm sick of the component rules and it's associated gotchas. These
are artificial problem caused by an overly complicated design.
Developers want xcopy simplicity. The features are nice from a platform
presevatin
Wix Build - 3.0.4318.0
I'm using the new C# Custom Action Project to build a managed custom action.
When invoking session.GetProductProperty(FOO), an InvalidHandleException is
always thrown. Calls to session.Log() are processes normally and messages do
appear in the install log indicting
Is your custom action deferred? Deferred CAs cannot access properties other
than CustomActionData.
Sources are in the wix3-sources.zip in the release folder of each build. There
is a wix3-pdbs.zip that comes out of every build, but it isn't getting
published -- I think because SF doesn't give
We execute msbuild from nant to build our products and wix installers. The
key to making this integration relatively painless was Szymon Kobalczyk's
Xml Logger for MSBuild. Have a look at
http://geekswithblogs.net/kobush/articles/xmllogger.aspx for details.
Gavin :)
-Original Message-
Great, that worked. I was able to build my installer using my NAnt build
file. However. I need to specify an output path every time the .msi gets
built. Right now the output path is what is set in the protect
properties. The reason I need to separate the build versions is that
ultimately I need to
The custom action is set to immediate, I've also tried commit.
Binary Id=CustomAction1.CA.dll
SourceFile=..\CustomAction1\bin\debug\CustomAction1.CA.dll /
CustomAction Id=MyCustomAction_DATA Property=MyCustomAction Value=foobar
/CustomAction
CustomAction Id=MyCustomAction
Thanks!
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Wednesday, July 23, 2008 7:32 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Where are binaries in MSIs from WiX?
Alan Sinclair wrote:
In
Thank you that's excellent news.
Regards
Simon Powell
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jason
Ginchereau
Sent: 23 July 2008 17:01
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] DTF - Using ExtractFiles
I have been looking for an easy way to set the ALLUSERS property if the
users has admin privs. Could anyone point me in the right direction?
Thank you
There is nothing more important than our customers.
-
This SF.Net
Oh, now I see it. Session.GetProductProperty() is not the API you're looking
for. That one calls into MsiGetProductProperty
(http://msdn.microsoft.com/en-us/library/aa370133.aspx) which is only callable
on a Session obtained from MsiOpenProduct.
To get and set ordinary installation properties,
Can you provide a bit more of the full scenario?
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bir, Steve
Sent: Wednesday, July 23, 2008 12:17
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] An easy way to set the ALLUSERS property if
Is there any other way to get the .cab out of the .msi? (I know about
NTFS file streams, but this must be something else.)
Unfortunately dark gets an exception when extracting the files from our
MSI, and even from the Wix-3.0.4318.0.msi. It's ok without the /x
option. This is dark.exe version
Can these streams be accessed from an extension dll/customaction? It could
give some real convenient features and full installer control that way.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Alan Sinclair
Sent: Wednesday, July 23, 2008 2:44 PM
To:
All binary streams including the hidden streams can be accessed from code via
the _Streams table: http://msdn.microsoft.com/en-us/library/aa372919.aspx
Orca doesn't show it, but the table is queryable with MSI SQL like any other
table.
-Original Message-
From: [EMAIL PROTECTED]
Hmm, am I going to have to access these via a C++ component or homemade
wrapper, or is there an existing .net wrapper?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jason
Ginchereau
Sent: Wednesday, July 23, 2008 2:55 PM
To: General discussion for
Thanks Gavin,
I think I'm very close. It still builds my .msi, but I can't get the
CustomOutput argument to work. I haven't worked with msbuild project
files before so I'm sure my code is wrong. Maybe you can easily see what
I'm doing wrong.
Nant Code:
exec
I'm sure this has been discussed before but I couldn't find anything
searching the mailing list archive. My apologies if you guys have seen
this many times.
I have a relatively small application .msi installer based on WiX
(9.6MB). I distribute it wrapped in a bootstrap executable. Everything
I found KB929467 which discusses this VERY briefly. It simply says To
work around this issue, click Allow in the User Account Control dialog
box to let the repair or remove operation continue. Does anyone have a
real way to work around this?
--Quinton
-Original Message-
From: [EMAIL
Known issue. Stupid bug on their part. You probably could register your
bootstrapper as the uninstaller for your product but that requires a fair bit
of work and can get very tricky to do correctly (read about ARPSYSCOMPONENT on
the internet... some really strange things that need to be
I spoke to three different teams in our organization and they all use an MSI
to install a database. I decided to try this as an alternative to the DOS
batch script I used in the previous version of our software.
On Wed, Jul 23, 2008 at 10:14 AM, John Nannenga [EMAIL PROTECTED]
wrote:
Ideally,
Can anyone tell me how to copy folders(including sub-directories and files)
in one location in the target machine to another location? I do not want to
package these files in msi at build time. these files exist only in the user
computer that I will access during installation. Is there a way to
Eric,
My apologies for leaving that part out. CustomOutputPath needs to be used
to set the value of OutputPath. So your Debug and Release PropertyGroups
end up looking like the following
PropertyGroup Condition= '$(Configuration)' == 'Debug'
OutputPath$(CustomOutputPath)/OutputPath
The only way to do it without having to worry about uninstall and rollback is
to list all the files as File elements. Everything else requires custom code.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sajid1105
Sent: Wednesday, July 23, 2008 18:32
Any particular reason they do this? (I'm not bashing folks or anything like
that; I'm simply genuinely curious what the advantage would be in doing this)
As Chris mentioned, you could modify the maintenance process to support your
needs, leaving the product installed.
If that option doesn't
He emailed me off list. Basically his product doesn't actually install
anything. He's looking at a fake MSI design where he basically just wants to
leverage MSI/WiX MSSQL CA's since that's the way other teams have done it
where he works.
Christopher Painter, Author of Deployment Engineering
Alan Sinclair wrote:
Unfortunately dark gets an exception when extracting the files from our
MSI, and even from the Wix-3.0.4318.0.msi. It's ok without the /x
option. This is dark.exe version 2.0.5805.0 (from both WiX 2 and WiX 3
(not the latest WiX 3))
If all you're interested in is the
57 matches
Mail list logo
