[WiX-users] how do I start an application after install, not conditionally and not based on clicking on dialog
As per the subject line, it's just supposed to install and run. The user doesn't have to click on the dialog to say that they want it to run. Thanks, Bryan Rasmussen - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how do I start an application after install, not conditionally and not based on clicking on dialog
Specifically I am trying to do this: CustomAction Id=CA1 Property=CA1_PROP Value=[AUTOPILOT]AutoPilot.exe / InstallExecuteSequence InstallFinalize/ Custom Action=CA1 After=InstallFinalize / /InstallExecuteSequence How should that be restructured to work? Thanks, Bryan Rasmussen On Thu, Jun 26, 2008 at 9:47 AM, bryan rasmussen [EMAIL PROTECTED] wrote: As per the subject line, it's just supposed to install and run. The user doesn't have to click on the dialog to say that they want it to run. Thanks, Bryan Rasmussen - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] RadioButton bizarreness
Just thought I'd shared this with you as I'm not
sure if it's expected behaviour or not.
I've been setting up a RadioButton on a UI...
Control Id=Radio Type=RadioButtonGroup X=10 Y=50 Width=310
Height=45 TabSkip=no Text=Hello Property=REF
RadioButtonGroup Property=REF
RadioButton Value=ipc
X=10 Y=0
Width=295 Height=15
Text={\WixUI_Font_Bold}amp;IPC /
RadioButton Value=tcp
X=10 Y=20
Width=295 Height=15
Text={\WixUI_Font_Bold}amp;TCP port /
/RadioButtonGroup
/Control
So far so good however if I try to use Indirect=yes for
the Control I always get the error trying to display
the UI...
Error Id=2855The radio button group [3] on dialog [2] has fewer than
2 buttons./Error
What say the panel? Should it behave in this unseemly
manner or am I simply being a dumb brit?
--
Richard Mitchell
Project Manager
Red Gate Software Ltd
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] GAC Funtamental question
Hi, I am new to Wix. I am trying to see some sample for GAC an assembly. AssemblyApplication String Specifies the file identifier of the application file. This assembly will be isolated to the same directory as the application file. If this attribute is absent, the assembly will be installed to the Global Assembly Cache. This attribute may only be specified if the Assembly attribute is set to '.net' or 'win32' From the documentation even though it says when we don't have this property it will create dll in GAC but it is not working for me.. Am I missing anything very obvious??? Cheers Raj - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Induce Sleep in the MSI script
Is there a way to do this? -- View this message in context: http://www.nabble.com/Induce-Sleep-in-the-MSI-script-tp18132204p18132204.html Sent from the wix-users mailing list archive at Nabble.com. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Induce Sleep in the MSI script
Use a custom action to play some soothing music? Maybe turn down the LCD backlight? Or did you mean one of the following? 1. Wait for a defined time -- i.e. ::Sleep(milliseconds) or Thread.Sleep(whatever) 2. Put the computer into standby. I'm joking around, but you'll need to be more specific. Cheers, Roger. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anidil Sent: Thu 26 June 2008 13:08 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Induce Sleep in the MSI script Is there a way to do this? -- View this message in context: http://www.nabble.com/Induce-Sleep-in-the-MSI-script-tp18132204p18132204.html Sent from the wix-users mailing list archive at Nabble.com. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users 1E can save a company with 10,000 PCs over $165,000 and 1,381 tons of CO2 emissions per annum. Calculate what you can save with the award winning NightWatchman from 1E. Discover the benefits of System Center solutions for yourself - attend an exclusive 1E Enterprise Solutions Road Show. Visit our website at http://www.1e.com DISCLAIMER: This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind 1E Ltd to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Induce Sleep in the MSI script
Well i mean wait for a defined time.. sleep(milliseconds) I have written a c# exe that gives a sleep of 30 seconds.But when i call it from the installer using a CA,i see that the exe in the process list of task manager for just 4 seconds and it doesn't hold/delay the installation sequence for 30 seconds.. Roger Lipscombe wrote: Use a custom action to play some soothing music? Maybe turn down the LCD backlight? Or did you mean one of the following? 1. Wait for a defined time -- i.e. ::Sleep(milliseconds) or Thread.Sleep(whatever) 2. Put the computer into standby. I'm joking around, but you'll need to be more specific. Cheers, Roger. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Anidil Sent: Thu 26 June 2008 13:08 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Induce Sleep in the MSI script Is there a way to do this? -- View this message in context: http://www.nabble.com/Induce-Sleep-in-the-MSI-script-tp18132204p18132204.html Sent from the wix-users mailing list archive at Nabble.com. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users 1E can save a company with 10,000 PCs over $165,000 and 1,381 tons of CO2 emissions per annum. Calculate what you can save with the award winning NightWatchman from 1E. Discover the benefits of System Center solutions for yourself - attend an exclusive 1E Enterprise Solutions Road Show. Visit our website at http://www.1e.com DISCLAIMER: This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind 1E Ltd to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- View this message in context: http://www.nabble.com/Induce-Sleep-in-the-MSI-script-tp18132204p18133837.html Sent from the wix-users mailing list archive at Nabble.com. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Votive V2008 problem on installing 3.0.4220.0
I haven't been able to reproduce the problem with source control, though several people have reported it. It's tracked as sourceforge bug 1977311. Any further details you can provide will be helpful. Do you notice the problem after just installing WiX, or do you need to open a WiX project for it to appear? If it's the latter, does it happen for new projects or only projects created with a previous build of WiX? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Reil Sent: Wednesday, June 25, 2008 4:22 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Votive V2008 problem on installing 3.0.4220.0 I also had the problem, that SourceControl in VS2008 is not working anymore for the votive project and what's really annoying is that the automatic checkout of files on edit in other projects (e.g. a C# project) is blocked by votive. Regards, Dennis Be careful, some text editors screw up the solution file. I know Textpad for one does... I personally use VS - I just close the solution, then use 'open file' to open the sln file, clicking the down arrow on the Open button and choosing 'text editor' in VS's open dialog. Kelly Simon Dahlbacka [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 06/25/2008 01:08 AM Please respond to General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net To General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net cc Subject Re: [WiX-users] Votive V2008 problem on installing 3.0.4220.0 On Wed, Jun 25, 2008 at 10:56 AM, Baldur [EMAIL PROTECTED] wrote: Hi Neil, Is there anyway I can simply edit the solution files? - I'd rather do this than recreating a complex solution that just happens to contain a WiX project. Notepad (or other text editor of preference) works if you are brave/careful enough /Simon - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] The size of compressed Wix install compared to InstallShield equivalent
I have ported InstallShield (version 12) project to Wix 3. InstallShield has msi embedded in exe and the whole setup.exe is 50 MB large. Wix creates MSI with embedded compressed CAB which takes 70 MB. 20 MB is a pretty large difference! Am I missing something obvious or is InstallShield compression really that superior? Thanks - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] The size of compressed Wix install compared to InstallShield equivalent
You can try passing the high compression (-dcl:hi) switch to light, or setting CompressionLevel=high on your Media element. WiX by default uses a moderate compression level which provides much faster builds but is slightly less optimal. However, I doubt that increasing the compression level will make up that 20MB difference. Do you have any large bitmaps, custom action binaries, or other resources in the Binary table of the MSI? Those items don't get compressed when they're packed in the MSI, though they would when the MSI is further wrapped in an EXE as InstallShield does. If you do have large .BMP files, you can change them to .JPG or .PNG format. Beyond that I have to ask the obvious question: are you sure the set of payload files is the same? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Juricic Sent: Thursday, June 26, 2008 8:14 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] The size of compressed Wix install compared to InstallShield equivalent I have ported InstallShield (version 12) project to Wix 3. InstallShield has msi embedded in exe and the whole setup.exe is 50 MB large. Wix creates MSI with embedded compressed CAB which takes 70 MB. 20 MB is a pretty large difference! Am I missing something obvious or is InstallShield compression really that superior? Thanks - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] not executing custom actions on uninstall
Bob Arnson a écrit : Frédéric Viollet wrote: Could someone please tell me which condition I should use to trigger a custom action only on installations (initial installation and minor upgrades). This custom action must not be run on uninstall. See http://msdn.microsoft.com/en-us/library/aa368561(VS.85).aspx. Ok, thanks. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how do I start an application after install, not conditionally and not based on clicking on dialog
Bryan, I have a new how-to topic out for review that covers launching an application based on a checkbox at the end of setup. I've included the text of it below. Assuming your installer has UI, you can wire up the action in the same way (to the Finish button), but simply omit the piece that turns on the checkbox and the condition for verifying the checkbox. I hope this helps, Neil How To: Run the Installed Application After Setup Often when completing the installation of an application it is desirable to offer the user the option of immediately launching the installed program when setup is complete. This how to describes customizing the default WiX UI experience to include a checkbox and a WiX custom action to launch the application if the checkbox is checked. This how to assumes you have already created a basic WiX project using the steps outlined in How To: Add a file to your installer. Step 1: Add the extension libraries to your project This walkthrough requires WiX extensions for UI components and custom actions. These extension libraries must must be added to your project prior to use. If you are using WiX on the command-line you need to add the following to your candle and light command lines: -ext WixUIExtension -ext WixUtilExtension If you are using Votive you can add the extensions using the Add Reference dialog: Right click on your project in Solution Explorer and select Add Reference... Select the WixUIExtension.dll assembly from the list and click Add Select the WixUtilExtension.dll assembly from the list and click Add Close the Add Reference dialog Step 2: Add UI to your installer The WiX Minimal UI sequence includes a basic set of dialogs that includes a finished dialog with optional checkbox. To include the sequence in your project add the following snippet anywhere inside the Product element. UI UIRef Id=WixUI_Minimal / /UI To display the checkbox on the last screen of the installer include the following snippet anywhere inside the Product element: Property Id=WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT Value=Launch My Application Name / The WIXUI_EXITDIALOGOPTIONALCHECKBOXTEXT property is provided by the standard UI sequence that, when set, displays the checkbox and uses the specified value as the checkbox label. Step 3: Include the custom action Custom actions are included in a WiX project using the CustomAction element. Running an application is accomplished with the WixShellExecTarget custom action. To tell Windows Installer about the custom action, and to set its properties, include the following in your project anywhere inside the Product element: Property Id=WixShellExecTarget Value=[#myapplication.exe] / CustomAction Id=LaunchApplication BinaryKey=WixCA DllEntry=WixShellExec Impersonate=yes / The Property element sets the WixShellExecTarget to the location of the installed application. WixShellExecTarget is the property Id the WixShellExec custom action expects will be set to the location of the file to run. The Value property uses the special # character to tell WiX to look up the full installed path of the keyfile for the component with the id myapplication.exe. The CustomAction element includes the action in the installer. It is given a unique Id, and the BinaryKey and DllEntry properties indicate the assembly and entry point for the custom action. The Impersonate property tells Windows Installer to run the custom action as the installing user. Step 4: Trigger the custom action Simply including the custom action, as in Step 3, isn't sufficient to cause it to run. Windows Installer must also be told when the custom action should be triggered. This is done by using the Publish element to add it to the actions run when the user clicks the Finished button on the final page of the UI dialogs. The Publish element should be included inside the UI element from Step 2, and looks like this: Publish Dialog=ExitDialog Control=Finish Event=DoAction Value=LaunchApplicationWIXUI_EXITDIALOGOPTIONALCHECKBOX = 1 and NOT Installed/Publish The Dialog property specifies the dialog the Custom Action will be attached to, in this case the ExitDialog. The Control property specifies that the Finish button on the dialog triggers the custom action. The Event property indicates that a custom action should be run when the button is clicked, and the Value property specifies the custom action that was included in Step 3. The condition on the element prevents the action from running unless the checkbox from Step 2 was checked and the application was actually installed (as opposed to being removed or repaired). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of bryan rasmussen Sent: Thursday, June 26, 2008 1:12 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] how do I start an application after install, not conditionally and not based on clicking on dialog Specifically I am
Re: [WiX-users] Votive V2008 problem on installing 3.0.4220.0
I closed VS 2008 before installing new WiX version. The problem appeared as I restarted VS, loaded solution containing the existing WiX project (among other Custom Action C++ DLL projects) and then clicked on project's Properties context menu. I recreated the project from scratch and the problem is gone. -Original Message- From: Jason Ginchereau [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2008 11:02 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Votive V2008 problem on installing 3.0.4220.0 I haven't been able to reproduce the problem with source control, though several people have reported it. It's tracked as sourceforge bug 1977311. Any further details you can provide will be helpful. Do you notice the problem after just installing WiX, or do you need to open a WiX project for it to appear? If it's the latter, does it happen for new projects or only projects created with a previous build of WiX? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Reil Sent: Wednesday, June 25, 2008 4:22 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Votive V2008 problem on installing 3.0.4220.0 I also had the problem, that SourceControl in VS2008 is not working anymore for the votive project and what's really annoying is that the automatic checkout of files on edit in other projects (e.g. a C# project) is blocked by votive. Regards, Dennis Be careful, some text editors screw up the solution file. I know Textpad for one does... I personally use VS - I just close the solution, then use 'open file' to open the sln file, clicking the down arrow on the Open button and choosing 'text editor' in VS's open dialog. Kelly Simon Dahlbacka [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 06/25/2008 01:08 AM Please respond to General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net To General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net cc Subject Re: [WiX-users] Votive V2008 problem on installing 3.0.4220.0 On Wed, Jun 25, 2008 at 10:56 AM, Baldur [EMAIL PROTECTED] wrote: Hi Neil, Is there anyway I can simply edit the solution files? - I'd rather do this than recreating a complex solution that just happens to contain a WiX project. Notepad (or other text editor of preference) works if you are brave/careful enough /Simon - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Induce Sleep in the MSI script
Is there a way to do this? I think you'd have to write a custom action. As custom actions go, this would be a very simple one. Just out of interest, why do you want to sleep during installation? Regards, John - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how do I start an application after install, not conditionally and not based on clicking on dialog
Hi Bryan,
I don't know details how you get the value of AUTOPILOT property. If that's
you installation path - use custom action type 18, if you are getting it using
AppSearch - custom action type 50. Here is the sample of type 18 (Write.exe is
from [SystemFolder] on my Vista machine):
?xml version=1.0 encoding=UTF-8?
Wix xmlns=http://schemas.microsoft.com/wix/2003/01/wi;
Product Id={0BD4334D-F9FE-4B70-8070-917288A50B51}
Name=Minimal Windows Installer Sample
Language=1033
Codepage=1252
Version=1.0.0
Manufacturer=Acme Corporation
UpgradeCode={770C5598-A538-4D44-8C2E-B2D94E15CC98}
Package Id={E1782FB0-3D87-4B13-88DC-62E11FB72552}
Description=Minimal Windows Installer Sample
Comments=This installer database contains the logic and data
required to install [ProductName].
InstallerVersion=200
Languages=1033
SummaryCodepage=1252
Platforms=Intel
ReadOnly=no
Compressed=yes
AdminImage=no
Keywords=Installer
ShortNames =no
Manufacturer=Acme Corporation /
Media Id=1 Cabinet=CAB001.cab EmbedCab=yes /
Directory Id=TARGETDIR Name=SourceDir
Directory Id=ProgramFilesFolder
Directory Id=INSTALLDIR Name=Minimal
LongName=MinimalInstallation
Component Id=Component1
Guid={A77C5B06-132D-4884-8E17-EA10A83C812D}
File Id=Write.exe DiskId=1 Name=Write.exe Source=Write.exe
Vital=yes KeyPath=yes /
File Id=ReadMe DiskId=1 Name=Readme.txt Source=Readme.txt
Vital=yes KeyPath=no /
/Component
/Directory
/Directory
/Directory
CustomAction Id=ShowReadMe
FileKey=Write.exe
ExeCommand='[#ReadMe]'
Return=asyncNoWait /
InstallExecuteSequence
Custom Action=ShowReadMe After=InstallFinalizeNot Installed/Custom
/InstallExecuteSequence
Feature Id=Feature1
Title=Feature1 title
Description=Feature1 description
Level=1
ConfigurableDirectory=INSTALLDIR
ComponentRef Id=Component1 /
/Feature
/Product
/Wix
Alex Shevchuk
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of bryan rasmussen
Sent: Thursday, June 26, 2008 1:12 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] how do I start an application after install, not
conditionally and not based on clicking on dialog
Specifically I am trying to do this:
CustomAction Id=CA1 Property=CA1_PROP
Value=[AUTOPILOT]AutoPilot.exe /
InstallExecuteSequence
InstallFinalize/
Custom Action=CA1 After=InstallFinalize /
/InstallExecuteSequence
How should that be restructured to work?
Thanks,
Bryan Rasmussen
On Thu, Jun 26, 2008 at 9:47 AM, bryan rasmussen
[EMAIL PROTECTED] wrote:
As per the subject line, it's just supposed to install and run. The
user doesn't have to click on the dialog to say that they want it to
run.
Thanks,
Bryan Rasmussen
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Induce Sleep in the MSI script
I tried putting in a custom action that used the cmd.exe sleep command to fix a problem with a service that needed to restart only to discover that not all my deployment targets had the sleep command! I later was able to abandon the sleep as we fixed the fact the service needed to be restarted. - Original Message - From: John Hall [EMAIL PROTECTED] To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Cc: Date: Thursday, June 26 2008 10:46 AM Subject: Re: [WiX-users] Induce Sleep in the MSI script Is there a way to do this? I think you'd have to write a custom action. As custom actions go, this would be a very simple one. Just out of interest, why do you want to sleep during installation? Regards, John - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] customAction running after Installfinalize not working
Here is the code: ?xml version='1.0' encoding=iso-8859-1? Wix xmlns='http://schemas.microsoft.com/wix/2003/01/wi' Product Id='12345678-1234-1234-1234-098765432114' Name='Software Innovation GrowBusiness AutoPilot' Language='1033' Version='1.0.0.0' Manufacturer='Software Innovation' Package Id='12345678-1234-1234-1234-123456789015' Description='Sample AutoPilot installation package' Comments='First example of AutoPilot installation' InstallerVersion='200' Compressed='yes' / Media Id='1' Cabinet='product.cab' EmbedCab='yes' / Directory Id='TARGETDIR' Name='SourceDir' Directory Id='ProgramFilesFolder' Name='PFiles' Directory Id='SIDir' Name='SI' LongName='SoftwareInnovation' Directory Id='AUTOPILOT' Name='autop' LongName='AutoPilot' Component Id='hotkeyfiles' Guid='12345678-1234-1234-1234-098765432114' File Id='AutoPilot' LongName='AutoPilot.exe' Name=autopilo DiskId='1' Vital=yes src='C:\projects\work\growbusinesshotkeys\version2\AutoPilot.exe' / File Id='gbsicon' Name='gbslogo.ico' DiskId='1' Vital=yes src='C:\projects\work\growbusinesshotkeys\version2\gbslogo.ico' / File Id='hotkeys1' LongName='General Soegning' Name=GenSoeg DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\General Soegning' / File Id='hotkeys2' Name=NyKor LongName='Ny KorrespondanceDokument' DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\Ny KorrespondanceDokument' / File Id='hotkeys3' Name=OpNyAkt LongName='Opret Ny Aktivitet' DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\Opret Ny Aktivitet' / File Id='hotkeys4' Name=OpNyKon LongName='Opret Ny Kontakt' DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\Opret Ny Kontakt' / File Id='hotkeys5' Name=OpNyVi LongName='Opret Ny Virksomhed' DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\Opret Ny Virksomhed' / File Id='hotkeys6' Name=SkrAdm LongName='Skrivebord Administration' DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\Skrivebord Administration' / File Id='hotkeys7' Name=SoegKon LongName='Soeg KontaktPerson' DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\Soeg KontaktPerson' / File Id='hotkeys8' Name=SoegKor LongName='Soeg Korrespondance' DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\Soeg Korrespondance' / File Id='hotkeys10' Name=help LongName='Hjaelp' DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\Hjaelp' / File Id='hotkeys9' Name=SoegVi LongName='Soeg Virksomhed' DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\Soeg Virksomhed' / File Id='hotkeys11' Name=SoegD LongName='Soeg Dokument' DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\Soeg Dokument' / File Id='graphic1' Name=backg.jpg LongName='background_ap_gui.jpg' DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\background_ap_gui.jpg' / File Id='graphic2' Name=footer LongName='footer_ap_gui.jpg' DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\footer_ap_gui.jpg' / File Id='graphic3' Name=header LongName='header_ap_gui.jpg' DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\header_ap_gui.jpg' / File Id='programconfig' Name='keys.ini' DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\keys.ini' / File Id='size1' Name=1680X1 LongName='1680X1050' DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\1680X1050' / File Id='size2' Name=1400X1 LongName='1400X1050' DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\1400X1050' / File Id='size3' Name=1280X1 LongName='1280X1024' DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\1280X1024' / File Id='size4' Name=1280X7 LongName='1280X768' DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\1280X768' / Registry Root=HKCU Key=Software\Microsoft\Windows\CurrentVersion\Run KeyPath=yes Action=write Name=SIAutoPilot Value=[AUTOPILOT]AutoPilot.exe Type=string / /Component /Directory /Directory /Directory /Directory Feature Id='hotkeys_step1' Title='GrowBusiness Hotkeys 1.0' Description='Installation package' Display='expand' Level='1' ConfigurableDirectory='AUTOPILOT' Feature Id='MainProgram' Title='Program' Description='The main executable.' Level='1' ComponentRef Id='hotkeyfiles' / /Feature /Feature CustomAction Id=CA1 Property=CA1_PROP Value=[AUTOPILOT]AutoPilot.exe / InstallExecuteSequence InstallFinalize/ Custom Action=CA1
[WiX-users] oops, it looks like my last post is being answered now.
The downfalls of receiving emails batched, and a batch coming in before people start responding. Sorry everyone. Cheers, Bryan Rasmussen - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] customAction running after Installfinalize not working
Custom Action scheduled after InstallFinalize do work. I have one that
invokes DLL exported function and, using __asm { int 3 } in my CA C++
code I get JIT debugger started.
I think your problem may be that you are expecting the action to start
the executable, while your action is just assigning one property value
to another, even if that happens to be a path tp executable file.
An example of Custom Action that runs executable can be found in, IMO,
excellent Alex's blog WiX series:
http://blogs.technet.com/alexshev/archive/2008/02/21/from-msi-to-wix-par
t-5-custom-actions.aspx
-Original Message-
From: bryan rasmussen [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 26, 2008 1:17 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] customAction running after Installfinalize not
working
Here is the code:
?xml version='1.0' encoding=iso-8859-1?
Wix xmlns='http://schemas.microsoft.com/wix/2003/01/wi'
Product Id='12345678-1234-1234-1234-098765432114' Name='Software
Innovation GrowBusiness AutoPilot' Language='1033'
Version='1.0.0.0' Manufacturer='Software Innovation'
Package Id='12345678-1234-1234-1234-123456789015'
Description='Sample AutoPilot installation package'
Comments='First example of AutoPilot installation'
InstallerVersion='200' Compressed='yes' /
Media Id='1' Cabinet='product.cab' EmbedCab='yes' /
Directory Id='TARGETDIR' Name='SourceDir'
Directory Id='ProgramFilesFolder' Name='PFiles'
Directory Id='SIDir' Name='SI'
LongName='SoftwareInnovation'
Directory Id='AUTOPILOT' Name='autop' LongName='AutoPilot'
Component Id='hotkeyfiles'
Guid='12345678-1234-1234-1234-098765432114'
File Id='AutoPilot' LongName='AutoPilot.exe'
Name=autopilo DiskId='1' Vital=yes
src='C:\projects\work\growbusinesshotkeys\version2\AutoPilot.exe' /
File Id='gbsicon' Name='gbslogo.ico' DiskId='1'
Vital=yes
src='C:\projects\work\growbusinesshotkeys\version2\gbslogo.ico'
/
File Id='hotkeys1' LongName='General Soegning'
Name=GenSoeg DiskId='1'
src='C:\projects\work\growbusinesshotkeys\version2\General Soegning'
/
File Id='hotkeys2' Name=NyKor LongName='Ny
KorrespondanceDokument' DiskId='1'
src='C:\projects\work\growbusinesshotkeys\version2\Ny
KorrespondanceDokument' /
File Id='hotkeys3' Name=OpNyAkt LongName='Opret
Ny Aktivitet' DiskId='1'
src='C:\projects\work\growbusinesshotkeys\version2\Opret Ny Aktivitet'
/
File Id='hotkeys4' Name=OpNyKon LongName='Opret
Ny Kontakt' DiskId='1'
src='C:\projects\work\growbusinesshotkeys\version2\Opret Ny Kontakt'
/
File Id='hotkeys5' Name=OpNyVi LongName='Opret Ny
Virksomhed' DiskId='1'
src='C:\projects\work\growbusinesshotkeys\version2\Opret Ny
Virksomhed' /
File Id='hotkeys6' Name=SkrAdm
LongName='Skrivebord Administration' DiskId='1'
src='C:\projects\work\growbusinesshotkeys\version2\Skrivebord
Administration' /
File Id='hotkeys7' Name=SoegKon LongName='Soeg
KontaktPerson' DiskId='1'
src='C:\projects\work\growbusinesshotkeys\version2\Soeg KontaktPerson'
/
File Id='hotkeys8' Name=SoegKor LongName='Soeg
Korrespondance' DiskId='1'
src='C:\projects\work\growbusinesshotkeys\version2\Soeg
Korrespondance' /
File Id='hotkeys10' Name=help LongName='Hjaelp' DiskId='1'
src='C:\projects\work\growbusinesshotkeys\version2\Hjaelp' /
File Id='hotkeys9' Name=SoegVi LongName='Soeg
Virksomhed' DiskId='1'
src='C:\projects\work\growbusinesshotkeys\version2\Soeg Virksomhed' /
File Id='hotkeys11' Name=SoegD LongName='Soeg
Dokument' DiskId='1'
src='C:\projects\work\growbusinesshotkeys\version2\Soeg Dokument' /
File Id='graphic1' Name=backg.jpg
LongName='background_ap_gui.jpg' DiskId='1'
src='C:\projects\work\growbusinesshotkeys\version2\background_ap_gui.jpg
'
/
File Id='graphic2' Name=footer
LongName='footer_ap_gui.jpg' DiskId='1'
src='C:\projects\work\growbusinesshotkeys\version2\footer_ap_gui.jpg'
/
File Id='graphic3' Name=header
LongName='header_ap_gui.jpg' DiskId='1'
src='C:\projects\work\growbusinesshotkeys\version2\header_ap_gui.jpg'
/
File Id='programconfig' Name='keys.ini' DiskId='1'
src='C:\projects\work\growbusinesshotkeys\version2\keys.ini' /
File Id='size1' Name=1680X1 LongName='1680X1050'
DiskId='1' src='C:\projects\work\growbusinesshotkeys\version2\1680X1050'
/
File Id='size2' Name=1400X1
LongName='1400X1050' DiskId='1'
src='C:\projects\work\growbusinesshotkeys\version2\1400X1050' /
File Id='size3' Name=1280X1
LongName='1280X1024' DiskId='1'
src='C:\projects\work\growbusinesshotkeys\version2\1280X1024' /
File Id='size4' Name=1280X7 LongName='1280X768'
DiskId='1'
Re: [WiX-users] Induce Sleep in the MSI script
I also need a sleep command during setup. What is the WiX custom action to sleep, i.e. delay operations for a certain period of time? Thanks very much! On Thu, Jun 26, 2008 at 9:46 AM, John Hall [EMAIL PROTECTED] wrote: Is there a way to do this? I think you'd have to write a custom action. As custom actions go, this would be a very simple one. Just out of interest, why do you want to sleep during installation? Regards, John - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question about $(Platform) in Votive Output name
This may seem like a silly question, but is this change global? Now my output paths are exhibiting the same escaping behavior, for non WiX projects. Was this a change in 2008, or did your change have other effects? Chris On Wed, Jun 25, 2008 at 1:42 PM, Jason Ginchereau [EMAIL PROTECTED] wrote: I'd rather see it not escaped, but that's just me. I don't even know if that's a WiX thing, or a VS2008 thing. Auto-escaping special chars is a recent change I implemented in the Votive properties dialogs. It is intended to prevent one from getting into a state where the project file can't be loaded, or is loaded incorrectly, because special characters can unintentionally confuse the parser. So, certain MSBuild special characters are auto-escaped as a %hex code when they are entered in the properties dialogs. But the $() characters should not be escaped for properties that support MSBuild variables. Currently those are: Compiler/Linker/Lib Additional Options Preprocessor Variables WiX Variables Output Path Pre/Post Build Event Output Name is not in that list, but it probably should be. I agree with your feedback that the Output Name value should allow embedded MSBuild variables. -Jason- -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Christopher Karper Sent: Wednesday, June 25, 2008 10:17 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about $(Platform) in Votive Output name So, here's the part where I answer my own question. Sheepishly, I have to admit that when I changed the .wixproj file by hand, I put in ($Platform) instead of $(Platform).. So, once that was corrected, I got the behavior I was looking for. The fact remains that the 2008 version seems to be escaping the non alphanumeric characters, but whether you consider that a bug or a feature is up to you, I guess. I'd rather see it not escaped, but that's just me. I don't even know if that's a WiX thing, or a VS2008 thing. Chris On Wed, Jun 25, 2008 at 1:00 PM, Christopher Karper [EMAIL PROTECTED] wrote: In a project I created in VS2005 I used Installer $(Platform) as my output name... It worked fine by created Installer x64.msi Now, I've converted to VS2008, and it still works fine. However, I created a new project, and set up a merge module WiX project, with Module $(Platform) as the output name, and it creates Module $(Platform).msm as the output. In the .wixproj XML, I noticed it had escaped the $() characters, so I replaced those manually and reopened it, but to no avail. It's still creating the name without replacement. Is this a change in platform functionality? Was I relying on a bug that was fixed? Is this a bug that was introduced? Am I a great big fat idiot? Any and all advice would be appreciated. :-) Thanks! Chris - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] The size of compressed Wix install comparedto InstallShield equivalent
Yep, that was it, thanks Jason! High compression shaved of 10 Mb and I accounted for the remaining 10 MB. My billboard bitmaps took only 3MB but Custom Action Dlls, while each smaller than half a megabyte, turned out to be numerous enough to take up to 7 MBs. I assume that a bunch of small DLLs that export a single function (for a single CA) is better than having a single larger Dll that would have an exported functions for each custom action. Said that, I don't think I would save much space by putting all the code in one Dll anyway. -Original Message- From: Jason Ginchereau [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2008 11:35 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] The size of compressed Wix install comparedto InstallShield equivalent You can try passing the high compression (-dcl:hi) switch to light, or setting CompressionLevel=high on your Media element. WiX by default uses a moderate compression level which provides much faster builds but is slightly less optimal. However, I doubt that increasing the compression level will make up that 20MB difference. Do you have any large bitmaps, custom action binaries, or other resources in the Binary table of the MSI? Those items don't get compressed when they're packed in the MSI, though they would when the MSI is further wrapped in an EXE as InstallShield does. If you do have large .BMP files, you can change them to .JPG or .PNG format. Beyond that I have to ask the obvious question: are you sure the set of payload files is the same? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Juricic Sent: Thursday, June 26, 2008 8:14 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] The size of compressed Wix install compared to InstallShield equivalent I have ported InstallShield (version 12) project to Wix 3. InstallShield has msi embedded in exe and the whole setup.exe is 50 MB large. Wix creates MSI with embedded compressed CAB which takes 70 MB. 20 MB is a pretty large difference! Am I missing something obvious or is InstallShield compression really that superior? Thanks - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] The size of compressed Wix install comparedto InstallShield equivalent
My memory is that a Basic MSI project with a bunch of exported InstallScript functions will compile and get linked into a single DLL with a bunch of exported functions like f1, f2, f3,f4 ectera. So the IScript runtime penalty should only be once. If you used merge modules and had installscript CA's then those would be compiled at different layers and the package bloat would increase. Do you have a dependency on the .NET Framework? Porting your code from InstallScript to C# ( or C++ if you are really inclinded ) would cut down on the size alot. Also if you dump the InstallShield UI and bring in Mondo and perhaps refactor any InstallScript standard paterns ( IIS,XML) into WiX Standard CA / Extensions then that should help also. In general, I would believe that a `properly designed` WiX package should actually be considerably smaller then an InstallShield package. Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me --- On Thu, 6/26/08, Tony Juricic [EMAIL PROTECTED] wrote: From: Tony Juricic [EMAIL PROTECTED] Subject: Re: [WiX-users] The size of compressed Wix install comparedto InstallShield equivalent To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Date: Thursday, June 26, 2008, 1:42 PM Yep, that was it, thanks Jason! High compression shaved of 10 Mb and I accounted for the remaining 10 MB. My billboard bitmaps took only 3MB but Custom Action Dlls, while each smaller than half a megabyte, turned out to be numerous enough to take up to 7 MBs. I assume that a bunch of small DLLs that export a single function (for a single CA) is better than having a single larger Dll that would have an exported functions for each custom action. Said that, I don't think I would save much space by putting all the code in one Dll anyway. -Original Message- From: Jason Ginchereau [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2008 11:35 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] The size of compressed Wix install comparedto InstallShield equivalent You can try passing the high compression (-dcl:hi) switch to light, or setting CompressionLevel=high on your Media element. WiX by default uses a moderate compression level which provides much faster builds but is slightly less optimal. However, I doubt that increasing the compression level will make up that 20MB difference. Do you have any large bitmaps, custom action binaries, or other resources in the Binary table of the MSI? Those items don't get compressed when they're packed in the MSI, though they would when the MSI is further wrapped in an EXE as InstallShield does. If you do have large .BMP files, you can change them to .JPG or .PNG format. Beyond that I have to ask the obvious question: are you sure the set of payload files is the same? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Juricic Sent: Thursday, June 26, 2008 8:14 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] The size of compressed Wix install compared to InstallShield equivalent I have ported InstallShield (version 12) project to Wix 3. InstallShield has msi embedded in exe and the whole setup.exe is 50 MB large. Wix creates MSI with embedded compressed CAB which takes 70 MB. 20 MB is a pretty large difference! Am I missing something obvious or is InstallShield compression really that superior? Thanks - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Wix3 patch / msbuild questions
Hello all. I'm new to this list and new to Wix. We have successfully integrated Wix3 into MSBUILD for two new development projects. We have an existing project that used Wix2 and has a few patches. We would like to upgrade this to Wix3 and want to be able to generate new patches off of our previous work. Where can I find more info on Wix3 patching from within MSBUILD? Would we be relegated to command line calls from MSBUILD or are tasks available for Wix3? Thanks! - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] The size of compressed Wix install comparedtoInstallShield equivalent
Thanks Christopher, That is what I expected too (for install package to be smaller) but, apparently, InstallShield is still running a tight ship and/or I am still missing something important since my MSI is still slightly larger than IS exe package and (I believe that) I did almost everything that you suggested. I have literally rewritten existing InstallScript code into Win32 C++ (striving for a minimum size/dependency) and removed all IS script dialog handling. Dialogs were done starting with Mondo and adding a few extra dialogs. I have no dependency on .NET and my CA DLLs, that encapsulate what used to be IS script, use minimal, if any, C/C++ runtime. For example, I am working with wsformat, lstrcpy and lstcat, just to avoid pulling in any string-related code from C runtime. C runtime is linked statically. The rest is basically a lot of pure Win32 API registry and folder/file management code, with some COM calls. After all, IS script is just a slightly higher-level Win32 API code. I think that my reimplementation should be smaller than any script+interpreter combination. I went with many small, instead if one large CA DLL, reasoning like this: - calling a deferred CA means that DLL gets stored in the install script, sent over to the server and then run by the server. If multiple deferred CAs are done like functions exported from a single DLL, several copies of the same and larger DLL will be present in install script. Even for immediate actions DLL gets extracted to a temporary location and then run. I think that IS size advantage may be, in part, in further compressing custom action DLLs and support DLLs. My support DLLs (these get extracted at the very beginning of installation by a CA and are available to the rest of CA code - it is, in essence, CA shared code) take about 5 MB. -Original Message- From: Christopher Painter [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2008 3:22 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] The size of compressed Wix install comparedtoInstallShield equivalent My memory is that a Basic MSI project with a bunch of exported InstallScript functions will compile and get linked into a single DLL with a bunch of exported functions like f1, f2, f3,f4 ectera. So the IScript runtime penalty should only be once. If you used merge modules and had installscript CA's then those would be compiled at different layers and the package bloat would increase. Do you have a dependency on the .NET Framework? Porting your code from InstallScript to C# ( or C++ if you are really inclinded ) would cut down on the size alot. Also if you dump the InstallShield UI and bring in Mondo and perhaps refactor any InstallScript standard paterns ( IIS,XML) into WiX Standard CA / Extensions then that should help also. In general, I would believe that a `properly designed` WiX package should actually be considerably smaller then an InstallShield package. Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me --- On Thu, 6/26/08, Tony Juricic [EMAIL PROTECTED] wrote: From: Tony Juricic [EMAIL PROTECTED] Subject: Re: [WiX-users] The size of compressed Wix install comparedto InstallShield equivalent To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Date: Thursday, June 26, 2008, 1:42 PM Yep, that was it, thanks Jason! High compression shaved of 10 Mb and I accounted for the remaining 10 MB. My billboard bitmaps took only 3MB but Custom Action Dlls, while each smaller than half a megabyte, turned out to be numerous enough to take up to 7 MBs. I assume that a bunch of small DLLs that export a single function (for a single CA) is better than having a single larger Dll that would have an exported functions for each custom action. Said that, I don't think I would save much space by putting all the code in one Dll anyway. -Original Message- From: Jason Ginchereau [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2008 11:35 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] The size of compressed Wix install comparedto InstallShield equivalent You can try passing the high compression (-dcl:hi) switch to light, or setting CompressionLevel=high on your Media element. WiX by default uses a moderate compression level which provides much faster builds but is slightly less optimal. However, I doubt that increasing the compression level will make up that 20MB difference. Do you have any large bitmaps, custom action binaries, or other resources in the Binary table of the MSI? Those items don't get compressed when they're packed in the MSI, though they would when the MSI is further wrapped in an EXE as InstallShield does. If you do have large .BMP files, you can change them to .JPG or .PNG format. Beyond
[WiX-users] Installing votive on Visual Studio Team System 2008
When I try to install wix-3.0.2925.0.msi I get the error message: Votive, the WiX project and editor package for Visual Studio, cannot be installed because Visual Studio Standard Edition or higher is not installed Yet I have Visual Studio Team System 2008 installed. Am I missing something? Thanks, Jeff - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] General Merge Module Questions
OK, I am redoing some of my installations to be in merge modules. Now, I have no idea what I'm doing, so it's kind of learn as I go. I'm stuck in a few spots, and was hoping someone out here would be kind enough to help me. :-) I am installing a .NET web application, which is why this gets complicated. * I have all the files to install. This was pretty straightforward. * I have some config changes to apply. I had this working in the .msi, but does the module have access to the public properties the containing MSI will have? Is this the preferred method of getting data, or is there some mechanism for explicitly passing the information? (something like CustomActionData for CAs) * I need to set up IIS properly. This gets complicated since I want to allow a choice for a web site, or a virtual directory installation. Also, different versions of IIS are configured differently. I don't mind having a complicated set of conditions in my MSM, I just want to avoid making an MSM for each of these conditions. Is this possible? * I am using the ASP.NET built in Membership providers, so I need to either run aspnet_config.exe, or directly run the SQL script against the datasource. Is it possible to test for the existence of this database before running either of these? Thanks in advance for any assistance... I'll take help for any or all of these questions.:-) Chris - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing votive on Visual Studio Team System 2008
Yet I have Visual Studio Team System 2008 installed. Am I missing something? Yes, you are using an old version that is pre VS 2008, get a newer one instead from http://wix.sf.net/releases - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing votive on Visual Studio Team System 2008
Thanks, Simon I guess sourceforge isn't the place to get the current release. I didn't notice the 2007 date on V3 after seeing the 2008 date on V2. Jeff On Thu, Jun 26, 2008 at 2:02 PM, Simon Dahlbacka [EMAIL PROTECTED] wrote: Yet I have Visual Studio Team System 2008 installed. Am I missing something? Yes, you are using an old version that is pre VS 2008, get a newer one instead from http://wix.sf.net/releases - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Question about $(Platform) in Votive Output name
The change applies only to WiX projects, and could not possibly affect escaping behavior in non-WiX projects. Most of the WiX project code is shared between VS2005 and VS2008, including this part. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Karper Sent: Thursday, June 26, 2008 11:40 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about $(Platform) in Votive Output name This may seem like a silly question, but is this change global? Now my output paths are exhibiting the same escaping behavior, for non WiX projects. Was this a change in 2008, or did your change have other effects? Chris On Wed, Jun 25, 2008 at 1:42 PM, Jason Ginchereau [EMAIL PROTECTED] wrote: I'd rather see it not escaped, but that's just me. I don't even know if that's a WiX thing, or a VS2008 thing. Auto-escaping special chars is a recent change I implemented in the Votive properties dialogs. It is intended to prevent one from getting into a state where the project file can't be loaded, or is loaded incorrectly, because special characters can unintentionally confuse the parser. So, certain MSBuild special characters are auto-escaped as a %hex code when they are entered in the properties dialogs. But the $() characters should not be escaped for properties that support MSBuild variables. Currently those are: Compiler/Linker/Lib Additional Options Preprocessor Variables WiX Variables Output Path Pre/Post Build Event Output Name is not in that list, but it probably should be. I agree with your feedback that the Output Name value should allow embedded MSBuild variables. -Jason- -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Christopher Karper Sent: Wednesday, June 25, 2008 10:17 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about $(Platform) in Votive Output name So, here's the part where I answer my own question. Sheepishly, I have to admit that when I changed the .wixproj file by hand, I put in ($Platform) instead of $(Platform).. So, once that was corrected, I got the behavior I was looking for. The fact remains that the 2008 version seems to be escaping the non alphanumeric characters, but whether you consider that a bug or a feature is up to you, I guess. I'd rather see it not escaped, but that's just me. I don't even know if that's a WiX thing, or a VS2008 thing. Chris On Wed, Jun 25, 2008 at 1:00 PM, Christopher Karper [EMAIL PROTECTED] wrote: In a project I created in VS2005 I used Installer $(Platform) as my output name... It worked fine by created Installer x64.msi Now, I've converted to VS2008, and it still works fine. However, I created a new project, and set up a merge module WiX project, with Module $(Platform) as the output name, and it creates Module $(Platform).msm as the output. In the .wixproj XML, I noticed it had escaped the $() characters, so I replaced those manually and reopened it, but to no avail. It's still creating the name without replacement. Is this a change in platform functionality? Was I relying on a bug that was fixed? Is this a bug that was introduced? Am I a great big fat idiot? Any and all advice would be appreciated. :-) Thanks! Chris - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing
Re: [WiX-users] Question about $(Platform) in Votive Output name
I didn't figure it would, but thought it was worth asking. :-) Thanks. Chris On Thu, Jun 26, 2008 at 5:18 PM, Jason Ginchereau [EMAIL PROTECTED] wrote: The change applies only to WiX projects, and could not possibly affect escaping behavior in non-WiX projects. Most of the WiX project code is shared between VS2005 and VS2008, including this part. -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Christopher Karper Sent: Thursday, June 26, 2008 11:40 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about $(Platform) in Votive Output name This may seem like a silly question, but is this change global? Now my output paths are exhibiting the same escaping behavior, for non WiX projects. Was this a change in 2008, or did your change have other effects? Chris On Wed, Jun 25, 2008 at 1:42 PM, Jason Ginchereau [EMAIL PROTECTED] wrote: I'd rather see it not escaped, but that's just me. I don't even know if that's a WiX thing, or a VS2008 thing. Auto-escaping special chars is a recent change I implemented in the Votive properties dialogs. It is intended to prevent one from getting into a state where the project file can't be loaded, or is loaded incorrectly, because special characters can unintentionally confuse the parser. So, certain MSBuild special characters are auto-escaped as a %hex code when they are entered in the properties dialogs. But the $() characters should not be escaped for properties that support MSBuild variables. Currently those are: Compiler/Linker/Lib Additional Options Preprocessor Variables WiX Variables Output Path Pre/Post Build Event Output Name is not in that list, but it probably should be. I agree with your feedback that the Output Name value should allow embedded MSBuild variables. -Jason- -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Christopher Karper Sent: Wednesday, June 25, 2008 10:17 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Question about $(Platform) in Votive Output name So, here's the part where I answer my own question. Sheepishly, I have to admit that when I changed the .wixproj file by hand, I put in ($Platform) instead of $(Platform).. So, once that was corrected, I got the behavior I was looking for. The fact remains that the 2008 version seems to be escaping the non alphanumeric characters, but whether you consider that a bug or a feature is up to you, I guess. I'd rather see it not escaped, but that's just me. I don't even know if that's a WiX thing, or a VS2008 thing. Chris On Wed, Jun 25, 2008 at 1:00 PM, Christopher Karper [EMAIL PROTECTED] wrote: In a project I created in VS2005 I used Installer $(Platform) as my output name... It worked fine by created Installer x64.msi Now, I've converted to VS2008, and it still works fine. However, I created a new project, and set up a merge module WiX project, with Module $(Platform) as the output name, and it creates Module $(Platform).msm as the output. In the .wixproj XML, I noticed it had escaped the $() characters, so I replaced those manually and reopened it, but to no avail. It's still creating the name without replacement. Is this a change in platform functionality? Was I relying on a bug that was fixed? Is this a bug that was introduced? Am I a great big fat idiot? Any and all advice would be appreciated. :-) Thanks! Chris - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installing votive on Visual Studio Team System 2008
http://wix.sourceforge.net/releases -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff Ratcliff Sent: Thursday, June 26, 2008 14:13 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing votive on Visual Studio Team System 2008 Thanks, Simon I guess sourceforge isn't the place to get the current release. I didn't notice the 2007 date on V3 after seeing the 2008 date on V2. Jeff On Thu, Jun 26, 2008 at 2:02 PM, Simon Dahlbacka [EMAIL PROTECTED] wrote: Yet I have Visual Studio Team System 2008 installed. Am I missing something? Yes, you are using an old version that is pre VS 2008, get a newer one instead from http://wix.sf.net/releases - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] General Merge Module Questions
I would recommend .wixlibs instead of .msm files (unless you have share your Merge Modules with people that don't use WiX). .wixlibs are far more flexible than Merge Modules. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Karper Sent: Thursday, June 26, 2008 13:59 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] General Merge Module Questions OK, I am redoing some of my installations to be in merge modules. Now, I have no idea what I'm doing, so it's kind of learn as I go. I'm stuck in a few spots, and was hoping someone out here would be kind enough to help me. :-) I am installing a .NET web application, which is why this gets complicated. * I have all the files to install. This was pretty straightforward. * I have some config changes to apply. I had this working in the .msi, but does the module have access to the public properties the containing MSI will have? Is this the preferred method of getting data, or is there some mechanism for explicitly passing the information? (something like CustomActionData for CAs) * I need to set up IIS properly. This gets complicated since I want to allow a choice for a web site, or a virtual directory installation. Also, different versions of IIS are configured differently. I don't mind having a complicated set of conditions in my MSM, I just want to avoid making an MSM for each of these conditions. Is this possible? * I am using the ASP.NET built in Membership providers, so I need to either run aspnet_config.exe, or directly run the SQL script against the datasource. Is it possible to test for the existence of this database before running either of these? Thanks in advance for any assistance... I'll take help for any or all of these questions.:-) Chris - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] The size of compressed Wix install comparedto InstallShield equivalent
Compressing an MSI in a bootstrapper can often get you impressive wins if you have a lot of data in your MSI like Jason suggests. I have a 120K MSI and my compressed bootstrapper ends up 90K total. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Juricic Sent: Thursday, June 26, 2008 11:42 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] The size of compressed Wix install comparedto InstallShield equivalent Yep, that was it, thanks Jason! High compression shaved of 10 Mb and I accounted for the remaining 10 MB. My billboard bitmaps took only 3MB but Custom Action Dlls, while each smaller than half a megabyte, turned out to be numerous enough to take up to 7 MBs. I assume that a bunch of small DLLs that export a single function (for a single CA) is better than having a single larger Dll that would have an exported functions for each custom action. Said that, I don't think I would save much space by putting all the code in one Dll anyway. -Original Message- From: Jason Ginchereau [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2008 11:35 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] The size of compressed Wix install comparedto InstallShield equivalent You can try passing the high compression (-dcl:hi) switch to light, or setting CompressionLevel=high on your Media element. WiX by default uses a moderate compression level which provides much faster builds but is slightly less optimal. However, I doubt that increasing the compression level will make up that 20MB difference. Do you have any large bitmaps, custom action binaries, or other resources in the Binary table of the MSI? Those items don't get compressed when they're packed in the MSI, though they would when the MSI is further wrapped in an EXE as InstallShield does. If you do have large .BMP files, you can change them to .JPG or .PNG format. Beyond that I have to ask the obvious question: are you sure the set of payload files is the same? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Juricic Sent: Thursday, June 26, 2008 8:14 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] The size of compressed Wix install compared to InstallShield equivalent I have ported InstallShield (version 12) project to Wix 3. InstallShield has msi embedded in exe and the whole setup.exe is 50 MB large. Wix creates MSI with embedded compressed CAB which takes 70 MB. 20 MB is a pretty large difference! Am I missing something obvious or is InstallShield compression really that superior? Thanks - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Votive V2008 problem on installing 3.0.4220.0
Jason, it sounds like there is some really strange behavior in build to build upgrades of the project. I think when people start clean it works fine but if they have an old VS project (2005 or 2008) then moving to a new project doesn't work. Is that possible? Do we need to teach WixCop to upgrade Votive projects? smile/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Juricic Sent: Thursday, June 26, 2008 09:45 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Votive V2008 problem on installing 3.0.4220.0 I closed VS 2008 before installing new WiX version. The problem appeared as I restarted VS, loaded solution containing the existing WiX project (among other Custom Action C++ DLL projects) and then clicked on project's Properties context menu. I recreated the project from scratch and the problem is gone. -Original Message- From: Jason Ginchereau [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2008 11:02 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Votive V2008 problem on installing 3.0.4220.0 I haven't been able to reproduce the problem with source control, though several people have reported it. It's tracked as sourceforge bug 1977311. Any further details you can provide will be helpful. Do you notice the problem after just installing WiX, or do you need to open a WiX project for it to appear? If it's the latter, does it happen for new projects or only projects created with a previous build of WiX? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Reil Sent: Wednesday, June 25, 2008 4:22 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Votive V2008 problem on installing 3.0.4220.0 I also had the problem, that SourceControl in VS2008 is not working anymore for the votive project and what's really annoying is that the automatic checkout of files on edit in other projects (e.g. a C# project) is blocked by votive. Regards, Dennis Be careful, some text editors screw up the solution file. I know Textpad for one does... I personally use VS - I just close the solution, then use 'open file' to open the sln file, clicking the down arrow on the Open button and choosing 'text editor' in VS's open dialog. Kelly Simon Dahlbacka [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 06/25/2008 01:08 AM Please respond to General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net To General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net cc Subject Re: [WiX-users] Votive V2008 problem on installing 3.0.4220.0 On Wed, Jun 25, 2008 at 10:56 AM, Baldur [EMAIL PROTECTED] wrote: Hi Neil, Is there anyway I can simply edit the solution files? - I'd rather do this than recreating a complex solution that just happens to contain a WiX project. Notepad (or other text editor of preference) works if you are brave/careful enough /Simon - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] EnableUserControl vs. SecureCustomProperties
The PUBLIC Properites passed across the client to server for a particular install should be logged. The problem is if you take the shortcut you are allowing *any* PUBLIC property through. Now you have to think about what every single PUBLIC property can do on the server side. Or you can just list the ones you need... smile/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jon W Sent: Thursday, June 26, 2008 09:16 To: WiX-users Subject: Re: [WiX-users] EnableUserControl vs. SecureCustomProperties Would you be able to list some of the PUBLIC properties that would be propagated and not needed/wanted? It would be nice to know what may cause issues, and why. If the properties aren't used and don't affect the certain installers, then setting EnableUserControl=1 may work well for some developers. Thank you, Jon On Wed, Jun 25, 2008 at 5:01 PM, Rob Mensching [EMAIL PROTECTED] wrote: I always do the latter. There are a lot more PUBLIC Properties than you might now and some of them could leak through data you don't need/want. Basically, minimize attack surface. -Original Message- Regarding the Vista installation issue of public properties not being passed when the registry/domain settings are set to: HKLM and HKCU Software\Policies\Microsoft\Windows\Installer AlwaysInstallElevated (DWORD) to 1 Which of the following property settings is preferred? !-- If the EnableUserControl property is set to 1, then the installer can pass all public properties to the server side during a managed installation using elevated privileges.-- Property Id=EnableUserControl Value=1 / or, add public properties to SecureCustomProperties, by the Secure option of each property such as: Property Id=MYPROPERTYNAME Secure=yes / Thanks, Jon - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] how do I start an application after install, not conditionally and not based on clicking on dialog
Also, you can be a bit more robust in your File reference by doing [#AutoPilotFileId] instead of [AUTOPILOT]AutoPilot.exe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of bryan rasmussen Sent: Thursday, June 26, 2008 01:12 To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] how do I start an application after install, not conditionally and not based on clicking on dialog Specifically I am trying to do this: CustomAction Id=CA1 Property=CA1_PROP Value=[AUTOPILOT]AutoPilot.exe / InstallExecuteSequence InstallFinalize/ Custom Action=CA1 After=InstallFinalize / /InstallExecuteSequence How should that be restructured to work? Thanks, Bryan Rasmussen On Thu, Jun 26, 2008 at 9:47 AM, bryan rasmussen [EMAIL PROTECTED] wrote: As per the subject line, it's just supposed to install and run. The user doesn't have to click on the dialog to say that they want it to run. Thanks, Bryan Rasmussen - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bug in dark.exe?
Sounds like a bug in there somewhere. Can you log it? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Rerick Sent: Wednesday, June 25, 2008 16:15 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Bug in dark.exe? I am de-compiling a MSI generated with InstallShield 11.5. I got an error on table CustomAction. I also found this link to the same problem: http://www.nabble.com/--wix-Bugs-1976057---dark-fails-on-Wise-MSI-due-to-Une xpectedColumnCount-td17552116.html When I look at the InstallShield MSI file with Orca, The CustomAction table looks just fine. I was using Wix 3.0.4214 and got the following error (and no .wxs file was generated): C:\Program Files\WixEdit\wix-3.0.4214.0\dark DB.msi DB.wxs -x db Microsoft (R) Windows Installer Xml Decompiler version 3.0.4214.0 Copyright (C) Microsoft Corporation. All rights reserved. DB.msi C:\Program Files\WixEdit\wix-3.0.4214.0\WixDifxAppExtension.dll : error DARK0143 : A parsed tuple has more fields for table 'CustomAction' than are defined. This is potentially because a standard table is being redefined as a custom table. I then tried with Wix 3.0.4014 and got the following (and a .wxs file was generated): C:\Program Files\WixEdit\wix-3.0.4014.0\dark DB.msi DB.wxs -x db Microsoft (R) Windows Installer Xml Decompiler version 3.0.4014.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. DB.msi dark.exe : warning DARK1065 : The AdvtUISequence table is not supported by the W iX toolset because it has been deprecated by the Windows Installer team. Any in formation in this table will be left out of the decompiled output. DB\DB.msi : warning DARK1060 : The ISSQLConnection table is being decompiled as a custom table. DB\DB.msi : warning DARK1060 : The ISSQLDBMetaData table is being decompiled as a custom table. DB\DB.msi : warning DARK1060 : The ISSQLConnectionDBServer table is being decompiled as a custom table. DB\DB.msi : warning DARK1060 : The ISSQLScriptFile table is being decompiled as a custom table. DB\DB.msi : warning DARK1060 : The ISSQLConnectionScript table is being decompiled as a custom table. DB\DB.msi : warning DARK1060 : The ISSQLScriptReplace table is being decompiled as a custom table. DB\DB.msi : warning DARK1062 : The ModuleComponents table can only be represented in WiX for merge modules. Th e information in this table will be left out of the decompiled output. DB.msi : warning DARK1066 : The Patch table is not directly supported by the WiX toolset because it belongs in a patch (msp) file. This table can be indirectly created by making a patch c reation (pcp) file using WiX, then using PatchWiz to create a patch (msp) file. Any information in this table will be left out of the decompiled output. DB\DB.msi : warning DARK1066 : The PatchPackage table is not directly supported by the WiX toolset because it b elongs in a patch (msp) file. This table can be indirectly created by making a patch creation (pcp) file using WiX, then using PatchWiz to create a patch (msp) file. Any information in this table will be left out of the decompiled output. dark.exe : warning DARK1058 : The AdminExecuteSequence table contains an action 'ScheduleReboot' which is not allowed in this table. If this is a standard acti on then it is not valid for this table, if it is a custom action or dialog then this table does not accept actions of that type. This action will be left out o f the decompiled output. dark.exe : warning DARK1058 : The AdvtExecuteSequence table contains an action ' RegisterTypeLibraries' which is not allowed in this table. If this is a standar d action then it is not valid for this table, if it is a custom action or dialog then this table does not accept actions of that type. This action will be left out of the decompiled output. dark.exe : warning DARK1058 : The AdvtExecuteSequence table contains an action ' ScheduleReboot' which is not allowed in this table. If this is a standard actio n then it is not valid for this table, if it is a custom action or dialog then t his table does not accept actions of that type. This action will be left out of the decompiled output. Mike Rerick Sr. Software Engineer - Professional Services blocked::http://www.iwsinc.com/ 9200 S.E. Sunnybrook Blvd., Suite 170 Clackamas, OR 97015 Phone: (503) 353-8068Fax: (503) 353-8065 The information contained in this transmission contains potentially privileged, export controlled and/or confidential information of Imageware Systems, Inc. or its customers or partners. It is intended only to be read by the person(s) named above and for no other purpose. You are hereby notified that any dissemination, distribution, duplication of this communication or use of its contents for any purpose not authorized expressly
Re: [WiX-users] Wix3 patch / msbuild questions
I don't think there are MSBuild tasks for torch/pyro yet. The build sequence is involved and Peter is still thinking about it... I think. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete Maroun Sent: Thursday, June 26, 2008 13:02 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Wix3 patch / msbuild questions Hello all. I'm new to this list and new to Wix. We have successfully integrated Wix3 into MSBUILD for two new development projects. We have an existing project that used Wix2 and has a few patches. We would like to upgrade this to Wix3 and want to be able to generate new patches off of our previous work. Where can I find more info on Wix3 patching from within MSBUILD? Would we be relegated to command line calls from MSBUILD or are tasks available for Wix3? Thanks! - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] General Merge Module Questions
But the other installations are built with InstallShield. They won't work with .wixlibs, will they? On Thu, Jun 26, 2008 at 6:01 PM, Rob Mensching [EMAIL PROTECTED] wrote: I would recommend .wixlibs instead of .msm files (unless you have share your Merge Modules with people that don't use WiX). .wixlibs are far more flexible than Merge Modules. -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Christopher Karper Sent: Thursday, June 26, 2008 13:59 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] General Merge Module Questions OK, I am redoing some of my installations to be in merge modules. Now, I have no idea what I'm doing, so it's kind of learn as I go. I'm stuck in a few spots, and was hoping someone out here would be kind enough to help me. :-) I am installing a .NET web application, which is why this gets complicated. * I have all the files to install. This was pretty straightforward. * I have some config changes to apply. I had this working in the .msi, but does the module have access to the public properties the containing MSI will have? Is this the preferred method of getting data, or is there some mechanism for explicitly passing the information? (something like CustomActionData for CAs) * I need to set up IIS properly. This gets complicated since I want to allow a choice for a web site, or a virtual directory installation. Also, different versions of IIS are configured differently. I don't mind having a complicated set of conditions in my MSM, I just want to avoid making an MSM for each of these conditions. Is this possible? * I am using the ASP.NET built in Membership providers, so I need to either run aspnet_config.exe, or directly run the SQL script against the datasource. Is it possible to test for the existence of this database before running either of these? Thanks in advance for any assistance... I'll take help for any or all of these questions.:-) Chris - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Using WIX IIS custom actions with metabase index
I need to add a virtual directory to an existing website during my application install. I would like to use the WIX WebVirtualDir custom action in order to do this. Unfortunately in order to reference an existing website I need to know the name of the website. I don't have this information, what I do have is the index to website from the IIS metabase, ie: /LM/W3SVC/1. Is there a best practice or commonly used solution in this scenario? Thanks, -Nate - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] General Merge Module Questions
You could create a bunch of wixlib's and a merge module to consume them and then consume the merge module with InstallShield. This allows you to interop with other tools while leaving the door open for pure WiX down the road. But yes, I like wixlibs better. When you get into building installs that contain thousands of merge modules, the overhead of decompressing and recompressing the modules into the installer really adds up. Also you are limited to what a merge module can express. Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me --- On Thu, 6/26/08, Christopher Karper [EMAIL PROTECTED] wrote: From: Christopher Karper [EMAIL PROTECTED] Subject: Re: [WiX-users] General Merge Module Questions To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Date: Thursday, June 26, 2008, 5:28 PM But the other installations are built with InstallShield. They won't work with .wixlibs, will they? On Thu, Jun 26, 2008 at 6:01 PM, Rob Mensching [EMAIL PROTECTED] wrote: I would recommend .wixlibs instead of .msm files (unless you have share your Merge Modules with people that don't use WiX). .wixlibs are far more flexible than Merge Modules. -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Christopher Karper Sent: Thursday, June 26, 2008 13:59 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] General Merge Module Questions OK, I am redoing some of my installations to be in merge modules. Now, I have no idea what I'm doing, so it's kind of learn as I go. I'm stuck in a few spots, and was hoping someone out here would be kind enough to help me. :-) I am installing a .NET web application, which is why this gets complicated. * I have all the files to install. This was pretty straightforward. * I have some config changes to apply. I had this working in the .msi, but does the module have access to the public properties the containing MSI will have? Is this the preferred method of getting data, or is there some mechanism for explicitly passing the information? (something like CustomActionData for CAs) * I need to set up IIS properly. This gets complicated since I want to allow a choice for a web site, or a virtual directory installation. Also, different versions of IIS are configured differently. I don't mind having a complicated set of conditions in my MSM, I just want to avoid making an MSM for each of these conditions. Is this possible? * I am using the ASP.NET built in Membership providers, so I need to either run aspnet_config.exe, or directly run the SQL script against the datasource. Is it possible to test for the existence of this database before running either of these? Thanks in advance for any assistance... I'll take help for any or all of these questions.:-) Chris - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] The size of compressed Wix install compared to InstallShield equivalent
On Thu, 26 Jun 2008 11:14:12 -0400, Tony Juricic wrote: Tony, 20 MB is a pretty large difference! Am I missing something obvious or is InstallShield compression really that superior? The first question always is whether you reference your main executable for the icon. If you do, you'll get *two* copies in the MSI, one for deployment, one for the icon only. If its size is large, the MSI will be much fatter. If this is the case, create a minimal stub (a DLL with a single resource, the icon) for the icon and use that instead. Bye, Gábor --- DEÁK JAHN, Gábor -- Budapest, Hungary E-mail: [EMAIL PROTECTED] - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Votive V2008 problem on installing 3.0.4220.0
Yes, re-using project files across certain builds seems to be problematic lately. We could hide behind a statement like it's still in beta, so expect breaking changes. But at this point that probably isn't valid because WiX 3.0 is entering stabilization and we're generally encouraging people to choose 3.0 over 2.0 for new development. The main breaking changes to the project file that I'm aware of are the introduction of platform configurations and associated removal of the 'Any CPU' platform for WiX projects. I had meant to do a better job of communicating impact of those changes on existing projects; I apologize. I'll try to put together a blog post or something as soon as I can. I hadn't thought of using WixCop to upgrade project files; I guess it's possible and we can look into it. Normally the project-loading code in the VS package should handle project file upgrades, but it didn't seem right to add special upgrade logic to handle changes that happen during the beta. I'm not aware of any further project-file breaking changes coming up. But if there are, we'll have to do a better job of testing for and avoiding problems where we can, and communicating where we can't. -Jason- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Thursday, June 26, 2008 3:09 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Votive V2008 problem on installing 3.0.4220.0 Jason, it sounds like there is some really strange behavior in build to build upgrades of the project. I think when people start clean it works fine but if they have an old VS project (2005 or 2008) then moving to a new project doesn't work. Is that possible? Do we need to teach WixCop to upgrade Votive projects? smile/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Juricic Sent: Thursday, June 26, 2008 09:45 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Votive V2008 problem on installing 3.0.4220.0 I closed VS 2008 before installing new WiX version. The problem appeared as I restarted VS, loaded solution containing the existing WiX project (among other Custom Action C++ DLL projects) and then clicked on project's Properties context menu. I recreated the project from scratch and the problem is gone. -Original Message- From: Jason Ginchereau [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2008 11:02 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Votive V2008 problem on installing 3.0.4220.0 I haven't been able to reproduce the problem with source control, though several people have reported it. It's tracked as sourceforge bug 1977311. Any further details you can provide will be helpful. Do you notice the problem after just installing WiX, or do you need to open a WiX project for it to appear? If it's the latter, does it happen for new projects or only projects created with a previous build of WiX? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Reil Sent: Wednesday, June 25, 2008 4:22 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Votive V2008 problem on installing 3.0.4220.0 I also had the problem, that SourceControl in VS2008 is not working anymore for the votive project and what's really annoying is that the automatic checkout of files on edit in other projects (e.g. a C# project) is blocked by votive. Regards, Dennis Be careful, some text editors screw up the solution file. I know Textpad for one does... I personally use VS - I just close the solution, then use 'open file' to open the sln file, clicking the down arrow on the Open button and choosing 'text editor' in VS's open dialog. Kelly Simon Dahlbacka [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 06/25/2008 01:08 AM Please respond to General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net To General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net cc Subject Re: [WiX-users] Votive V2008 problem on installing 3.0.4220.0 On Wed, Jun 25, 2008 at 10:56 AM, Baldur [EMAIL PROTECTED] wrote: Hi Neil, Is there anyway I can simply edit the solution files? - I'd rather do this than recreating a complex solution that just happens to contain a WiX project. Notepad (or other text editor of preference) works if you are brave/careful enough /Simon - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] General Merge Module Questions
I'm not sure how that would help me with any of my issues. I'm willing to use whatever structure I need, and we will be hopefully migrating everything to WiX across the board one day (Being able to automate the build is the big seller there, BTW)...But it won't be for at least a year. so, looking forward would be great, but is not the biggest concern I have, I guess. Chris On Thu, Jun 26, 2008 at 7:47 PM, Christopher Painter [EMAIL PROTECTED] wrote: You could create a bunch of wixlib's and a merge module to consume them and then consume the merge module with InstallShield. This allows you to interop with other tools while leaving the door open for pure WiX down the road. But yes, I like wixlibs better. When you get into building installs that contain thousands of merge modules, the overhead of decompressing and recompressing the modules into the installer really adds up. Also you are limited to what a merge module can express. Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me --- On Thu, 6/26/08, Christopher Karper [EMAIL PROTECTED] wrote: From: Christopher Karper [EMAIL PROTECTED] Subject: Re: [WiX-users] General Merge Module Questions To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Date: Thursday, June 26, 2008, 5:28 PM But the other installations are built with InstallShield. They won't work with .wixlibs, will they? On Thu, Jun 26, 2008 at 6:01 PM, Rob Mensching [EMAIL PROTECTED] wrote: I would recommend .wixlibs instead of .msm files (unless you have share your Merge Modules with people that don't use WiX). .wixlibs are far more flexible than Merge Modules. -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Christopher Karper Sent: Thursday, June 26, 2008 13:59 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] General Merge Module Questions OK, I am redoing some of my installations to be in merge modules. Now, I have no idea what I'm doing, so it's kind of learn as I go. I'm stuck in a few spots, and was hoping someone out here would be kind enough to help me. :-) I am installing a .NET web application, which is why this gets complicated. * I have all the files to install. This was pretty straightforward. * I have some config changes to apply. I had this working in the .msi, but does the module have access to the public properties the containing MSI will have? Is this the preferred method of getting data, or is there some mechanism for explicitly passing the information? (something like CustomActionData for CAs) * I need to set up IIS properly. This gets complicated since I want to allow a choice for a web site, or a virtual directory installation. Also, different versions of IIS are configured differently. I don't mind having a complicated set of conditions in my MSM, I just want to avoid making an MSM for each of these conditions. Is this possible? * I am using the ASP.NET built in Membership providers, so I need to either run aspnet_config.exe, or directly run the SQL script against the datasource. Is it possible to test for the existence of this database before running either of these? Thanks in advance for any assistance... I'll take help for any or all of these questions.:-) Chris - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the
Re: [WiX-users] Problem with ComponentUnregister on reinstall
Brian,
Thanks for that, it fixed the problem. I reduced the number of components by
increasing the number of files per component (that was a tedious job :)).
It's now installing and uninstalling fine.
The help was much appreciated - I've been bashing my head on the wall for weeks
trying different things to fix this problem.
Ben
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Rogers
Sent: Wednesday, 25 June 2008 3:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Problem with ComponentUnregister on reinstall
Hey Ben,
The primary error message and number is different, however, the 1402 and
1450 are return values from calls to the Windows API. Take a look at my blog
entry on the 2908 error code. You might be able to track down the resolve
with that.
http://icumove.spaces.live.com/blog/cns!FB93073C6534B681!318.entry
Hope this helps. Please let me know.
Thanks,
--
Brian Rogers
Intelligence removes complexity. - Me
http://www.codeplex.com/wixml/
On Tue, Jun 24, 2008 at 10:23 PM, Ben Greene [EMAIL PROTECTED] wrote:
Hi,
I've posted this issue before and didn't get any replies, so if there's a
better (MSI-specific?) place to post this, I'm happy to do that.
I'm having an issue with an installer I've created with WiX. I'm using the
latest weekly version, and before that was using a version 4 or 5 releases
back.
When I run the install for the first time, it runs fine.
When I uninstall for the first time, it runs fine.
I've gone through the install logs line by line for these, and they don't
seem to have any major errors.
When I try to reinstall after uninstalling, the log is identical until the
start of ProcessComponents.
After 'Executing op: ProgressTotal...', I get an error for every
ComponentUnregister (for every component in a feature I choose not to
install),
And after that on ComponentRegister for every other component.
Here is the ComponentUnregister error:
Executing op: ComponentUnregister(ComponentId={[Component
GUID]},,BinaryType=0,PreviouslyPinned=1)
1: {[Product GUID]} 2: {[Component GUID]}
Note: 1: 1402 2: UNKNOWN\Components\0009AC226832F79408503FC8C3821B12 3:
1450
[Snip - error table lookup fails]
DEBUG: Error 2909: Could not unregister component {[Component GUID]}.
On a successful install, I get 'Note: 1: 1402 2: [...] 3: 2' instead of '3:
1450'
The same happens with ComponentRegister, except that there are no 'Note's
between ComponentRegister calls. I get this on the unsuccessful install:
MSI (s) (E8:60) [15:07:59:133]: Note: 1: 1402 2:
UNKNOWN\Components\F7CC39F422EA75F42A4D338196723D7B 3: 1450
[Snip - error table lookup fails]
DEBUG: Error 2908: Could not register component
{4F93CC7F-AE22-4F57-A2D4-33186927D3B7}.
I'm not sure where 'F7CC39F422EA75F42A4D338196723D7B' comes from - it's not
a GUID from my project.
After pressing OK for the error message for every component, the install
finishes and the product works the same as the first install.
If I try to uninstall after this, I don't get any error messages, no files
or registry keys are removed.
I've found out that some similar looking problems are to do with entries in
SharedDLL key in the registry, so I checked and none of the files from my
install were in there.
If anyone has any suggestions, they would be much appreciated.
(Sorry about the long post)
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problem with ComponentUnregister on reinstall
Hey Ben,
Unfortunately the amount of components in your installation might not fix
the problem. That isn't really want my article said to do.
Here is the scenario where that will break. Another per-user package has
been installed on the machine with hundreds of components. The Component
registry key type changes. Your product is then installed on the same
machine. The previous package is removed and then yours is as well. Both
products will now experience the Windows Installer 2908 (1402 and 1450)
errors again.
There is no real work around inside an MSI for this issue except to set
ALLUSERS=1 and not allow your product to do a per-user install or
ALLUSERS=2. The amount of components are just coincidental for your
installation machine. In the wild, with other per-users installations, this
issue will occur again.
Hope that helps,
--
Brian Rogers
Intelligence removes complexity. - Me
http://www.codeplex.com/wixml/
On Thu, Jun 26, 2008 at 5:21 PM, Ben Greene [EMAIL PROTECTED] wrote:
Brian,
Thanks for that, it fixed the problem. I reduced the number of components
by increasing the number of files per component (that was a tedious job :)).
It's now installing and uninstalling fine.
The help was much appreciated - I've been bashing my head on the wall for
weeks trying different things to fix this problem.
Ben
-Original Message-
From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] On Behalf Of Brian Rogers
Sent: Wednesday, 25 June 2008 3:37 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Problem with ComponentUnregister on reinstall
Hey Ben,
The primary error message and number is different, however, the 1402 and
1450 are return values from calls to the Windows API. Take a look at my
blog
entry on the 2908 error code. You might be able to track down the resolve
with that.
http://icumove.spaces.live.com/blog/cns!FB93073C6534B681!318.entry
Hope this helps. Please let me know.
Thanks,
--
Brian Rogers
Intelligence removes complexity. - Me
http://www.codeplex.com/wixml/
On Tue, Jun 24, 2008 at 10:23 PM, Ben Greene [EMAIL PROTECTED] wrote:
Hi,
I've posted this issue before and didn't get any replies, so if there's a
better (MSI-specific?) place to post this, I'm happy to do that.
I'm having an issue with an installer I've created with WiX. I'm using
the
latest weekly version, and before that was using a version 4 or 5
releases
back.
When I run the install for the first time, it runs fine.
When I uninstall for the first time, it runs fine.
I've gone through the install logs line by line for these, and they don't
seem to have any major errors.
When I try to reinstall after uninstalling, the log is identical until
the
start of ProcessComponents.
After 'Executing op: ProgressTotal...', I get an error for every
ComponentUnregister (for every component in a feature I choose not to
install),
And after that on ComponentRegister for every other component.
Here is the ComponentUnregister error:
Executing op: ComponentUnregister(ComponentId={[Component
GUID]},,BinaryType=0,PreviouslyPinned=1)
1: {[Product GUID]} 2: {[Component GUID]}
Note: 1: 1402 2: UNKNOWN\Components\0009AC226832F79408503FC8C3821B12 3:
1450
[Snip - error table lookup fails]
DEBUG: Error 2909: Could not unregister component {[Component GUID]}.
On a successful install, I get 'Note: 1: 1402 2: [...] 3: 2' instead of
'3:
1450'
The same happens with ComponentRegister, except that there are no 'Note's
between ComponentRegister calls. I get this on the unsuccessful install:
MSI (s) (E8:60) [15:07:59:133]: Note: 1: 1402 2:
UNKNOWN\Components\F7CC39F422EA75F42A4D338196723D7B 3: 1450
[Snip - error table lookup fails]
DEBUG: Error 2908: Could not register component
{4F93CC7F-AE22-4F57-A2D4-33186927D3B7}.
I'm not sure where 'F7CC39F422EA75F42A4D338196723D7B' comes from - it's
not
a GUID from my project.
After pressing OK for the error message for every component, the install
finishes and the product works the same as the first install.
If I try to uninstall after this, I don't get any error messages, no
files
or registry keys are removed.
I've found out that some similar looking problems are to do with entries
in
SharedDLL key in the registry, so I checked and none of the files from my
install were in there.
If anyone has any suggestions, they would be much appreciated.
(Sorry about the long post)
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] General Merge Module Questions
Correct, .wixlibs won't help you there. Unfrotunately, that means you're stuck fighting with the Modularization of identities to get things to all line up. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Christopher Karper Sent: Thursday, June 26, 2008 15:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] General Merge Module Questions But the other installations are built with InstallShield. They won't work with .wixlibs, will they? On Thu, Jun 26, 2008 at 6:01 PM, Rob Mensching [EMAIL PROTECTED] wrote: I would recommend .wixlibs instead of .msm files (unless you have share your Merge Modules with people that don't use WiX). .wixlibs are far more flexible than Merge Modules. -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Christopher Karper Sent: Thursday, June 26, 2008 13:59 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] General Merge Module Questions OK, I am redoing some of my installations to be in merge modules. Now, I have no idea what I'm doing, so it's kind of learn as I go. I'm stuck in a few spots, and was hoping someone out here would be kind enough to help me. :-) I am installing a .NET web application, which is why this gets complicated. * I have all the files to install. This was pretty straightforward. * I have some config changes to apply. I had this working in the .msi, but does the module have access to the public properties the containing MSI will have? Is this the preferred method of getting data, or is there some mechanism for explicitly passing the information? (something like CustomActionData for CAs) * I need to set up IIS properly. This gets complicated since I want to allow a choice for a web site, or a virtual directory installation. Also, different versions of IIS are configured differently. I don't mind having a complicated set of conditions in my MSM, I just want to avoid making an MSM for each of these conditions. Is this possible? * I am using the ASP.NET built in Membership providers, so I need to either run aspnet_config.exe, or directly run the SQL script against the datasource. Is it possible to test for the existence of this database before running either of these? Thanks in advance for any assistance... I'll take help for any or all of these questions.:-) Chris - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] optionally removing AppData folders created by application, during uninstall
Hi guys, I have been battling with this problem for a while. I have a .Net application which saves temporary data into AppData\Roaming\Bookmarks. This folder should not HAVE to be installed by the MSI as the app will create it when needed (but I've gotten to the stage of experimentation where it seems to be easier if it is created by the MSI - the installer seems to not want to remove folders it didn't create, no matter what I do). I want this folder (and all its contents) to be removed at uninstall if REMOVEBOOKMARKS=1 (I have created a custom dialog with a checkbox that lets the user selected during uninstall whether or not to delete these temporary files). If REMOVEBOOKMARKS=0, then I don't want to delete the folder (or its contents), allowing any later installations to pick up these files... My WiX looks something like this: Property Id=REMOVEBOOKMARKS Value=0/ Directory Id=AppDataFolder Directory Id=MyApp Name=MyApp Component Id=RemoveAppData Guid=8C857E65-5EA2-4b0e-BCDA-334F030B1E4A ConditionREMOVEBOOKMARKS = 1/Condition RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\1 RegistryValue Value=MyApp Type=string KeyPath=yes / /RegistryKey CreateFolder / RemoveFolder Id=RemoveAppData On=uninstall / RemoveFile Id=RemoveAppDataFiles Name=* On=uninstall/ /Component Directory Id=Bookmarks Name=Bookmarks Component Id=AddAppDataBookmarks Guid=3494B400-3193-4226-878C-2A4EB1B86456 Permanent=yes ConditionNOT Installed/Condition RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\3 RegistryValue Value=MyApp Type=string KeyPath=yes / /RegistryKey CreateFolder / /Component Component Id=RemoveAppDataBookmarks Guid=3494B400-3193-4226-878C-2A4EB1B86455 ConditionInstalled AND REMOVEBOOKMARKS = 1/Condition RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\3 RegistryValue Value=MyApp Type=string KeyPath=yes / /RegistryKey !--CreateFolder /-- RemoveFolder Id=RemoveAppDataBookmarks On=uninstall/ RemoveFile Id=RemoveAppDataBookmarksFiles Name=* On=uninstall/ /Component /Directory /Directory /Directory The Bookrmarks folder is the one I want to stay behind if REMOVEBOOKMARKS=0. It seems, no matter what I do, I can't get it to work. If I specify Permanent on the AddAppDataBookmarks component, the NOTHING will remove it. If I DONT specify it, then no matter what I put in the component conditions, it will ALWAYS be removed... How do I set up this sort of behaviour? Thank you in advance... Adam Langley Senior Developer Tel: +64 9 486 9010 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] optionally removing AppData folders created by application, during uninstall
I second this question. I am in the same boat. Adam, Do you use the WixUI or some custom UI?/Would you be able to post your code for the UI on uninstall? Date: Fri, 27 Jun 2008 16:10:48 +1200 From: [EMAIL PROTECTED] To: WiX-users@lists.sourceforge.net Subject: [WiX-users] optionally removing AppData folders created by application, during uninstall Hi guys, I have been battling with this problem for a while. I have a .Net application which saves temporary data into AppData\Roaming\Bookmarks. This folder should not HAVE to be installed by the MSI as the app will create it when needed (but I've gotten to the stage of experimentation where it seems to be easier if it is created by the MSI - the installer seems to not want to remove folders it didn't create, no matter what I do). I want this folder (and all its contents) to be removed at uninstall if REMOVEBOOKMARKS=1 (I have created a custom dialog with a checkbox that lets the user selected during uninstall whether or not to delete these temporary files). If REMOVEBOOKMARKS=0, then I don't want to delete the folder (or its contents), allowing any later installations to pick up these files... My WiX looks something like this: Guid=8C857E65-5EA2-4b0e-BCDA-334F030B1E4A REMOVEBOOKMARKS = 1 / On=uninstall/ Guid=3494B400-3193-4226-878C-2A4EB1B86456 Permanent=yes NOT Installed / Guid=3494B400-3193-4226-878C-2A4EB1B86455 Installed AND REMOVEBOOKMARKS = 1 / On=uninstall/ The Bookrmarks folder is the one I want to stay behind if REMOVEBOOKMARKS=0. It seems, no matter what I do, I can't get it to work. If I specify Permanent on the AddAppDataBookmarks component, the NOTHING will remove it. If I DONT specify it, then no matter what I put in the component conditions, it will ALWAYS be removed... How do I set up this sort of behaviour? Thank you in advance... Adam Langley Senior Developer Tel: +64 9 486 9010 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users _ The i’m Talkathon starts 6/24/08. For now, give amongst yourselves. http://www.imtalkathon.com?source=TXT_EML_WLH_LearnMore_GiveAmongst - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] optionally removing AppData folders createdby application, during uninstall
Sure. Its pretty simple - just create your dialog, copy WixUI_Mondo (or one of the other UI sequences if you want), and insert your button publications... Compare my XML below with WixUI_Mondo.wxs and you'll see what I've changed (and inserted)... Adam Langley Senior Developer Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Fragment UI Id=UI_Mondo TextStyle Id=WixUI_Font_Normal FaceName=Tahoma Size=8 / TextStyle Id=WixUI_Font_Bigger FaceName=Tahoma Size=12 / TextStyle Id=WixUI_Font_Title FaceName=Tahoma Size=9 Bold=yes / Property Id=DefaultUIFont Value=WixUI_Font_Normal / Property Id=WixUI_Mode Value=Mondo / DialogRef Id=ErrorDlg / DialogRef Id=FatalError / DialogRef Id=FilesInUse / DialogRef Id=MsiRMFilesInUse / DialogRef Id=PrepareDlg / DialogRef Id=ProgressDlg / DialogRef Id=ResumeDlg / DialogRef Id=UserExit / Publish Dialog=ExitDialog Control=Finish Event=EndDialog Value=Return Order=9991/Publish Publish Dialog=WelcomeDlg Control=Next Event=NewDialog Value=LicenseAgreementDlg1/Publish Publish Dialog=LicenseAgreementDlg Control=Back Event=NewDialog Value=WelcomeDlg1/Publish Publish Dialog=LicenseAgreementDlg Control=Next Event=NewDialog Value=SetupTypeDlg Order=2LicenseAccepted = 1/Publish Publish Dialog=SetupTypeDlg Control=Back Event=NewDialog Value=LicenseAgreementDlg1/Publish Publish Dialog=SetupTypeDlg Control=TypicalButton Event=NewDialog Value=VerifyReadyDlg1/Publish Publish Dialog=SetupTypeDlg Control=CustomButton Event=NewDialog Value=CustomizeDlg1/Publish Publish Dialog=SetupTypeDlg Control=CompleteButton Event=NewDialog Value=VerifyReadyDlg1/Publish Publish Dialog=CustomizeDlg Control=Back Event=NewDialog Value=MaintenanceTypeDlg Order=1WixUI_InstallMode = Change/Publish Publish Dialog=CustomizeDlg Control=Back Event=NewDialog Value=SetupTypeDlg Order=2WixUI_InstallMode = InstallCustom/Publish Publish Dialog=CustomizeDlg Control=Next Event=NewDialog Value=VerifyReadyDlg1/Publish Publish Dialog=VerifyReadyDlg Control=Back Event=NewDialog Value=CustomizeDlg Order=1WixUI_InstallMode = InstallCustom/Publish Publish Dialog=VerifyReadyDlg Control=Back Event=NewDialog Value=SetupTypeDlg Order=2WixUI_InstallMode = InstallTypical OR WixUI_InstallMode = InstallComplete/Publish Publish Dialog=VerifyReadyDlg Control=Back Event=NewDialog Value=CustomizeDlg Order=3WixUI_InstallMode = Change/Publish Publish Dialog=VerifyReadyDlg Control=Back Event=NewDialog Value=RemoveBookmarksDlg Order=4WixUI_InstallMode = Repair OR WixUI_InstallMode = Remove/Publish Publish Dialog=MaintenanceWelcomeDlg Control=Next Event=NewDialog Value=MaintenanceTypeDlg1/Publish Publish Dialog=MaintenanceTypeDlg Control=ChangeButton Event=NewDialog Value=CustomizeDlg1/Publish Publish Dialog=MaintenanceTypeDlg Control=RepairButton Event=NewDialog Value=RemoveBookmarksDlg1/Publish Publish Dialog=MaintenanceTypeDlg Control=RemoveButton Event=NewDialog Value=RemoveBookmarksDlg1/Publish Publish Dialog=MaintenanceTypeDlg Control=Back Event=NewDialog Value=MaintenanceWelcomeDlg1/Publish Publish Dialog=RemoveBookmarksDlg Control=Back Event=NewDialog Value=MaintenanceTypeDlg1/Publish Publish Dialog=RemoveBookmarksDlg Control=Next Event=NewDialog Value=VerifyReadyDlg1/Publish /UI UIRef Id=WixUI_Common / /Fragment /Wix -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan Dunn Sent: Friday, 27 June 2008 5:14 p.m. To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] optionally removing AppData folders createdby application, during uninstall I second this question. I am in the same boat. Adam, Do you use the WixUI or some custom UI?/Would you be able to post your code for the UI on uninstall? Date: Fri, 27 Jun 2008 16:10:48 +1200 From: [EMAIL PROTECTED] To: WiX-users@lists.sourceforge.net Subject: [WiX-users] optionally removing AppData folders created by application, during uninstall Hi guys, I have been battling with this problem for a while. I have a .Net application which saves temporary data into AppData\Roaming\Bookmarks. This folder should not HAVE to be installed by the MSI as the app will create it when needed (but I've gotten to the stage of experimentation where it seems to be easier if it is created by the MSI - the installer seems to not want to remove folders it didn't create, no matter what I do). I want this folder (and all its contents) to be removed at uninstall if REMOVEBOOKMARKS=1 (I have created a custom dialog with a checkbox that lets the user selected during uninstall whether or not to delete these temporary files). If REMOVEBOOKMARKS=0, then I don't want to delete the folder (or its contents),
