[WiX-users] Extracting a certificate from binary table
Hi, I'm placing a .pfx certificate in the binary table and wish to retrieve it in my deferred custom action dll. From what I read on the forum, I see that this can be achieved by reading the certificate using immediate custom action, write it to custom action data(or to a temporary file, which I don't prefer) and then call the deferred custom action that can use this data. Can someone please help me with the following doubts: 1. What APIs should I be looking at, to write to custom action data in an immediate custom action? 2. The certificate is purely binary data and all the APIs return strings. So, I'm afraid that I'd loose some data if there is a NULL in the binary data. How can I handle this situation? 3. I have a URI that should also be placed in the custom action data. So, how can I append the certificate's binary stream to the custom action data(which contains the URI already)? Thanks, Pratapa. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Specify source of exe in ServiceInstall
I actually struggled a bit with this as well, I discovered that the easiest way to do that is: Component Id=NameServiceComponent Guid=* DiskId=1 File Id=ServiceId Name=FileName Source=FilePath / ServiceInstall Id=ServiceInstallId DisplayName=ServiceDisplayName Name=ServiceName Description= ErrorControl=normal Start=auto Type=ownProcess Vital=yes Account=NT AUTHORITY\NetworkService Interactive=no/ /Component Apparently the ServiceInstall node references the file node directly above it. Thomas Due -Original Message- From: Anupama A [mailto:anupama...@gmail.com] Sent: 26. januar 2009 08:24 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Specify source of exe in ServiceInstall I am trying to write an installer for a Windows Service. Depending on the deploy environment, I set a property called [ApplicationDirectory]. I have a separate component which copies all files from [ProgramFilesFolder] to [ApplicationDirectory] depending on what is dynamically set. And then the service install from the new location [ApplicationDirectory] should happen. In the below statement how do I specify the Service1.exe is in the [AppDirectory] path: ServiceInstall Id=Service1Installer Name=Service1.exe Type=ownProcess Start=auto Vital=yes ErrorControl=normal/ServiceInstall Wrapping this within a File element with the source pointing to the exe from the new location will fail at compile time as [AppDirectory] will not be set then. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CustomAction accessing CustomTable
Just if someone else is reading this thread. I solved the issue by an immediate customaction scheduled in the ui just after writing to the customtable. This custom action creates the CustomActionData class and saves it to a public property which can be used to schedule the actions in after InstallFiles. jballe wrote: Ok so I probably have to get around this issue by setting some properties or similar. I will give it a try. Thank you for your assistance. Rob Mensching-2 wrote: I do have CustomActions that do this sort of thing but I don't use DTF. Somewhere there is probably a bug. -- View this message in context: http://www.nabble.com/CustomAction-accessing-CustomTable-tp21543515p21662327.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] BootStrapper log question
I added SQL 2008 to BootStrapper and it works on new Install. But when I try to
install on a system that already has SQL 2008 installed, it tries to re-install
again, I can't find where the problem might be Can someone help?
This is the code in package.xml - I have added registry check for SQL Server
installed.
InstallChecks
RegistryFileCheck Property=DefaultSQLInstalled
Key=HKLM\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\CurrentVersion
Value=CurrentVersion/
/InstallChecks
Commands Reboot=Defer
!-- Defines a new installation (x86) --
Command PackageFile=SQLEXPR32_x86_ENU.EXE
Arguments='/q /hideconsole /action=Install
/features=SQL /INSTANCENAME=MSSQLSERVER /TCPENABLED=1 /SECURITYMODE=SQL
/SAPWD=w...@13456789 /enableranu=1 /sqlsvcaccount= NT Authority\System
/SQLSYSADMINACCOUNTS=BUILTIN\ADMINISTRATORS /skiprules=RebootRequiredCheck'
EstimatedInstalledBytes=22500
EstimatedInstallSeconds=420
InstallConditions
BypassIf Property=DefaultSQLInstalled
Compare=ValueExists Value=90/
BypassIf Property=ProcessorArchitecture
Compare=ValueNotEqualTo Value=Intel/
!--BypassIf Property=SQLExpressInstalled
Compare=ValueNotEqualTo Value=0/--
FailIf Property=Version9x Compare=ValueExists
String=InvalidPlatformXP/
FailIf Property=VersionNT
Compare=VersionLessThan Value=5.1.2 String=InvalidPlatformXP/
FailIf Property=VersionNT
Compare=VersionEqualTo Value=5.2.0 String=InvalidPlatform2K3/
FailIf Property=VersionNT
Compare=VersionEqualTo Value=5.2.1 String=InvalidPlatform2K3/
FailIf Property=AdminUser Compare=ValueEqualTo
Value=false String=AdminRequired/
/InstallConditions
ExitCodes
ExitCode Value=0 Result=Success/
ExitCode Value=1641 Result=SuccessReboot/
ExitCode Value=3010 Result=SuccessReboot/
!-- 0x84BE0BC2 (1214,3010) --
ExitCode Value=-2067919934 Result=FailReboot/
!-- 0x84C10BC2 (1217,3010) --
ExitCode Value=-2067723326 Result=FailReboot/
!-- 0x84BE0007 (1214,7) --
ExitCode Value=-2067922937 Result=Fail
String=AdminRequired/
!-- 0x84C4001F (1220,31) --
ExitCode Value=-2067529697 Result=Fail
String=AdminRequired/
!-- 0x84BE0001 (1214,1)--
ExitCode Value=-2067922943 Result=Fail
String=InvalidPlatformOSServicePacks/
!-- 0x84C4000B (1220,11) --
ExitCode Value=-2067529717 Result=Fail
String=AnotherInstanceRunning/
!-- 0x84BE01F8 (1214,504) --
ExitCode Value=-2067922440 Result=Fail
String=BetaComponentsFailure/
!-- 0x84BE01FA (1214,506) --
ExitCode Value=-2067922438 Result=Fail
String=BetaComponentsFailure/
!-- 0x84BE0202 (1214,514) --
ExitCode Value=-2067922430 Result=Fail
String=InvalidPlatformArchitecture/
!-- 0x84BE0203 (1214,515) --
ExitCode Value=-2067922429 Result=Fail
String=InvalidPlatformArchitecture/
ExitCode Value=216 Result=Fail
String=InvalidPlatformArchitecture/
DefaultExitCode Result=Fail
FormatMessageFromSystem=true String=GeneralFailure /
/ExitCodes
/Command
===
== This is the log from
install.log=
Running checks for package 'SQL Server 2008 Express Edition', phase BuildList
Running external check with command
'D:\DOCUME~1\APERRE~1\LOCALS~1\Temp\VSD713.tmp\SQLExpress2008\SqlExpressChk.exe'
and parameters ''
Process exited with code 9023073
Setting value '9023073 {int}' for property 'SQLExpressInstalled'
Reading value 'CurrentVersion' of registry key
'HKLM\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\CurrentVersion'
Read string value '9.00.3042.00'
Running check with folder '' and file '9.00.3042.00'
Unable to find directory ''
Not setting value for property 'DefaultSQLInstalled'
The following properties have been set for package 'SQL Server 2008 Express
Edition':
Property: [SQLExpressInstalled] = 9023073 {int}
Running checks for command 'SQLExpress2008\SQLEXPR32_x86_ENU.EXE'
Result of running operator 'ValueExists' on property 'DefaultSQLInstalled':
[WiX-users] Dealing with Components with Only Non-Versioned Files
I have a few components that only contain non-versioned files (i.e. message files, fonts). Currently I am using a core DLL that I install as the companion file for the files in those components. However, this means that I don't have a keypath for these components. I'm not sure if this is a problem or not, and if so, any suggestions? Currently I am just doing a post-build step to insert a keypath back into this component. Any thoughts on better practice? Thanks -- View this message in context: http://n2.nabble.com/Dealing-with-Components-with-Only-Non-Versioned-Files-tp2218510p2218510.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Specify source of exe in ServiceInstall
Thanks, I am aware of this. The point I am trying to make is that in my case, the source of the File element above the ServiceInstall is not clear at compile time. As I mentioned, I set a property called [ApplicationDirectory] during execution and this would hold the path that should be set to File element's source * Re: [WiX-users] Specify source of exe in ServiceInstall* From: Thomas Due thomas@sc... - 2009-01-26 08:12 I actually struggled a bit with this as well, I discovered that the easiest way to do that is: Component Id=NameServiceComponent Guid=* DiskId=1 File Id=ServiceId Name=FileName Source=FilePath / ServiceInstall Id=ServiceInstallId DisplayName=ServiceDisplayName Name=ServiceName Description= ErrorControl=normal Start=auto Type=ownProcess Vital=yes Account=NT AUTHORITY\NetworkService Interactive=no/ /Component Apparently the ServiceInstall node references the file node directly above it. Thomas Due -Original Message- From: Anupama A [mailto:anupama...@gm...] Sent: 26. januar 2009 08:24 To: wix-us...@li... Subject: [WiX-users] Specify source of exe in ServiceInstall I am trying to write an installer for a Windows Service. Depending on the deploy environment, I set a property called [ApplicationDirectory]. I have a separate component which copies all files from [ProgramFilesFolder] to [ApplicationDirectory] depending on what is dynamically set. And then the service install from the new location [ApplicationDirectory] should happen. In the below statement how do I specify the Service1.exe is in the [AppDirectory] path: ServiceInstall Id=Service1Installer Name=Service1.exe Type=ownProcess Start=auto Vital=yes ErrorControl=normal/ServiceInstall Wrapping this within a File element with the source pointing to the exe from the new location will fail at compile time as [AppDirectory] will not be set then. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Detecting WSE 3.0
Hi, Do you know how to detect if WSE 3.0 is installed ? There are plenty of product codes for WSE 3.0, so a simple registry search to Windows\Uninstall does not help. Thanks, Eitan -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] BootStrapper log question
I was able to resolve this issue.
Thanks,
Arun Perregattur
-Original Message-
From: Arun Perregatturv [mailto:aperregatt...@napcosecurity.com]
Sent: Monday, January 26, 2009 9:15 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] BootStrapper log question
I added SQL 2008 to BootStrapper and it works on new Install. But when I try to
install on a system that already has SQL 2008 installed, it tries to re-install
again, I can't find where the problem might be Can someone help?
This is the code in package.xml - I have added registry check for SQL Server
installed.
InstallChecks
RegistryFileCheck Property=DefaultSQLInstalled
Key=HKLM\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\CurrentVersion
Value=CurrentVersion/
/InstallChecks
Commands Reboot=Defer
!-- Defines a new installation (x86) --
Command PackageFile=SQLEXPR32_x86_ENU.EXE
Arguments='/q /hideconsole /action=Install
/features=SQL /INSTANCENAME=MSSQLSERVER /TCPENABLED=1 /SECURITYMODE=SQL
/SAPWD=w...@13456789 /enableranu=1 /sqlsvcaccount= NT Authority\System
/SQLSYSADMINACCOUNTS=BUILTIN\ADMINISTRATORS /skiprules=RebootRequiredCheck'
EstimatedInstalledBytes=22500
EstimatedInstallSeconds=420
InstallConditions
BypassIf Property=DefaultSQLInstalled
Compare=ValueExists Value=90/
BypassIf Property=ProcessorArchitecture
Compare=ValueNotEqualTo Value=Intel/
!--BypassIf Property=SQLExpressInstalled
Compare=ValueNotEqualTo Value=0/--
FailIf Property=Version9x Compare=ValueExists
String=InvalidPlatformXP/
FailIf Property=VersionNT
Compare=VersionLessThan Value=5.1.2 String=InvalidPlatformXP/
FailIf Property=VersionNT
Compare=VersionEqualTo Value=5.2.0 String=InvalidPlatform2K3/
FailIf Property=VersionNT
Compare=VersionEqualTo Value=5.2.1 String=InvalidPlatform2K3/
FailIf Property=AdminUser Compare=ValueEqualTo
Value=false String=AdminRequired/
/InstallConditions
ExitCodes
ExitCode Value=0 Result=Success/
ExitCode Value=1641 Result=SuccessReboot/
ExitCode Value=3010 Result=SuccessReboot/
!-- 0x84BE0BC2 (1214,3010) --
ExitCode Value=-2067919934 Result=FailReboot/
!-- 0x84C10BC2 (1217,3010) --
ExitCode Value=-2067723326 Result=FailReboot/
!-- 0x84BE0007 (1214,7) --
ExitCode Value=-2067922937 Result=Fail
String=AdminRequired/
!-- 0x84C4001F (1220,31) --
ExitCode Value=-2067529697 Result=Fail
String=AdminRequired/
!-- 0x84BE0001 (1214,1)--
ExitCode Value=-2067922943 Result=Fail
String=InvalidPlatformOSServicePacks/
!-- 0x84C4000B (1220,11) --
ExitCode Value=-2067529717 Result=Fail
String=AnotherInstanceRunning/
!-- 0x84BE01F8 (1214,504) --
ExitCode Value=-2067922440 Result=Fail
String=BetaComponentsFailure/
!-- 0x84BE01FA (1214,506) --
ExitCode Value=-2067922438 Result=Fail
String=BetaComponentsFailure/
!-- 0x84BE0202 (1214,514) --
ExitCode Value=-2067922430 Result=Fail
String=InvalidPlatformArchitecture/
!-- 0x84BE0203 (1214,515) --
ExitCode Value=-2067922429 Result=Fail
String=InvalidPlatformArchitecture/
ExitCode Value=216 Result=Fail
String=InvalidPlatformArchitecture/
DefaultExitCode Result=Fail
FormatMessageFromSystem=true String=GeneralFailure /
/ExitCodes
/Command
===
== This is the log from
install.log=
Running checks for package 'SQL Server 2008 Express Edition', phase BuildList
Running external check with command
'D:\DOCUME~1\APERRE~1\LOCALS~1\Temp\VSD713.tmp\SQLExpress2008\SqlExpressChk.exe'
and parameters ''
Process exited with code 9023073
Setting value '9023073 {int}' for property 'SQLExpressInstalled'
Reading value 'CurrentVersion' of registry key
'HKLM\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer\CurrentVersion'
Read string value '9.00.3042.00'
Running check with folder '' and file '9.00.3042.00'
Unable to find directory ''
Not setting value for property
[WiX-users] Recursive Directory Import
Hi, how can you include a directory with all sub directories? I use WiX3.0 Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Create Database does NOT fail even though there is a database with the same name
Hi, I have a database element which should install a database and abort if the installation fails. The component is as below. Component Id=Database Guid=857106E0-F1EC-42FE-965E-A098EBB06BD1 Permanent=no NeverOverwrite=yes File Id=DatabaseFile Name=$(var.DemoDatabaseBackupFileName) DiskId=1 Source=TempSrc\$(var.DemoDatabaseBackupFileName) KeyPath=yes / sql:SqlDatabase Id=CreateDemoDatabase Database=$(var.DatabaseName) Server=[ComputerName] Instance=[INSTANCENAME] CreateOnInstall=yes CreateOnReinstall=yes ConfirmOverwrite=no DropOnUninstall=no ContinueOnError=no DropOnInstall=no DropOnReinstall=no /sql:SqlDatabase /Component To test, I already have a database with the same name on the server. So I would expect this action to fail and stop the setup. I looked around the documentation but couldn’t find anything on the behaviour so I’m not sure if this is a bug or not. In the verbose log file I get the below message on CreateDatabase, the Return value is 1. Shouldn’t the installer fail complaining about the database already exists? MSI (s) (64!18) [17:52:46:076]: PROPERTY CHANGE: Adding CreateDatabase property. Its value is 'CreateDemoDatabaseERDINA-WSDemo Database NAV (6-0)97100'. MSI (s) (64!18) [17:52:46:076]: Creating MSIHANDLE (887) of type 790531 for thread 2328 MSI (s) (64!18) [17:52:46:077]: Closing MSIHANDLE (887) of type 790531 for thread 2328 MSI (s) (64!18) [17:52:46:077]: Doing action: CreateDatabase Action start 17:52:46: CreateDatabase. Action ended 17:52:46: CreateDatabase. Return value 1. MSI (s) (64!18) [17:52:46:080]: Closing MSIHANDLE (871) of type 790541 for thread 2328 MSI (s) (64:F0) [17:52:46:081]: Closing MSIHANDLE (870) of type 790542 for thread 5576 Action ended 17:52:46: InstallSqlData. Return value 1. Am I missing something here, version of WIX is 3.0.4805.0? Thx, /E -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Override 'Large Package' in WiX
WiX sets File Sequence and Media LastSequence to i4 to enable creation of large msi packages. Is there anyway to force candle/light to use the standard i2 for these columns? Exporting and importing idt files is clumsy. I would like to use WiX to build an updated database for use with patching a legacy product. TIA, Jim -- View this message in context: http://n2.nabble.com/Override-%27Large-Package%27-in-WiX-tp2219802p2219802.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Override 'Large Package' in WiX
light.exe in WiX v2 has switch to do that. -Original Message- From: Jim Stout [mailto:jimst...@gmail.com] Sent: Monday, January 26, 2009 10:50 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Override 'Large Package' in WiX WiX sets File Sequence and Media LastSequence to i4 to enable creation of large msi packages. Is there anyway to force candle/light to use the standard i2 for these columns? Exporting and importing idt files is clumsy. I would like to use WiX to build an updated database for use with patching a legacy product. TIA, Jim -- View this message in context: http://n2.nabble.com/Override-%27Large-Package%27-in-WiX-tp2219802p2219802.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Getting a DARK1024 error
I'm using Visual Studio 6.0 Installer to create a test msi package and I'm getting the following error when using DARK.EXE to convert it. dark.exe : warning DARK1024 : Action 'UpdateResources' in sequence 'InstallExecuteSequence' is not a custom action, dialog, supported standard action, or known special action so this action is being left out. Using WiX 2.0.4611.0 Thanks in advance. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] ServiceInstall as deferred action
How can i include ServiceInstall in a deferred custom action? I want it to be deferred as i'll construct the exe path only during execution. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Prevent 32 bit MSI install on 64 bit OS
Before I resort to a CA that tries to call IsWow64Process(), is there any other simple way to bail out if attempting to run a 32 bit installer on a Win64 OS? (My product requires the 64 bit installer on a 64 bit OS) Thanks, Jeremy -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Getting a DARK1024 error
Not an error, a warning. It tells you exactly what it is doing. -Original Message- From: MacDiarmid, James D [mailto:james.macdiar...@eds.com] Sent: Monday, January 26, 2009 12:24 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Getting a DARK1024 error I'm using Visual Studio 6.0 Installer to create a test msi package and I'm getting the following error when using DARK.EXE to convert it. dark.exe : warning DARK1024 : Action 'UpdateResources' in sequence 'InstallExecuteSequence' is not a custom action, dialog, supported standard action, or known special action so this action is being left out. Using WiX 2.0.4611.0 Thanks in advance. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Properties in WiX
Hi, I am new to WiX and I am trying to understand some basics. Regarding 'Properties' in WiX: 1. If there is any hardcode value for a Property in a WiX file, when we compile this Wix file...is this value going to be stored in the MSI database ? 2.If there are any public properties and If I supply values to these public properties during compilation phase, would these values be stored in the MSI database? 3.If I supply values to public properties at runtime using UI, would these values also be stored in the MSI database or do I need to do any custom steps to store them? Thanks, Kiran -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CustomAction accessing CustomTable
In article 21662327.p...@talk.nabble.com, jballe j...@visionpeople.dk writes: I solved the issue by an immediate customaction scheduled in the ui just after writing to the customtable. This custom action creates the CustomActionData class and saves it to a public property which can be used to schedule the actions in after InstallFiles. I haven't really been following this thread, but this is the standard way of communicating custom table data to deferred CAs. The MSI SDK documentation provides an example of doing this for creating user accounts. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Prevent 32 bit MSI install on 64 bit OS
I think a LaunchCondition with the property Msix64 will do what you want. -Ari -Original Message- From: Jeremy Lew [mailto:j...@liquidmachines.com] Sent: Monday, January 26, 2009 2:49 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Prevent 32 bit MSI install on 64 bit OS Before I resort to a CA that tries to call IsWow64Process(), is there any other simple way to bail out if attempting to run a 32 bit installer on a Win64 OS? (My product requires the 64 bit installer on a 64 bit OS) Thanks, Jeremy -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating SQL Database with WiX v3
I tried to restore the database from a backup file during the initial install and am getting this error below. Is there WiX log or something where I can get some more info on how to debug this? Below is my code and I think this should work. Anyone have any ideas? Thanks in advance for you help. Component Id=SuiteDatabaseComponent Guid=d6e96011-3252-4e85-80b5-b1ff64045e88 File Id=DatabaseBackup Name=SuiteBlank.bak Source=..\..\Database\Backups\SuiteBlank.bak / CreateFolder/ !-- installs database -- sql:SqlDatabase Id=db1 Server=[SQLSERVER] Instance=[SQLINSTANCE] Database=Suite CreateOnInstall=yes ConfirmOverwrite=yes DropOnUninstall=no User=SQLUser !-- define where the database files are saved -- sql:SqlFileSpec Id=mdf Name=Suite_Data Filename=[DATABASEDIR]Suite_Data.mdf Size=2MB GrowthSize=2MB/ sql:SqlLogFileSpec Id=ldf Name=Suite_Log Filename=[DATABASEDIR]Suite_Log.ldf/ /sql:SqlDatabase sql:SqlString Id='RestoreDB' SqlDb='db1' ContinueOnError='no' ExecuteOnInstall='yes' SQL=RESTORE DATABASE Suite FROM DISK = '[DATABASEDIR]SuiteBlank.bak' WITH MOVE 'Suite_Data' TO '[DATABASEDIR]Suite_Data.mdf', MOVE 'Suite_Log' TO '[DATABASEDIR]Suite_Log.ldf',REPLACE/ /Component Error -2147217900: failed to execute SQL string, error detail: RESTORE DATABASE is terminating abnormally., SQL key: RestoreDB SQL string: RESTORE DATABASE Suite FROM DISK = 'G:\Database\SuiteBlank.bak' WITH MOVE 'Suite_Data' TO G:\ ...\Suite_Log.ldf',REPLACE Eric Latendresse -Original Message- From: David Reed [mailto:david.r...@microsoft.com] Sent: Friday, January 23, 2009 11:44 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating SQL Database with WiX v3 It really depends on what those 9k scripts are doing. If your scripts are a raft of INSERT statements or other transactions, then you can probably switch to CSVs and bulk load (much faster), which is what we do with AdventureWorks now for SQL Server 2008 samples. The WiX3 code for ours is checked into CodePlex here along with the MSBuild scripts, etc: http://www.codeplex.com/SqlServerSamples/SourceControl/ListDownloadableC ommits.aspx In our experience with AdventureWorks' installers, switching to a backup/restore is likely to bloat the size of your installer quite a bit because the BAK files aren't nearly as compressible (if at all) as script files are... From: Eric Latendresse [elatendre...@optimum-solutions.com] Sent: Friday, January 23, 2009 13:10 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Creating SQL Database with WiX v3 I am creating a SQL database with my installer. Right now I have approximately 9000 scripts to be run after the database is created. This is taking around 20mins for the install to complete. Is there anything I can do to speed this process up? I thought about running a single script to restore the database from a backup file of the database, but thought I'd ask if there was a better way. Eric Latendresse -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CustomAction accessing CustomTable
In article 1233004461998-2220704.p...@n2.nabble.com, jballe j...@visionpeople.dk writes: Richard-45 wrote: I haven't really been following this thread, but this is the standard way of communicating custom table data to deferred CAs. The MSI SDK documentation provides an example of doing this for creating user accounts. Thank you for answering. You say that I should not be able to access the Custom Table in an immediate custom action scheduled after InstallFiles? I didn't say anything about immediate CAs. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ServiceInstall as deferred action
ServiceInstall is already deferred. See Suggested InstallExecuteSequence (http://msdn.microsoft.com/en-us/library/aa372038(VS.85).aspx) - InstallServices standard action is scheduled after InstallInitialize. I am not sure what you mean by constructing exe path during execution. ServiceInstall will install the KeyPath file of the component where ServiceInstall is located. Also, the KeyPath file of the component must be an executable file for the service. See description of Component_ column in ServiceInstall table (http://msdn.microsoft.com/en-us/library/aa371637(VS.85).aspx). Alex -Original Message- From: Anupama A [mailto:anupama...@gmail.com] Sent: Monday, January 26, 2009 12:34 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] ServiceInstall as deferred action How can i include ServiceInstall in a deferred custom action? I want it to be deferred as i'll construct the exe path only during execution. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Create Database does NOT fail even though there is a database with the same name
Not sure that is a failure case. It would need to succeed in the case where a repair comes a long and wants to put the database back. If it is already there, no work done. Very similar to the way the Windows Installer behaves for all other resources. -Original Message- From: Erdinch Akbasli [mailto:erd...@microsoft.com] Sent: Monday, January 26, 2009 09:31 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Create Database does NOT fail even though there is a database with the same name Hi, I have a database element which should install a database and abort if the installation fails. The component is as below. Component Id=Database Guid=857106E0-F1EC-42FE-965E-A098EBB06BD1 Permanent=no NeverOverwrite=yes File Id=DatabaseFile Name=$(var.DemoDatabaseBackupFileName) DiskId=1 Source=TempSrc\$(var.DemoDatabaseBackupFileName) KeyPath=yes / sql:SqlDatabase Id=CreateDemoDatabase Database=$(var.DatabaseName) Server=[ComputerName] Instance=[INSTANCENAME] CreateOnInstall=yes CreateOnReinstall=yes ConfirmOverwrite=no DropOnUninstall=no ContinueOnError=no DropOnInstall=no DropOnReinstall=no /sql:SqlDatabase /Component To test, I already have a database with the same name on the server. So I would expect this action to fail and stop the setup. I looked around the documentation but couldn’t find anything on the behaviour so I’m not sure if this is a bug or not. In the verbose log file I get the below message on CreateDatabase, the Return value is 1. Shouldn’t the installer fail complaining about the database already exists? MSI (s) (64!18) [17:52:46:076]: PROPERTY CHANGE: Adding CreateDatabase property. Its value is 'CreateDemoDatabaseERDINA-WSDemo Database NAV (6-0)97100'. MSI (s) (64!18) [17:52:46:076]: Creating MSIHANDLE (887) of type 790531 for thread 2328 MSI (s) (64!18) [17:52:46:077]: Closing MSIHANDLE (887) of type 790531 for thread 2328 MSI (s) (64!18) [17:52:46:077]: Doing action: CreateDatabase Action start 17:52:46: CreateDatabase. Action ended 17:52:46: CreateDatabase. Return value 1. MSI (s) (64!18) [17:52:46:080]: Closing MSIHANDLE (871) of type 790541 for thread 2328 MSI (s) (64:F0) [17:52:46:081]: Closing MSIHANDLE (870) of type 790542 for thread 5576 Action ended 17:52:46: InstallSqlData. Return value 1. Am I missing something here, version of WIX is 3.0.4805.0? Thx, /E -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Recursive Directory Import
heat.exe or one of the other tools out there generates a .wxs file. -Original Message- From: Thomas Guettler [mailto:h...@tbz-pariv.de] Sent: Monday, January 26, 2009 07:44 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Recursive Directory Import Hi, how can you include a directory with all sub directories? I use WiX3.0 Thomas -- Thomas Guettler, http://www.thomas-guettler.de/ E-Mail: guettli (*) thomas-guettler + de -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] LGHT001 error from Light I can't seem to get rid of
Ug, bug. Can you file this on SourceForge? Should be able to get a fix next week. Be sure to put it under the v3.0 Group and light Category. -Original Message- From: John Cooper (Volt) [mailto:a-jc...@microsoft.com] Sent: Monday, January 26, 2009 09:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] LGHT001 error from Light I can't seem to get rid of On this run, I was using 3.0.4707.0. Thinking that the latest version might fix the problem, I've installed 3.0.4923, but I get the same error. So, then I tried offload things to lit. If if leave off the -bf flag on lit, it compiles everything into wixlib's just fine (and then I get the aforementioned error in light.exe). However, if I add the -bf flag to bind the binaries into the wixlib's, I get: Microsoft (R) Windows Installer Xml Library Tool version 3.0.4923.0 Copyright (C) Microsoft Corporation. All rights reserved. lit.exe : error LIT0001 : Unable to find an entry point named 'CreateCabCancel' in DLL 'winterop.dll'. Exception Type: System.EntryPointNotFoundException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.Cab.Interop.NativeMethods.CreateCabCancel(IntPtr contextHandle) at Microsoft.Tools.WindowsInstallerXml.Cab.WixCreateCab.Dispose() at Microsoft.Tools.WindowsInstallerXml.Library.Save(String path, BinderFileManager binderFileManager, WixVariableResolver wixVariableResolver) at Microsoft.Tools.WindowsInstallerXml.Tools.Lit.Run(String[] args) -- John M. Cooper -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Saturday, January 24, 2009 8:03 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] LGHT001 error from Light I can't seem to get rid of What vesion of the WiX toolset are you using? -Original Message- From: John Cooper (Volt) [mailto:a-jc...@microsoft.com] Sent: Friday, January 23, 2009 15:31 To: wix-users@lists.sourceforge.net Subject: [WiX-users] LGHT001 error from Light I can't seem to get rid of I can't seem to get rid of this error on my server builds: 1/23/2009 2:57:48 PMCMD: E:\bt\512100\build\setup\tools\wix\3.0.4707.0\binaries\light.exe -ct 16 -v -pedantic -ext WixUIExtension -ext WixNetFxExtension -cultures:en-us -loc E:\bt\512100\build\setup\tools\wix\3.0.4707.0\sources\loc\WixUI_en-us.wxl -loc E:\bt\512100\build\setup\PMX\Loc\locstrings_en-us.wxl -out E:\bt\512100\Build\Setup\Kit\Bld1323\beta\disk1\Microsoft Windows Mobile PMX Adaption Kit.msi E:\bt\512100\Build\Setup\Kit\Bld1323\beta\build\*.wixobj 1/23/2009 2:57:48 PMMicrosoft (R) Windows Installer Xml Linker version 3.0.4707.0 1/23/2009 2:57:48 PMCopyright (C) Microsoft Corporation. All rights reserved. 1/23/2009 2:57:48 PM 1/23/2009 2:59:40 PMlight.exe : error LGHT0001 : Exception of type 'System.OutOfMemoryException' was thrown. 1/23/2009 2:59:40 PM 1/23/2009 2:59:40 PMException Type: System.OutOfMemoryException 1/23/2009 2:59:40 PM 1/23/2009 2:59:40 PMStack Trace: 1/23/2009 2:59:40 PM at System.String.GetStringForStringBuilder(String value, Int32 startIndex, Int32 length, Int32 capacity) 1/23/2009 2:59:40 PM at System.Text.StringBuilder.GetNewString(String currentString, Int32 requiredLength) 1/23/2009 2:59:40 PM at System.Text.StringBuilder.Append(String value) 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.Row.GetPrimaryKey(Char delimiter) 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.Symbol.get_Name() 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.SymbolCollection.Add(Symbol symbol) 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.Section.GetSymbols(IMessageHandler messageHandler) 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.SectionCollection.FindEntrySectionAndLoadSymbols(Boolean allowIdenticalRows, IMessageHandler messageHandler, OutputType expectedOutputType, Section entrySection, SymbolCollection allSymbols) 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.Linker.Link(SectionCollection sections, ArrayList transforms, OutputType expectedOutputType) 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args) 1/23/2009 2:59:40 PMBinder temporary directory located at 'C:\WINDOWS\TEMP\va_sd7cx'. 1/23/2009 2:59:40 PMValidator temporary directory located at 'C:\WINDOWS\TEMP\nonrjueh'. Curiously, it does not show up on Vista when I build on my workstation. -- John M. Cooper Volt at Microsoft -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Specify source of exe in ServiceInstall
ServiceInstall in MSI doesn't support that scenario. MSI SDK says ServiceInstall always points at the key path of the Component. -Original Message- From: Anupama A [mailto:anupama...@gmail.com] Sent: Monday, January 26, 2009 07:32 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Specify source of exe in ServiceInstall Thanks, I am aware of this. The point I am trying to make is that in my case, the source of the File element above the ServiceInstall is not clear at compile time. As I mentioned, I set a property called [ApplicationDirectory] during execution and this would hold the path that should be set to File element's source * Re: [WiX-users] Specify source of exe in ServiceInstall* From: Thomas Due thomas@sc... - 2009-01-26 08:12 I actually struggled a bit with this as well, I discovered that the easiest way to do that is: Component Id=NameServiceComponent Guid=* DiskId=1 File Id=ServiceId Name=FileName Source=FilePath / ServiceInstall Id=ServiceInstallId DisplayName=ServiceDisplayName Name=ServiceName Description= ErrorControl=normal Start=auto Type=ownProcess Vital=yes Account=NT AUTHORITY\NetworkService Interactive=no/ /Component Apparently the ServiceInstall node references the file node directly above it. Thomas Due -Original Message- From: Anupama A [mailto:anupama...@gm...] Sent: 26. januar 2009 08:24 To: wix-us...@li... Subject: [WiX-users] Specify source of exe in ServiceInstall I am trying to write an installer for a Windows Service. Depending on the deploy environment, I set a property called [ApplicationDirectory]. I have a separate component which copies all files from [ProgramFilesFolder] to [ApplicationDirectory] depending on what is dynamically set. And then the service install from the new location [ApplicationDirectory] should happen. In the below statement how do I specify the Service1.exe is in the [AppDirectory] path: ServiceInstall Id=Service1Installer Name=Service1.exe Type=ownProcess Start=auto Vital=yes ErrorControl=normal/ServiceInstall Wrapping this within a File element with the source pointing to the exe from the new location will fail at compile time as [AppDirectory] will not be set then. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Properties in WiX
1. Yes. You can open the MSI with Orca and look at the Property table. 2. No. 3. Same as 2. There are a few discussion about how to do this in the archives. -Original Message- From: Kiran Challa [mailto:kicha...@microsoft.com] Sent: Monday, January 26, 2009 12:56 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Properties in WiX Hi, I am new to WiX and I am trying to understand some basics. Regarding 'Properties' in WiX: 1. If there is any hardcode value for a Property in a WiX file, when we compile this Wix file...is this value going to be stored in the MSI database ? 2.If there are any public properties and If I supply values to these public properties during compilation phase, would these values be stored in the MSI database? 3.If I supply values to public properties at runtime using UI, would these values also be stored in the MSI database or do I need to do any custom steps to store them? Thanks, Kiran -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Creating SQL Database with WiX v3
That's often a 404-equivalent. There's usually more info in the server error log. Error -2147217900 Cannot open backup device 'incorrect_path_2_file.bak'. Device error or device off-line. See the SQL Server error log for more details. Make sure the SQL Server process has permissions to that path and that the file actually exists there. You are trying to restore to a local server instance, right? Not a remote server? -Original Message- From: Eric Latendresse [mailto:elatendre...@optimum-solutions.com] Sent: Monday, January 26, 2009 13:21 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating SQL Database with WiX v3 I tried to restore the database from a backup file during the initial install and am getting this error below. Is there WiX log or something where I can get some more info on how to debug this? Below is my code and I think this should work. Anyone have any ideas? Thanks in advance for you help. Component Id=SuiteDatabaseComponent Guid=d6e96011-3252-4e85-80b5-b1ff64045e88 File Id=DatabaseBackup Name=SuiteBlank.bak Source=..\..\Database\Backups\SuiteBlank.bak / CreateFolder/ !-- installs database -- sql:SqlDatabase Id=db1 Server=[SQLSERVER] Instance=[SQLINSTANCE] Database=Suite CreateOnInstall=yes ConfirmOverwrite=yes DropOnUninstall=no User=SQLUser !-- define where the database files are saved -- sql:SqlFileSpec Id=mdf Name=Suite_Data Filename=[DATABASEDIR]Suite_Data.mdf Size=2MB GrowthSize=2MB/ sql:SqlLogFileSpec Id=ldf Name=Suite_Log Filename=[DATABASEDIR]Suite_Log.ldf/ /sql:SqlDatabase sql:SqlString Id='RestoreDB' SqlDb='db1' ContinueOnError='no' ExecuteOnInstall='yes' SQL=RESTORE DATABASE Suite FROM DISK = '[DATABASEDIR]SuiteBlank.bak' WITH MOVE 'Suite_Data' TO '[DATABASEDIR]Suite_Data.mdf', MOVE 'Suite_Log' TO '[DATABASEDIR]Suite_Log.ldf',REPLACE/ /Component Error -2147217900: failed to execute SQL string, error detail: RESTORE DATABASE is terminating abnormally., SQL key: RestoreDB SQL string: RESTORE DATABASE Suite FROM DISK = 'G:\Database\SuiteBlank.bak' WITH MOVE 'Suite_Data' TO G:\ ...\Suite_Log.ldf',REPLACE Eric Latendresse -Original Message- From: David Reed [mailto:david.r...@microsoft.com] Sent: Friday, January 23, 2009 11:44 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating SQL Database with WiX v3 It really depends on what those 9k scripts are doing. If your scripts are a raft of INSERT statements or other transactions, then you can probably switch to CSVs and bulk load (much faster), which is what we do with AdventureWorks now for SQL Server 2008 samples. The WiX3 code for ours is checked into CodePlex here along with the MSBuild scripts, etc: http://www.codeplex.com/SqlServerSamples/SourceControl/ListDownloadableC ommits.aspx In our experience with AdventureWorks' installers, switching to a backup/restore is likely to bloat the size of your installer quite a bit because the BAK files aren't nearly as compressible (if at all) as script files are... From: Eric Latendresse [elatendre...@optimum-solutions.com] Sent: Friday, January 23, 2009 13:10 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Creating SQL Database with WiX v3 I am creating a SQL database with my installer. Right now I have approximately 9000 scripts to be run after the database is created. This is taking around 20mins for the install to complete. Is there anything I can do to speed this process up? I thought about running a single script to restore the database from a backup file of the database, but thought I'd ask if there was a better way. Eric Latendresse -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list
Re: [WiX-users] Adding system wide module to IIS7 on 64-bit OS
Additional info, I am using WIX 3.0.4827.0
With the following:
?if $(var.ProcessorArchitecture)=x64?
?define 64bit=yes?
?define ProgramFiles=ProgramFiles64Folder?
?define ProductGuid={YOURGUID-C701-42ab-B252-2D8C869CA7E3}?
?define UpgradeGuid={YOURGUID-C16C-4aeb-B439-F6A42EB6C022}?
?else?
?define 64bit=no?
?define ProgramFiles=ProgramFilesFolder?
?define ProductGuid={YOURGUID-4B18-446e-AD6E-35EB81EB56EE}?
?define UpgradeGuid={YOURGUID-9F5B-4271-90B0-7D0C3A6FC4DE}?
?endif?
Product Id=$(var.ProductGuid) Name=MyProduct.ServerSetup Language=1033
Version=1.0.0.0 Manufacturer=MySoftware UpgradeCode=$(var.UpgradeGuid)
Package InstallerVersion=200 Compressed=yes
InstallPrivileges=elevated Platform=$(var.ProcessorArchitecture)/
I didn't get any replies in my e-mail, but noticed there was an actual reply on
the archive.
If anybody could help I would be most appreciative
Thanks,
Adam
From: Adam Eversole
Sent: Friday, January 23, 2009 2:24 PM
To: 'wix-users@lists.sourceforge.net'
Subject: Adding system wide module to IIS7 on 64-bit OS
I have a setup that installs a system-wide managed-code module in IIS7. I do
this as follows:
Component Id=modulesConfig
Guid={3D0ACDA1-C029-4084-B3F7-51822745A7ED} Win64=$(var.64bit)
util:XmlConfig Id=addMyHandler Sequence=4
File=[IISINSTALLDIR]Config\applicationHost.config
ElementPath=//system.webServer/modules Name=add Node=element
Action=create On=install /
util:XmlConfig Id='add_name' Sequence='5'
File='[IISINSTALLDIR]Config\applicationHost.config'
ElementId='addMyHandler' Name='name' Value='myHandler' /
util:XmlConfig Id='add_type' Sequence='6'
File='[IISINSTALLDIR]Config\applicationHost.config'
ElementId='addMyHandler' Name='type' Value='MyHandler.Module,
MyHandler, Version=1.0.0.1, Culture=neutral, PublicKeyToken=9a9d230324c99377' /
util:XmlConfig Id=modulesConfigRemove Sequence=4
File=[IISINSTALLDIR]Config\applicationHost.config
ElementPath=//system.webServer/modules
VerifyPath=//system.webServer/modules/add[...@name='myHandler'[\]]
Name=add Node=element
Action=delete On=uninstall /
/Component
With the following preprocessor command setting var.64bit:
?ifdef $(var.ProcessorArchitecture) = x64?
?define 64bit=yes?
?else?
?define 64bit=no?
?endif?
This seems to work just fine in 32-bit, but in 64-bit it fails with the
following error:
Action 14:21:52: ExecXmlConfig.
Error 25541. Failed to open XML file
C:\Windows\system32\inetsrv\Config\applicationHost.config, system error:
-2147024786
I can't figure it out, I made sure I have access to the file in elevated mode
(the elevated prompt comes up), and it works great in 32-bit.
Any ideas? Is there a better way to do this?
Thanks,
Adam
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting folder permissions (was: Problems installing a windows service)
The default MSI SDK Permission element overwrites ACLs. The PermissionEx element appends ACLs. -Original Message- From: Thomas Due [mailto:thomas@scanvaegt.dk] Sent: Sunday, January 25, 2009 23:01 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Setting folder permissions (was: Problems installing a windows service) Yes, I have been messing around with Permission, and so far I have this: DirectoryId Id=INSTALLDIR Component Id=FolderPermissions Guid=174E96BB-87D6-40B0-84A4-8FF6C58BA702 CreateFolder Directory=INSTALLDIR Permission User=NT AUTHORITY\NetworkService GenericRead=yes GenericWrite=yes / /CreateFolder /Component /DirectoryId My problem is, that I seem to REPLACE the existing permissions, where I need to ADD to them. When I do this, I complete remove all other permissions on the folder (Except for System). Shouldn't it be possible to append a new permission set, instead of replacing the existing? It doesn't seem right that I have to add ALL permissions to a folder, when it can just as well Inherit those from its parent. Thomas Due -Original Message- From: Wilson, Phil [mailto:phil.wil...@wonderware.com] Sent: 23. januar 2009 19:56 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Problems installing a windows service I think there are some WiX built-in custom actions that set permissions - I forget if it's Permissions or something else. Phil Wilson -Original Message- From: Thomas Due [mailto:thomas@scanvaegt.dk] Sent: Friday, January 23, 2009 1:17 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Problems installing a windows service It was the account name. I changed it to NT AUTHORITY\NetworkService and presto: It installed without a hitch. Now I only have a single question (at the moment): How do I set specific permissions to a specific account on the installdir? I need to set write permissions for NT AUTHORITY\NetworkService on the installation directory. Thanks, Thomas Due -Original Message- From: Wilson, Phil [mailto:phil.wil...@wonderware.com] Sent: 23. januar 2009 01:54 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Problems installing a windows service To add to this: 1) A dependent assembly that you're installing in the GAC will be an issue because they're not available until the end of the install after StartServices. 2) What would you do in other circumstances if your service crashed or would not start? This is no different really. If it doesn't start at all it's usually a dependency issue, an account issue, or a catastrophic crash as soon as it starts. Trace or debug entries are something I can't live without these days. It's not that I'm a poor developer, honest, but with TraceListeners it's so easy to put trace information that it's bad practice NOT to add Trace.WriteLine that goes to a text file somewhere. 3) Regardless of what tool you use, the underlying engine is still Windows Installer and an MSI file. Getting to know something about that is always useful. In this case, the content of the ServiceInstall table and allowed values for StartName are relevant. Anyway, I don't believe that Network Service is the correct name for that account. Those actual account names (as opposed to the friendly names) need to be something like NT AUTHORITY\LocalService. Perhaps NT AUTHORITY\NetworkService is the actual name. Phil Wilson -Original Message- From: Chad Miles [mailto:chad.mi...@gmail.com] Sent: Thursday, January 22, 2009 7:51 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Problems installing a windows service Have you run depends/reflector on your file to see if your missing any dependencies by chance? On Thu, Jan 22, 2009 at 9:48 AM, Thomas Due thomas@scanvaegt.dk wrote: I am currently experimenting with WiX to see if it is something we can use for our next generation software. My immediate thought was to simply build the complete installation from ground-up in small steps. This have worked fine so far, now I have run into a problem though, when I try to install a Windows Service I get this error: Service My Name Server (NSEngine) could not be installed. Verify that you have sufficient privileges to install system services. The problem is, I DO have sufficient privileges to install services, at least I haven't had any problems using the InstallUtil. The services have been created with VS2008 and .NET 3.5 (C#). If I use InstallUtil, they install fine, but I thought I would try doing it the right way. Here is the code I am currently using: DirectoryRef Id=INSTALLDIR Component Id=NameServiceComponent Guid=53398A87-395B-4DA8-A475-04684FE5DE20 File Id=NSEngine Name=$(var.NSEngine.TargetFileName)
Re: [WiX-users] LGHT001 error from Light I can't seem to get rid of
Yes. I will do so promptly. -- John M. Cooper -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Monday, January 26, 2009 2:14 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] LGHT001 error from Light I can't seem to get rid of Ug, bug. Can you file this on SourceForge? Should be able to get a fix next week. Be sure to put it under the v3.0 Group and light Category. -Original Message- From: John Cooper (Volt) [mailto:a-jc...@microsoft.com] Sent: Monday, January 26, 2009 09:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] LGHT001 error from Light I can't seem to get rid of On this run, I was using 3.0.4707.0. Thinking that the latest version might fix the problem, I've installed 3.0.4923, but I get the same error. So, then I tried offload things to lit. If if leave off the -bf flag on lit, it compiles everything into wixlib's just fine (and then I get the aforementioned error in light.exe). However, if I add the -bf flag to bind the binaries into the wixlib's, I get: Microsoft (R) Windows Installer Xml Library Tool version 3.0.4923.0 Copyright (C) Microsoft Corporation. All rights reserved. lit.exe : error LIT0001 : Unable to find an entry point named 'CreateCabCancel' in DLL 'winterop.dll'. Exception Type: System.EntryPointNotFoundException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.Cab.Interop.NativeMethods.CreateCabCancel(IntPtr contextHandle) at Microsoft.Tools.WindowsInstallerXml.Cab.WixCreateCab.Dispose() at Microsoft.Tools.WindowsInstallerXml.Library.Save(String path, BinderFileManager binderFileManager, WixVariableResolver wixVariableResolver) at Microsoft.Tools.WindowsInstallerXml.Tools.Lit.Run(String[] args) -- John M. Cooper -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Saturday, January 24, 2009 8:03 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] LGHT001 error from Light I can't seem to get rid of What vesion of the WiX toolset are you using? -Original Message- From: John Cooper (Volt) [mailto:a-jc...@microsoft.com] Sent: Friday, January 23, 2009 15:31 To: wix-users@lists.sourceforge.net Subject: [WiX-users] LGHT001 error from Light I can't seem to get rid of I can't seem to get rid of this error on my server builds: 1/23/2009 2:57:48 PMCMD: E:\bt\512100\build\setup\tools\wix\3.0.4707.0\binaries\light.exe -ct 16 -v -pedantic -ext WixUIExtension -ext WixNetFxExtension -cultures:en-us -loc E:\bt\512100\build\setup\tools\wix\3.0.4707.0\sources\loc\WixUI_en-us.wxl -loc E:\bt\512100\build\setup\PMX\Loc\locstrings_en-us.wxl -out E:\bt\512100\Build\Setup\Kit\Bld1323\beta\disk1\Microsoft Windows Mobile PMX Adaption Kit.msi E:\bt\512100\Build\Setup\Kit\Bld1323\beta\build\*.wixobj 1/23/2009 2:57:48 PMMicrosoft (R) Windows Installer Xml Linker version 3.0.4707.0 1/23/2009 2:57:48 PMCopyright (C) Microsoft Corporation. All rights reserved. 1/23/2009 2:57:48 PM 1/23/2009 2:59:40 PMlight.exe : error LGHT0001 : Exception of type 'System.OutOfMemoryException' was thrown. 1/23/2009 2:59:40 PM 1/23/2009 2:59:40 PMException Type: System.OutOfMemoryException 1/23/2009 2:59:40 PM 1/23/2009 2:59:40 PMStack Trace: 1/23/2009 2:59:40 PM at System.String.GetStringForStringBuilder(String value, Int32 startIndex, Int32 length, Int32 capacity) 1/23/2009 2:59:40 PM at System.Text.StringBuilder.GetNewString(String currentString, Int32 requiredLength) 1/23/2009 2:59:40 PM at System.Text.StringBuilder.Append(String value) 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.Row.GetPrimaryKey(Char delimiter) 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.Symbol.get_Name() 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.SymbolCollection.Add(Symbol symbol) 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.Section.GetSymbols(IMessageHandler messageHandler) 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.SectionCollection.FindEntrySectionAndLoadSymbols(Boolean allowIdenticalRows, IMessageHandler messageHandler, OutputType expectedOutputType, Section entrySection, SymbolCollection allSymbols) 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.Linker.Link(SectionCollection sections, ArrayList transforms, OutputType expectedOutputType) 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args) 1/23/2009 2:59:40 PMBinder temporary directory located at 'C:\WINDOWS\TEMP\va_sd7cx'. 1/23/2009 2:59:40 PMValidator temporary directory located at 'C:\WINDOWS\TEMP\nonrjueh'. Curiously, it does not show up on Vista when I build on my workstation. -- John M. Cooper Volt at Microsoft -- This
Re: [WiX-users] Creating SQL Database with WiX v3
-2147217900 == DB_E_ERRORSINCOMMAND oledberr.h Unfortunately, more detail is not provided. -Original Message- From: Eric Latendresse [mailto:elatendre...@optimum-solutions.com] Sent: Monday, January 26, 2009 13:21 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating SQL Database with WiX v3 I tried to restore the database from a backup file during the initial install and am getting this error below. Is there WiX log or something where I can get some more info on how to debug this? Below is my code and I think this should work. Anyone have any ideas? Thanks in advance for you help. Component Id=SuiteDatabaseComponent Guid=d6e96011-3252-4e85-80b5-b1ff64045e88 File Id=DatabaseBackup Name=SuiteBlank.bak Source=..\..\Database\Backups\SuiteBlank.bak / CreateFolder/ !-- installs database -- sql:SqlDatabase Id=db1 Server=[SQLSERVER] Instance=[SQLINSTANCE] Database=Suite CreateOnInstall=yes ConfirmOverwrite=yes DropOnUninstall=no User=SQLUser !-- define where the database files are saved -- sql:SqlFileSpec Id=mdf Name=Suite_Data Filename=[DATABASEDIR]Suite_Data.mdf Size=2MB GrowthSize=2MB/ sql:SqlLogFileSpec Id=ldf Name=Suite_Log Filename=[DATABASEDIR]Suite_Log.ldf/ /sql:SqlDatabase sql:SqlString Id='RestoreDB' SqlDb='db1' ContinueOnError='no' ExecuteOnInstall='yes' SQL=RESTORE DATABASE Suite FROM DISK = '[DATABASEDIR]SuiteBlank.bak' WITH MOVE 'Suite_Data' TO '[DATABASEDIR]Suite_Data.mdf', MOVE 'Suite_Log' TO '[DATABASEDIR]Suite_Log.ldf',REPLACE/ /Component Error -2147217900: failed to execute SQL string, error detail: RESTORE DATABASE is terminating abnormally., SQL key: RestoreDB SQL string: RESTORE DATABASE Suite FROM DISK = 'G:\Database\SuiteBlank.bak' WITH MOVE 'Suite_Data' TO G:\ ...\Suite_Log.ldf',REPLACE Eric Latendresse -Original Message- From: David Reed [mailto:david.r...@microsoft.com] Sent: Friday, January 23, 2009 11:44 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Creating SQL Database with WiX v3 It really depends on what those 9k scripts are doing. If your scripts are a raft of INSERT statements or other transactions, then you can probably switch to CSVs and bulk load (much faster), which is what we do with AdventureWorks now for SQL Server 2008 samples. The WiX3 code for ours is checked into CodePlex here along with the MSBuild scripts, etc: http://www.codeplex.com/SqlServerSamples/SourceControl/ListDownloadableC ommits.aspx In our experience with AdventureWorks' installers, switching to a backup/restore is likely to bloat the size of your installer quite a bit because the BAK files aren't nearly as compressible (if at all) as script files are... From: Eric Latendresse [elatendre...@optimum-solutions.com] Sent: Friday, January 23, 2009 13:10 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Creating SQL Database with WiX v3 I am creating a SQL database with my installer. Right now I have approximately 9000 scripts to be run after the database is created. This is taking around 20mins for the install to complete. Is there anything I can do to speed this process up? I thought about running a single script to restore the database from a backup file of the database, but thought I'd ask if there was a better way. Eric Latendresse -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
Re: [WiX-users] Prevent 32 bit MSI install on 64 bit OS
Hmm, the doc says that Msix64 is set when running on a 64 bit processor. What does it mean if I have a 32bit version of Windows running on a 64-bit processor? -Original Message- From: Moradi, Ari [mailto:arastoo.mor...@hp.com] Sent: Monday, January 26, 2009 4:15 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Prevent 32 bit MSI install on 64 bit OS I think a LaunchCondition with the property Msix64 will do what you want. -Ari -Original Message- From: Jeremy Lew [mailto:j...@liquidmachines.com] Sent: Monday, January 26, 2009 2:49 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Prevent 32 bit MSI install on 64 bit OS Before I resort to a CA that tries to call IsWow64Process(), is there any other simple way to bail out if attempting to run a 32 bit installer on a Win64 OS? (My product requires the 64 bit installer on a 64 bit OS) Thanks, Jeremy -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Override 'Large Package' in WiX
Yes, the -ust switch, but what about WiX v3? We have been using that exclusively since build 3113. Jim On Mon, Jan 26, 2009 at 11:39 AM, Rob Mensching-2 (via Nabble) ml-user+58086-232436...@n2.nabble.comml-user%2b58086-232436...@n2.nabble.com wrote: light.exe in WiX v2 has switch to do that. -Original Message- From: Jim Stout [mailto:jimst...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2220097i=0] Sent: Monday, January 26, 2009 10:50 To: wix-us...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2220097i=1 Subject: [WiX-users] Override 'Large Package' in WiX WiX sets File Sequence and Media LastSequence to i4 to enable creation of large msi packages. Is there anyway to force candle/light to use the standard i2 for these columns? Exporting and importing idt files is clumsy. I would like to use WiX to build an updated database for use with patching a legacy product. TIA, Jim -- View this message in context: http://n2.nabble.com/Override-%27Large-Package%27-in-WiX-tp2219802p2219802.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list wix-us...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2220097i=2 https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list wix-us...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2220097i=3 https://lists.sourceforge.net/lists/listinfo/wix-users -- This email is a reply to your post @ http://n2.nabble.com/Override-%27Large-Package%27-in-WiX-tp2219802p2220097.html You can reply by email or by visting the link above. -- View this message in context: http://n2.nabble.com/Override-%27Large-Package%27-in-WiX-tp2219802p2220974.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] German OS and Network Service Account issue
I'm having an issue with a basic installer built with WIX when it's being used on German versions of Windows XP - the problem is that the Network Service account is in fact named Netzwerkdienst and as such the installer is failing with the message: An error occurred while applying security settings. Network Service is not a valid user or group. This could be a problem with the package, or a problem connecting to a domain controller on the network. Check your network connection and click retry, or Cancel to end the install. Here's the snippet of xml that's failing: Component Id=WebSiteIndexesComponent Guid=3B9C897B-FE09-4c3c-A244-CC84964BFF0F Directory=WebSiteIndexes CreateFolder Permission User=Network Service GenericAll=yes ChangePermission=yes / /CreateFolder /Component I'm wondering if anyone has hit this issue, and if there's a way to reference a localized Network Service name that's correct for german vs. english OS's. Alternatively is there a Condition I could evaluate to choose different components based on the OS language? Cheers, - Alex -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Override 'Large Package' in WiX
Switch doesn't exist in WiX v3. The -ust had lots of legacy (almost duplicate) code in it that wasn't maintained well. It was removed early in WiX v3. -Original Message- From: Jim Stout [mailto:jimst...@gmail.com] Sent: Monday, January 26, 2009 13:55 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Override 'Large Package' in WiX Yes, the -ust switch, but what about WiX v3? We have been using that exclusively since build 3113. Jim On Mon, Jan 26, 2009 at 11:39 AM, Rob Mensching-2 (via Nabble) ml-user+58086-232436...@n2.nabble.comml-user%2b58086-232436...@n2.nabble.com wrote: light.exe in WiX v2 has switch to do that. -Original Message- From: Jim Stout [mailto:jimst...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2220097i=0] Sent: Monday, January 26, 2009 10:50 To: wix-us...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2220097i=1 Subject: [WiX-users] Override 'Large Package' in WiX WiX sets File Sequence and Media LastSequence to i4 to enable creation of large msi packages. Is there anyway to force candle/light to use the standard i2 for these columns? Exporting and importing idt files is clumsy. I would like to use WiX to build an updated database for use with patching a legacy product. TIA, Jim -- View this message in context: http://n2.nabble.com/Override-%27Large-Package%27-in-WiX-tp2219802p2219802.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list wix-us...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2220097i=2 https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list wix-us...@...http://n2.nabble.com/user/SendEmail.jtp?type=nodenode=2220097i=3 https://lists.sourceforge.net/lists/listinfo/wix-users -- This email is a reply to your post @ http://n2.nabble.com/Override-%27Large-Package%27-in-WiX-tp2219802p2220097.html You can reply by email or by visting the link above. -- View this message in context: http://n2.nabble.com/Override-%27Large-Package%27-in-WiX-tp2219802p2220974.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] LGHT001 error from Light I can't seem to get rid of
Thanks much. Ick. -Original Message- From: John Cooper (Volt) [mailto:a-jc...@microsoft.com] Sent: Monday, January 26, 2009 14:42 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] LGHT001 error from Light I can't seem to get rid of Yes. I will do so promptly. -- John M. Cooper -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Monday, January 26, 2009 2:14 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] LGHT001 error from Light I can't seem to get rid of Ug, bug. Can you file this on SourceForge? Should be able to get a fix next week. Be sure to put it under the v3.0 Group and light Category. -Original Message- From: John Cooper (Volt) [mailto:a-jc...@microsoft.com] Sent: Monday, January 26, 2009 09:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] LGHT001 error from Light I can't seem to get rid of On this run, I was using 3.0.4707.0. Thinking that the latest version might fix the problem, I've installed 3.0.4923, but I get the same error. So, then I tried offload things to lit. If if leave off the -bf flag on lit, it compiles everything into wixlib's just fine (and then I get the aforementioned error in light.exe). However, if I add the -bf flag to bind the binaries into the wixlib's, I get: Microsoft (R) Windows Installer Xml Library Tool version 3.0.4923.0 Copyright (C) Microsoft Corporation. All rights reserved. lit.exe : error LIT0001 : Unable to find an entry point named 'CreateCabCancel' in DLL 'winterop.dll'. Exception Type: System.EntryPointNotFoundException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.Cab.Interop.NativeMethods.CreateCabCancel(IntPtr contextHandle) at Microsoft.Tools.WindowsInstallerXml.Cab.WixCreateCab.Dispose() at Microsoft.Tools.WindowsInstallerXml.Library.Save(String path, BinderFileManager binderFileManager, WixVariableResolver wixVariableResolver) at Microsoft.Tools.WindowsInstallerXml.Tools.Lit.Run(String[] args) -- John M. Cooper -Original Message- From: Rob Mensching [mailto:rob.mensch...@microsoft.com] Sent: Saturday, January 24, 2009 8:03 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] LGHT001 error from Light I can't seem to get rid of What vesion of the WiX toolset are you using? -Original Message- From: John Cooper (Volt) [mailto:a-jc...@microsoft.com] Sent: Friday, January 23, 2009 15:31 To: wix-users@lists.sourceforge.net Subject: [WiX-users] LGHT001 error from Light I can't seem to get rid of I can't seem to get rid of this error on my server builds: 1/23/2009 2:57:48 PMCMD: E:\bt\512100\build\setup\tools\wix\3.0.4707.0\binaries\light.exe -ct 16 -v -pedantic -ext WixUIExtension -ext WixNetFxExtension -cultures:en-us -loc E:\bt\512100\build\setup\tools\wix\3.0.4707.0\sources\loc\WixUI_en-us.wxl -loc E:\bt\512100\build\setup\PMX\Loc\locstrings_en-us.wxl -out E:\bt\512100\Build\Setup\Kit\Bld1323\beta\disk1\Microsoft Windows Mobile PMX Adaption Kit.msi E:\bt\512100\Build\Setup\Kit\Bld1323\beta\build\*.wixobj 1/23/2009 2:57:48 PMMicrosoft (R) Windows Installer Xml Linker version 3.0.4707.0 1/23/2009 2:57:48 PMCopyright (C) Microsoft Corporation. All rights reserved. 1/23/2009 2:57:48 PM 1/23/2009 2:59:40 PMlight.exe : error LGHT0001 : Exception of type 'System.OutOfMemoryException' was thrown. 1/23/2009 2:59:40 PM 1/23/2009 2:59:40 PMException Type: System.OutOfMemoryException 1/23/2009 2:59:40 PM 1/23/2009 2:59:40 PMStack Trace: 1/23/2009 2:59:40 PM at System.String.GetStringForStringBuilder(String value, Int32 startIndex, Int32 length, Int32 capacity) 1/23/2009 2:59:40 PM at System.Text.StringBuilder.GetNewString(String currentString, Int32 requiredLength) 1/23/2009 2:59:40 PM at System.Text.StringBuilder.Append(String value) 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.Row.GetPrimaryKey(Char delimiter) 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.Symbol.get_Name() 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.SymbolCollection.Add(Symbol symbol) 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.Section.GetSymbols(IMessageHandler messageHandler) 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.SectionCollection.FindEntrySectionAndLoadSymbols(Boolean allowIdenticalRows, IMessageHandler messageHandler, OutputType expectedOutputType, Section entrySection, SymbolCollection allSymbols) 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.Linker.Link(SectionCollection sections, ArrayList transforms, OutputType expectedOutputType) 1/23/2009 2:59:40 PM at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args) 1/23/2009 2:59:40 PMBinder temporary directory located at 'C:\WINDOWS\TEMP\va_sd7cx'. 1/23/2009 2:59:40
[WiX-users] CustomizeDlg Reset button to affect feature Location ?
Hi, I'm modifying the standard dialogs provided in src/ext/UIExtension/wixlib to suit my needs. I notice that the Reset button on CustomizeDlg only reverts the user's feature selection in the SelectionTree. I would like the Reset button to also revert the Location values for each feature to the installation default (if the user had changed the path using the Browse button). Is this possible ? Thanks for any help ! Scott -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Prevent 32 bit MSI install on 64 bit OS
From: Jeremy Lew [mailto:j...@liquidmachines.com] Before I resort to a CA that tries to call IsWow64Process(), is there any other simple way to bail out if attempting to run a 32 bit installer on a Win64 OS? (My product requires the 64 bit installer on a 64 bit OS) Launch conditions based on some combination of standard properties such as VersionNT64, Intel64, Msix64. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Specify source of exe in ServiceInstall
In that case, I can probably use installutil to install my windows service. Again how can I achieve something like this? InstallExecuteSequence Custom Action='ManagedInstall' After=InstallFinalize / /InstallExecuteSequence CustomAction Id=ManagedInstall Directory=*[ApplicationDirectory]* ExeCommand='[WindowsFolder]\Microsoft.NET\Framework\v2.0.50727\installUtil.exe /LogToConsole=false **Service1.exe' Return='check' /CustomAction I want to mention the source of the exe to be different than the [ProgramFilesFolder], some other directory, the value which is set in [ApplicationDirectory] - *Re: [WiX-users] Specify source of exe in ServiceInstallhttps://sourceforge.net/mailarchive/message.php?msg_name=DE33023B477FE44EAA71983F5279F6CE50FCE09D3A%40NA-EXMSG-C102.redmond.corp.microsoft.com * From: Rob Mensching rob.mensch...@mi... - 2009-01-26 22:38 ServiceInstall in MSI doesn't support that scenario. MSI SDK says ServiceInstall always points at the key path of the Component. -Original Message- From: Anupama A [mailto:anupama...@gm...] Sent: Monday, January 26, 2009 07:32 To: wix-us...@li... Subject: Re: [WiX-users] Specify source of exe in ServiceInstall Thanks, I am aware of this. The point I am trying to make is that in my case, the source of the File element above the ServiceInstall is not clear at compile time. As I mentioned, I set a property called [ApplicationDirectory] during execution and this would hold the path that should be set to File element's source * Re: [WiX-users] Specify source of exe in ServiceInstall* From: Thomas Due thomas@sc... - 2009-01-26 08:12 I actually struggled a bit with this as well, I discovered that the easiest way to do that is: Component Id=NameServiceComponent Guid=* DiskId=1 File Id=ServiceId Name=FileName Source=FilePath / ServiceInstall Id=ServiceInstallId DisplayName=ServiceDisplayName Name=ServiceName Description= ErrorControl=normal Start=auto Type=ownProcess Vital=yes Account=NT AUTHORITY\NetworkService Interactive=no/ /Component Apparently the ServiceInstall node references the file node directly above it. Thomas Due -Original Message- From: Anupama A [mailto:anupama...@gm...] Sent: 26. januar 2009 08:24 To: wix-us...@li... Subject: [WiX-users] Specify source of exe in ServiceInstall I am trying to write an installer for a Windows Service. Depending on the deploy environment, I set a property called [ApplicationDirectory]. I have a separate component which copies all files from [ProgramFilesFolder] to [ApplicationDirectory] depending on what is dynamically set. And then the service install from the new location [ApplicationDirectory] should happen. In the below statement how do I specify the Service1.exe is in the [AppDirectory] path: ServiceInstall Id=Service1Installer Name=Service1.exe Type=ownProcess Start=auto Vital=yes ErrorControl=normal/ServiceInstall Wrapping this within a File element with the source pointing to the exe from the new location will fail at compile time as [AppDirectory] will not be set then. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Prevent 32 bit MSI install on 64 bit OS
Hi Jeremy! I solved it this way: Firstly I define a custom action for 32bit setup routine: ?if $(var.ProcessorArchitecture)=x86 ? CustomAction Id=CA_Err32BitMsiOn64BitOS Error=The 32-bit version of this product cannot be installed on a 64-bit version of Microsoft Windows. / ?endif ? Secondly I call the custom action in the 32bit setup routine whenever it is called on a 64bit machine: InstallExecuteSequence ?if $(var.ProcessorArchitecture)=x86 ? Custom Action=CA_Err32BitMsiOn64BitOS After=LaunchConditions ![CDATA[MsiAMD64 OR Intel64]] /Custom ?endif ? ... /InstallExecuteSequence InstallUISequence !-- Only schedule this custom action for the 32-bit MSI. -- ?if $(var.ProcessorArchitecture)=x86 ? Custom Action=CA_Err32BitMsiOn64BitOS After=LaunchConditions ![CDATA[MsiAMD64 OR Intel64]] /Custom ?endif ? ... /InstallUISequence To be honest I did not invent this by myself. I found this solution in a blog. Unfortunately I cannot remember the URL of the blog any more. Hope this helps. Kind regards, Rainer. -Ursprüngliche Nachricht- Von: Jeremy Lew [mailto:j...@liquidmachines.com] Gesendet: Montag, 26. Jänner 2009 21:49 An: General discussion for Windows Installer XML toolset. Betreff: [WiX-users] Prevent 32 bit MSI install on 64 bit OS Before I resort to a CA that tries to call IsWow64Process(), is there any other simple way to bail out if attempting to run a 32 bit installer on a Win64 OS? (My product requires the 64 bit installer on a 64 bit OS) Thanks, Jeremy -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to change permission for existing Folder and/or file?
Permission Element's parent must be CreateFolder or File. How to change the permission for existing Folder and/or file? Thanks Joseph -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Prevent 32 bit MSI install on 64 bit OS
The VersionNT64, Intel64, and Msix64 properties are all imprecisely and inaccurately worded, which makes it very difficult to work out how to use them properly. It's a while since I wasted a chunk of time experimenting to work out what they actually mean, but I'm fairly sure that Msix64 being defined actually means that you are running on an x64 edition of Windows. Its documentation implies that you could be on a 32-bit or x64 edition running on an x64 processor, or on an Itanium processor, but it's wrong. Regards, jjf -Original Message- From: Jeremy Lew [mailto:j...@liquidmachines.com] Sent: Monday, January 26, 2009 9:42 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Prevent 32 bit MSI install on 64 bit OS Hmm, the doc says that Msix64 is set when running on a 64 bit processor. What does it mean if I have a 32bit version of Windows running on a 64-bit processor? -Original Message- From: Moradi, Ari [mailto:arastoo.mor...@hp.com] Sent: Monday, January 26, 2009 4:15 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Prevent 32 bit MSI install on 64 bit OS I think a LaunchCondition with the property Msix64 will do what you want. -Ari -Original Message- From: Jeremy Lew [mailto:j...@liquidmachines.com] Sent: Monday, January 26, 2009 2:49 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Prevent 32 bit MSI install on 64 bit OS Before I resort to a CA that tries to call IsWow64Process(), is there any other simple way to bail out if attempting to run a 32 bit installer on a Win64 OS? (My product requires the 64 bit installer on a 64 bit OS) Thanks, Jeremy -- -- -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -- -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] CustoAction as early as possible
Hi, I am trying to invoke CA as early as possible. Ideally on msi startup but on showing the first UI dialog will do. InstallExecuteSequence Custom Action=MyAction Before=InstallInitialize(NOT Installed)/Custom /InstallExecuteSequence CustomAction Id=MyAction BinaryKey=MyAction_File DllEntry=MyAction Execute=immediate Return=asyncNoWait / The code above executes MyAction after all UI dialogs finished. I guess standard action InstallInitialize is not good for this. What would be the best approach to solve this problem. Any idea will be appreciated. -- View this message in context: http://n2.nabble.com/CustoAction-as-early-as-possible-tp674p674.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Configuration update problem during install...
John H. Bergman (XPedient Technologies) wrote: That did it for me, thanks. BTW, where is this documented, I hunted and hunted and could not find it. WiX.chm specifies that the field is formatted; the MSI SDK documents the Formatted special characters. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Dealing with Components with Only Non-Versioned Files
jnewton wrote: I have a few components that only contain non-versioned files (i.e. message files, fonts). Currently I am using a core DLL that I install as the companion file for the files in those components. However, this means that I don't have a keypath for these components. I'm not sure if this is a problem or not, and if so, any suggestions? Currently I am just doing a post-build step to insert a keypath back into this component. What keypath are you putting in? -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CustomizeDlg Reset button to affect feature Location ?
Scott Sanders wrote: I'm modifying the standard dialogs provided in src/ext/UIExtension/wixlib to suit my needs. I notice that the Reset button on CustomizeDlg only reverts the user's feature selection in the SelectionTree. I would like the Reset button to also revert the Location values for each feature to the installation default (if the user had changed the path using the Browse button). Is this possible ? According to the MSI SDK, Reset undoes property values; directories don't count at that point in the UI, so I doubt it's supported. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CustoAction as early as possible
taras wrote: I am trying to invoke CA as early as possible. Ideally on msi startup but on showing the first UI dialog will do. InstallExecuteSequence If you want a custom action to run during the UI, use InstallUISequence instead. Note that it won't run during a silent install. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CustoAction as early as possible
When UI is in use during installation (UI level is not None), Windows Installer starts with actions from InstallUISequence table. In case when UI level is set to None, you still want to schedule custom action in InstallExecuteSequence table. In that case you may want Execute attribute to be firstSequence depending on if you want or don't want custom action to be executed twice. Also, if you want to run your custom action as early as possible, you probably want to schedule it before LaunchConditions. Alex -Original Message- From: taras [mailto:osh...@gmail.com] Sent: Monday, January 26, 2009 10:38 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] CustoAction as early as possible Hi, I am trying to invoke CA as early as possible. Ideally on msi startup but on showing the first UI dialog will do. InstallExecuteSequence Custom Action=MyAction Before=InstallInitialize(NOT Installed)/Custom /InstallExecuteSequence CustomAction Id=MyAction BinaryKey=MyAction_File DllEntry=MyAction Execute=immediate Return=asyncNoWait / The code above executes MyAction after all UI dialogs finished. I guess standard action InstallInitialize is not good for this. What would be the best approach to solve this problem. Any idea will be appreciated. -- View this message in context: http://n2.nabble.com/CustoAction-as-early-as-possible-tp674p674.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] CustoAction as early as possible
Thank you Bob. It is exactly what I needed... Bob Arnson-6 wrote: taras wrote: I am trying to invoke CA as early as possible. Ideally on msi startup but on showing the first UI dialog will do. InstallExecuteSequence If you want a custom action to run during the UI, use InstallUISequence instead. Note that it won't run during a silent install. -- sig://boB http://joyofsetup.com/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://n2.nabble.com/CustoAction-as-early-as-possible-tp674p710.html Sent from the wix-users mailing list archive at Nabble.com. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
