-----Original Message-----
From: John Vottero [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 12, 2007 1:15 PM
To: W. Craig Trader
Cc: wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Converting Setup project to WiX 3.0
project (Custom Actions)
> -----Original Message-----
> From: W. Craig Trader [mailto:[EMAIL PROTECTED]
> Sent: Thursday, July 12, 2007 12:36 PM
> To: John Vottero
> Cc: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Converting Setup project to WiX 3.0
project
> (Custom Actions)
>
> John Vottero wrote:
> >
> > It would be very easy to write a console app that calls the
C#
> > Installer based code. Once you have that, use the WiX
CAQuietExec
> > custom action to run the console app.
> >
> >
> >
[snip]
> I'm thinking that I need to use the InstallUtil.exe
console-app to run
> my code (since the code expects to be run that way for the old
VS
Setup
> project). Do you have any explicit examples (or pointers to
examples)
> of how to use the QAQuietExec custom action? I'm still pretty
new to
> WiX...
>
It's basically a two step process, set a property with the value
of the
command line like this:
<CustomAction
Id="SetCreateDB"
Property="CreateDB"
Value=""[#JAMSDBAEXE]"
INSTALL/UI=[UILevel]"/>
And then execute that command line with CAQuietExec like this:
<CustomAction
Id="CreateDB"
BinaryKey="wixca"
DllEntry="CAQuietExec"
Execute="deferred"
Impersonate="yes"
Return="check"/>
You'll also have to schedule those two custom actions in the
<InstallExecuteSequence>
The hard part is getting the "Value" right in the first step.
[#JAMSDBAEXE] resolves to the full path of an executable that we
just
installed. I'm not sure how you get the full path to
InstallUtil, I
think with <FileSearch>.
The closest example I've found (http://www.dalun.com/wix/12.07.2006.htm)
looks like this:
<Directory Id='SourceDir' Name='SourceDir'>
<Directory Id='ProgramFilesFolder' Name='PFDir'>
<Directory Id='TestDir' Name='TestDir' LongName='Test
Program'>
<Component Id='MyComponent'
Guid='12345678-1234-1234-1234-123456789012'>
<File Id='tryInstall' Name="try"
LongName='tryInstall.exe' DiskId='1' src='tryInstall.exe' />
</Component>
</Directory>
</Directory>
</Directory>
<InstallExecuteSequence>
<Custom Action='ManagedInstall' After="InstallFinalize" />
</InstallExecuteSequence>
<CustomAction Id="ManagedInstall"
Directory='TestDir'
ExeCommand='"[WindowsFolder]\Microsoft.NET\Framework\v2.0.50727\InstallU
til.exe" /LogToConsole=false tryInstall.exe'
Return='check'>
</CustomAction>
This is (apparently) the equivalent of the following:
cd "C:\Program Files\TestDir"
"C:\Windows\Microsoft.NET\Framework\v2.0.50727\InstallUtil.exe"
/LogToConsole=false tryInstall.exe
Also, you've mentioned rolling back if the DB update fails, I'm
not sure
if that's going to work or not. We treat DB updates as
something that
happens *after* the installation. If our DB update fails, the
DB
updates rollback but, the product install doesn't.
In our case there's a small but finite chance that the database upgrade
may fail. It's much better for our installation to rollback completely
(leaving the old version of the app and all the old data in the old
database schema) than to leave a mix (new software, old database schema)
because the new software is incompatible with the old database schema.
Upgrades have to be done manually at remote locations.
- Craig -
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
