[WiX-users] Missing Browse button in Change mode
Hello, My setup uses a slightly modified WixUI_FeatureTree and contains features which must be installed into different directories, some of which must be selected by the user. The problem is in the Change mode - the user cannot change default directories for features which he/she wants to add because there's no Browse button: Control Id=Browse Type=PushButton X=294 Y=210 Width=66 Height=17 Text=!(loc.CustomizeDlgBrowse) Publish Event=SelectionBrowse Value=BrowseDlg1/Publish Condition Action=hideInstalled/Condition Condition Action=disableInstalled/Condition /Control Is there any way to overcome this limitation? Piotr -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] NeverOverwrite attribute behavior
Hello WiX community, According to the MSI documentation, if 'NeverOverwrite' bit is set, the installer does not install or reinstall the component if a key path file or a key path registry entry for the component already exists. What about components, which refer to the parent directory as a key path? For instance, I have a component containing only IIS site definition, and it doesn't specify any file or registry key as a key path. On reinstall, its key path, which is a parent directory, exists and hence it should behave as 'NeverOverwrite'. However, I still see my website being reinstalled, resetting the custom settings to initial defaults... Is this the way IIS extension works? Is it correct (I guess, no)? Or do I simply missing the point how 'NeverOverwrite' technique works? I would appreciate your hints. Thanks, -- Yan -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] util:InternetShortcut alternatives?
Hello, What are the advantages of using util:InternetShortcut over: a) IniFile creating .url file b) .url File ? I create one link in the Start menu using IniFile, because util:InternetShortcut makes my setup 150 kB bigger, which is half of the size of my whole package. Thanks, Piotr -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to generate a .wxs from a reg files ?
Hi, I want to convert many .reg files to .wxs files. Is there an utility like heat ? thanks, Akihiro Shibuta. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] _Validation table
A quick look with a hex editor into my MSI reveals that this table is 50 kB or so. I'd be happy to drop it if it's optional, preferably with a WiX option. End users won't read Descriptions anyway, why are they so long then? Piotr Blair os...@live.com wrote: Besides what is available on MSDN (e.g. http://msdn.microsoft.com/library/aa372930.aspx) what more do you need to know? -Original Message- From: Piotr Fusik [mailto:pi...@fusik.info] Sent: Tuesday, December 01, 2009 2:39 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] _Validation table Hello, Could you please explain what's the purpose of the _Validation table in MSI files? How is the long Description column used? How much overhead does this table add to my MSI and how can I reduce it? Thank you, Piotr - --- -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] _Validation table
I think you need to keep this table to ensure others your app was ICE validated, I remember this was part of the Designed for Windows requirement or so. Best regards, Sebastian Brand Deployment consultant E-Mail: sebast...@instyler.com Blog: www.sebastianbrand.com -Original Message- From: Piotr Fusik [mailto:pi...@fusik.info] Sent: Wednesday, December 02, 2009 10:05 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] _Validation table A quick look with a hex editor into my MSI reveals that this table is 50 kB or so. I'd be happy to drop it if it's optional, preferably with a WiX option. End users won't read Descriptions anyway, why are they so long then? Piotr Blair os...@live.com wrote: Besides what is available on MSDN (e.g. http://msdn.microsoft.com/library/aa372930.aspx) what more do you need to know? -Original Message- From: Piotr Fusik [mailto:pi...@fusik.info] Sent: Tuesday, December 01, 2009 2:39 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] _Validation table Hello, Could you please explain what's the purpose of the _Validation table in MSI files? How is the long Description column used? How much overhead does this table add to my MSI and how can I reduce it? Thank you, Piotr -- --- --- -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- --- - Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to generate a .wxs from a reg files ?
Use tallow.exe from the WiX v2.0 toolset. You can then process the .wxs files you output with WiXCop.exe in WiX v3.0 to update the XML in the .wxs files from the v2.0 schema to the v3.0 schema. Unfortunately that functionality was never replicated in heat.exe even though it is the tallow.exe replacement in the v3.0 toolset. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: akihiro.shib...@jp.yokogawa.com [mailto:akihiro.shib...@jp.yokogawa.com] Sent: 02 December 2009 08:58 To: wix-users@lists.sourceforge.net Subject: [WiX-users] How to generate a .wxs from a reg files ? Hi, I want to convert many .reg files to .wxs files. Is there an utility like heat ? thanks, Akihiro Shibuta. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] _Validation table
Ok, I dropped this table with Orca and the MSI is just 19kB smaller which is no big deal (however nice for open source software where you don't care about certification). Could you please explain This table is not shipped with the installer database from the MSDN article linked below? Thanks, Piotr Sebastian Brand \(Instyler Software\) wix+us...@instyler.com wrote: I think you need to keep this table to ensure others your app was ICE validated, I remember this was part of the Designed for Windows requirement or so. Best regards, Sebastian Brand Deployment consultant E-Mail: sebast...@instyler.com Blog: www.sebastianbrand.com -Original Message- From: Piotr Fusik [mailto:pi...@fusik.info] Sent: Wednesday, December 02, 2009 10:05 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] _Validation table A quick look with a hex editor into my MSI reveals that this table is 50 kB or so. I'd be happy to drop it if it's optional, preferably with a WiX option. End users won't read Descriptions anyway, why are they so long then? Piotr Blair os...@live.com wrote: Besides what is available on MSDN (e.g. http://msdn.microsoft.com/library/aa372930.aspx) what more do you need to know? -Original Message- From: Piotr Fusik [mailto:pi...@fusik.info] Sent: Tuesday, December 01, 2009 2:39 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] _Validation table Hello, Could you please explain what's the purpose of the _Validation table in MSI files? How is the long Description column used? How much overhead does this table add to my MSI and how can I reduce it? Thank you, Piotr -- --- --- -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- --- - Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - --- -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] util:InternetShortcut alternatives?
I asked a very similar question in September last year on this list. See - http://n2.nabble.com/util-InternetShortcut-td838589.html for my question Bob Arnson's reply. More info on util:InternetShortcut on Bob A's blog at - http://www.joyofsetup.com/2008/03/18/new-wix-feature-internet-shortcuts/ Personally I go with the IniFile method. I suspect util:InternetShortcut is increasing your MSI size as it needs to include the WiXUtilExtenstion Custom Action DLL to actually create the .lnk file. Have you looked at the MSI in Orca or InstEd checked the Binary table? Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Piotr Fusik [mailto:pi...@fusik.info] Sent: 02 December 2009 08:50 To: WiX Subject: [WiX-users] util:InternetShortcut alternatives? Hello, What are the advantages of using util:InternetShortcut over: a) IniFile creating .url file b) .url File ? I create one link in the Start menu using IniFile, because util:InternetShortcut makes my setup 150 kB bigger, which is half of the size of my whole package. Thanks, Piotr -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Missing Browse button in Change mode
Remove the Condition elements in the code you pasted. That will however enable the Browse button for all Features regardless of installation status. To selectively enable it for Features which haven't been installed yet and disable it for those which have you'll have to modify the inner text of the 2 conditions accordingly. I've no idea which Properties you'd even begin to look at in this case I suspect it's not an easy thing to write. Good Luck. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Piotr Fusik [mailto:pi...@fusik.info] Sent: 02 December 2009 08:10 To: WiX Subject: [WiX-users] Missing Browse button in Change mode Hello, My setup uses a slightly modified WixUI_FeatureTree and contains features which must be installed into different directories, some of which must be selected by the user. The problem is in the Change mode - the user cannot change default directories for features which he/she wants to add because there's no Browse button: Control Id=Browse Type=PushButton X=294 Y=210 Width=66 Height=17 Text=!(loc.CustomizeDlgBrowse) Publish Event=SelectionBrowse Value=BrowseDlg1/Publish Condition Action=hideInstalled/Condition Condition Action=disableInstalled/Condition /Control Is there any way to overcome this limitation? Piotr -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] util:InternetShortcut alternatives?
Yes, util:InternetShortcut adds 150kB WixCA to the Binary table. File Id=Website.url Name=Website.url Source=Website.url / seems to work just as well as IniFile and the MSI is 0.5kB smaller. ;) You just need to generate the Component Guid, because * doesn't work. Piotr Pally Sandher pally.sand...@iesve.com wrote: I asked a very similar question in September last year on this list. See - http://n2.nabble.com/util-InternetShortcut-td838589.html for my question Bob Arnson's reply. More info on util:InternetShortcut on Bob A's blog at - http://www.joyofsetup.com/2008/03/18/new-wix-feature-internet-shortcuts/ Personally I go with the IniFile method. I suspect util:InternetShortcut is increasing your MSI size as it needs to include the WiXUtilExtenstion Custom Action DLL to actually create the .lnk file. Have you looked at the MSI in Orca or InstEd checked the Binary table? Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Piotr Fusik [mailto:pi...@fusik.info] Sent: 02 December 2009 08:50 To: WiX Subject: [WiX-users] util:InternetShortcut alternatives? Hello, What are the advantages of using util:InternetShortcut over: a) IniFile creating .url file b) .url File ? I create one link in the Start menu using IniFile, because util:InternetShortcut makes my setup 150 kB bigger, which is half of the size of my whole package. Thanks, Piotr - - Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] setupbld diagnosing?
Use a LaunchCondition in your MSI to detect for .NET 3.5 SP1 and deny installation if it's not present. See http://wix.sourceforge.net/manual-wix3/check_for_dotnet.htm Also the following page may be of use to you if you're trying to create a bootstrapper to install .NET 3.5 SP1 before running your MSI - http://wix.sourceforge.net/manual-wix3/install_dotnet.htm Both the above pages are also in the WiX.chm installed with the WiX v3.0 v3.5 toolsets. Personally I use dotnetinstaller (http://dotnetinstaller.codeplex.com/) for my bootstrapper needs as I find it is very powerful but also very simple to understand and configure the behaviour you require. However you may find something like ClickOnce or Setupbld suits your needs. Until Burn (WiX v3.5 toolset bootstrapper) is finished you'll need to look outside of the WiX toolset to fulfil your bootstrapper requirements. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: JKLists [mailto:jkli...@ifm-services.com] Sent: 02 December 2009 07:09 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] setupbld diagnosing? John L Krupka wrote: You should be able to set up preconditions on those things in the msi. Setupbld is not the place for that to the best of my knowledge. This is where my lack of understanding how MSIs work raises its head. My MSI has a condition where it needs .NET 3.5 SP1, and refuses to run if it is not installed. I need trigger the .NET setup in that case. There are also a couple of other installs that need to be run before mine. I'm under the impression that I need a bootstrapper for these things, but don't fully understand how these things work yet. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] error message for 64 bit installer on 32 bit machine
Not unless you can re-write the standard error messages thrown by error codes in Windows Installer (I'm guessing you don't work for the Windows Installer team at Microsoft so that'd be a no). See error code 1633 on http://msdn.microsoft.com/en-us/library/aa368542.aspx Note that error codes are completely different things to Windows Installer Error Messages (see http://msdn.microsoft.com/en-us/library/aa372835.aspx). You can author your own custom text for an error message using the Error UI Element in WiX (which writes to the Error table in your MSI) but you can't re-write a message for an error code thrown by msiexec. I would suggest wrapping your MSI with a bootstrapper if it's that important to handle this elegantly. That way you'll be able to write a more friendly error message rather than having to rely on the one msiexec throws. Palbinder Sandher Software Deployment IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Sunkesula, Srivardhan [mailto:srivardhan.sunkes...@netapp.com] Sent: 01 December 2009 14:57 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] error message for 64 bit installer on 32 bit machine Hi, When we try to install a 64 bit MSI on a 32 bit machine, the error message is not clear. The error message is: This installation package is not support by this processor type. Can we change this message? Thanks Regards, Srivardhan. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] setting default INSTALLDIR
i want to make single msi-file both to install or upgrade my application. i'm using different product codes and single update code for all versions and i store installation path in the registry. running the installation i want to check the registry for my records presence and if i find istallation path then i want to reinstall new version to the same path. i've tried a lot and i managed to set default installation path by searching from the registry to property INSTALLPATH: Property Id=INSTALLDIR Value=C:\MyDefaultDir\ RegistrySearch Id=RegSearch_0001 Root=HKLM Key=Software\some\path Name=InstallDir Type=raw/ /Property That worked pretty fine and the default installation path was set to the path found in registry. But i'm getting compilator warnings for that. I tried to search from registry to another property and then set INSTALLDIR to my value via Set Folder and Set Property custom actions but that didn't work. Is there any way to set the INSTALLDIR before the Select Directory dialog without warnings? Also i wonder if i can omit the Select Directory dialog if i have successfully found my installation path in registry. -- View this message in context: http://n2.nabble.com/setting-default-INSTALLDIR-tp4100396p4100396.html Sent from the wix-users mailing list archive at Nabble.com. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Pyro error
No, don't try it with the option. It converts the warning into an error. -Original Message- From: Anurag Pahwa [mailto:apa...@microsoft.com] Sent: Tuesday, December 01, 2009 6:40 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Pyro error If the warning is not causing any issues I think we can ignore that. We can take care of this in the SP1 release. No I did not. DO you want me to try it with the option? Ok let me know if you need any information. Thanks Anurag -Original Message- From: Blair [mailto:os...@live.com] Sent: Monday, November 30, 2009 11:45 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Pyro error Regarding the warning: since you released, you are stuck with the warning unless you are willing to change both filenames and the component guid (along with any registry paths you declare in that same component). Regarding the error: you don't happen to have -wx in your pyro commandline, do you? I'll try to reproduce your error here, but it may be later in the week (or even next week) before I can get to it. -Original Message- From: Anurag Pahwa [mailto:apa...@microsoft.com] Sent: Monday, November 30, 2009 7:02 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Pyro error No we don't explicitly designate the file and the first file is the FSCREG.cfg file. We did release the MSI. I did try that as well and still getting the error. -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, November 24, 2009 11:18 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Pyro error Regarding the warning: in your AdminInstall_Component component, do you explicitly designate which file is the keypath? If you don't, the first one listed often becomes the keypath. If you have already released your MSI, you might be too late to easily fix this, however. Regarding the error: to know definitively if the anti-virus is to blame, try turning off the real-time scanning right before you start your build (make sure to turn it back on right after the build finishes). If that doesn't clear the error, I'll help you keep digging. -Original Message- From: Anurag Pahwa [mailto:apa...@microsoft.com] Sent: Tuesday, November 24, 2009 9:00 AM To: Anurag Pahwa; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Pyro error Tried the WIX_TEMP and still getting the same error. pyro.exe : warning PYRO1097 : File 'FSSAClient.exe' in Component 'AdminInstall_Component' was changed, but the KeyPath file 'FSCReg.cfg' was not. This file will not be pa tched on the target system if the REINSTALLMODE does not contain 'A'. The KeyPath file should also be changed and included in your patch. C:\wix\temp\tyqlnkaz\Patch.msp : error PYRO0103 : The system cannot find the file 'C:\wix\temp\tyqlnkaz\Patch.msp'. Any ideas. -Original Message- From: Anurag Pahwa Sent: Tuesday, November 24, 2009 9:25 AM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Pyro error I'll try that. I think problem might be the FSCReg.cfg file is a non versioned file whereas the FSSACLient.exe is a versioned file. Isn't it weird that it expects the FSCReg.cfg to be changed when we change the fssaclient.exe file? I'm not removing anything from the patch. -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, November 24, 2009 2:20 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Pyro error The error may possibly be caused by anti-virus software running on your build box. Or, it might be related to the earlier warnings (I couldn't tell). Try using the WIX_TEMP environment variable to move the temp folder used and suppress that folder (the one you specify in your WIX_TEMP value) in your anti-virus. What are the changes in the AdminInstall_Component between the two builds? You shouldn't normally be adding/removing/renaming files in a minor upgrade/small update (which working patches are) inside of a component. -Original Message- From: Anurag Pahwa [mailto:apa...@microsoft.com] Sent: Monday, November 23, 2009 7:55 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Pyro error Hi Guys, I'm getting these pyro warnings and then the error. Any ideas? pyro.exe : warning PYRO1097 : File 'FSSAClient.exe' in Component 'AdminInstall_Component' was changed, but the KeyPath file 'FSCReg.cfg' was not. This file will not be pa tched on the target system if the REINSTALLMODE does not contain 'A'. The KeyPath file should also be changed and included in your patch. C:\Documents and Settings\a-anup\Local Settings\Temp\zbp-1f6q\Patch.msp : error PYRO0103 : The system cannot find the file 'C:\Documents and Settings\a-anup\Local Setting s\Temp\zbp-1f6q\Patch.msp'. Thanks Anurg
Re: [WiX-users] _Validation table
From a functionality point-of-view, the table is not considered part of the installation database (it is ignored if present by the routines involved in installation maintenance of your product). However, many administrators depend on guidance from the ICE tests and other tests which often depend on this table in determining if they will allow any given application on their networks. Being OSS or not, you still need customers for most software, and that can be valuable information that others will use in helping gauge the quality of the package being offered. I would recommend leaving it in. -Original Message- From: Piotr Fusik [mailto:pi...@fusik.info] Sent: Wednesday, December 02, 2009 2:21 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] _Validation table Ok, I dropped this table with Orca and the MSI is just 19kB smaller which is no big deal (however nice for open source software where you don't care about certification). Could you please explain This table is not shipped with the installer database from the MSDN article linked below? Thanks, Piotr Sebastian Brand \(Instyler Software\) wix+us...@instyler.com wrote: I think you need to keep this table to ensure others your app was ICE validated, I remember this was part of the Designed for Windows requirement or so. Best regards, Sebastian Brand Deployment consultant E-Mail: sebast...@instyler.com Blog: www.sebastianbrand.com -Original Message- From: Piotr Fusik [mailto:pi...@fusik.info] Sent: Wednesday, December 02, 2009 10:05 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] _Validation table A quick look with a hex editor into my MSI reveals that this table is 50 kB or so. I'd be happy to drop it if it's optional, preferably with a WiX option. End users won't read Descriptions anyway, why are they so long then? Piotr Blair os...@live.com wrote: Besides what is available on MSDN (e.g. http://msdn.microsoft.com/library/aa372930.aspx) what more do you need to know? -Original Message- From: Piotr Fusik [mailto:pi...@fusik.info] Sent: Tuesday, December 01, 2009 2:39 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] _Validation table Hello, Could you please explain what's the purpose of the _Validation table in MSI files? How is the long Description column used? How much overhead does this table add to my MSI and how can I reduce it? Thank you, Piotr -- --- --- -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- --- - Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - --- -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual
Re: [WiX-users] NeverOverwrite attribute behavior
MSDN explicitly says that the keypaths required for this flag are files and registry entries. When they are explicit they only guarantee the behavior within the scope they describe. Since you are using a directory as the keypath (and not a file) I assume the flag is being ignored, but you would have to look at a verbose debug log to be certain. The IIS extension simply checks the installation states of the component it lives inside of. It doesn't have anything to do with the keypath directly (that is Windows Installer's domain). You control the keypath (and thus the installation behavior of the IIS extension) yourself. -Original Message- From: Yan Sklyarenko [mailto:y...@sitecore.net] Sent: Wednesday, December 02, 2009 12:37 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] NeverOverwrite attribute behavior Hello WiX community, According to the MSI documentation, if 'NeverOverwrite' bit is set, the installer does not install or reinstall the component if a key path file or a key path registry entry for the component already exists. What about components, which refer to the parent directory as a key path? For instance, I have a component containing only IIS site definition, and it doesn't specify any file or registry key as a key path. On reinstall, its key path, which is a parent directory, exists and hence it should behave as 'NeverOverwrite'. However, I still see my website being reinstalled, resetting the custom settings to initial defaults... Is this the way IIS extension works? Is it correct (I guess, no)? Or do I simply missing the point how 'NeverOverwrite' technique works? I would appreciate your hints. Thanks, -- Yan -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] setting default INSTALLDIR
The warning most likely comes from the C:\ part of C:\MyDefaultDir\. Not all Windows platforms have a C: drive. You may want to find a different way to compute a default location for new installations. -Original Message- From: pushist1y [mailto:mister.p...@gmail.com] Sent: Wednesday, December 02, 2009 7:34 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] setting default INSTALLDIR i want to make single msi-file both to install or upgrade my application. i'm using different product codes and single update code for all versions and i store installation path in the registry. running the installation i want to check the registry for my records presence and if i find istallation path then i want to reinstall new version to the same path. i've tried a lot and i managed to set default installation path by searching from the registry to property INSTALLPATH: Property Id=INSTALLDIR Value=C:\MyDefaultDir\ RegistrySearch Id=RegSearch_0001 Root=HKLM Key=Software\some\path Name=InstallDir Type=raw/ /Property That worked pretty fine and the default installation path was set to the path found in registry. But i'm getting compilator warnings for that. I tried to search from registry to another property and then set INSTALLDIR to my value via Set Folder and Set Property custom actions but that didn't work. Is there any way to set the INSTALLDIR before the Select Directory dialog without warnings? Also i wonder if i can omit the Select Directory dialog if i have successfully found my installation path in registry. -- View this message in context: http://n2.nabble.com/setting-default-INSTALLDIR-tp4100396p4100396.html Sent from the wix-users mailing list archive at Nabble.com. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] setting default INSTALLDIR
C:\MyDefaultDir\ is only a default value, in usual case i'm getting actual value from registry. -- /callvote set1v1 q3tourney2 -- View this message in context: http://n2.nabble.com/setting-default-INSTALLDIR-tp4100396p4100949.html Sent from the wix-users mailing list archive at Nabble.com. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] setting default INSTALLDIR
You wrote: That worked pretty fine and the default installation path was set to the path found in registry. But i'm getting compilator warnings for that. I responded: The warning is caused by your default value, not by what may or may not already be in the registry or your pattern (which is supported). Change your default value to something that is NOT a fixed path (or get rid of it entirely) and your warning should go away. -Original Message- From: pushist1y [mailto:mister.p...@gmail.com] Sent: Wednesday, December 02, 2009 9:11 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] setting default INSTALLDIR C:\MyDefaultDir\ is only a default value, in usual case i'm getting actual value from registry. -- /callvote set1v1 q3tourney2 -- View this message in context: http://n2.nabble.com/setting-default-INSTALLDIR-tp4100396p4100949.html Sent from the wix-users mailing list archive at Nabble.com. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] _Validation table
So MSDN is wrong when it says This table is not shipped with the installer database? In that case I assume either that it's intending to say something other than what it says, or it's presuming the use of a particular toolset which strips the table. As far as WIX is concerned though, this table is shipped with the installer database unless something non-WIXy is done to strip it out after building the MSI and before shipping it. -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, December 02, 2009 4:45 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] _Validation table From a functionality point-of-view, the table is not considered part of the installation database (it is ignored if present by the routines involved in installation maintenance of your product). However, many administrators depend on guidance from the ICE tests and other tests which often depend on this table in determining if they will allow any given application on their networks. Being OSS or not, you still need customers for most software, and that can be valuable information that others will use in helping gauge the quality of the package being offered. I would recommend leaving it in. -Original Message- From: Piotr Fusik [mailto:pi...@fusik.info] Sent: Wednesday, December 02, 2009 2:21 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] _Validation table Ok, I dropped this table with Orca and the MSI is just 19kB smaller which is no big deal (however nice for open source software where you don't care about certification). Could you please explain This table is not shipped with the installer database from the MSDN article linked below? Thanks, Piotr Sebastian Brand \(Instyler Software\) wix+us...@instyler.com wrote: I think you need to keep this table to ensure others your app was ICE validated, I remember this was part of the Designed for Windows requirement or so. Best regards, Sebastian Brand Deployment consultant E-Mail: sebast...@instyler.com Blog: www.sebastianbrand.com -Original Message- From: Piotr Fusik [mailto:pi...@fusik.info] Sent: Wednesday, December 02, 2009 10:05 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] _Validation table A quick look with a hex editor into my MSI reveals that this table is 50 kB or so. I'd be happy to drop it if it's optional, preferably with a WiX option. End users won't read Descriptions anyway, why are they so long then? Piotr Blair os...@live.com wrote: Besides what is available on MSDN (e.g. http://msdn.microsoft.com/library/aa372930.aspx) what more do you need to know? -Original Message- From: Piotr Fusik [mailto:pi...@fusik.info] Sent: Tuesday, December 01, 2009 2:39 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] _Validation table Hello, Could you please explain what's the purpose of the _Validation table in MSI files? How is the long Description column used? How much overhead does this table add to my MSI and how can I reduce it? Thank you, Piotr -- --- --- -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- --- - Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- --- --- -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- --- - Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk.
[WiX-users] Logging from XML file?
Is it possible to log something to the installer log file from the XML definition? Thanks, slide -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Patching problems with alternate directories
I've been having an issue with my WiX patch which I haven't been able to find any information for. The company I work for wants to give users the freedom to install our product in a directory of their choice. We've given the installer a default directory which can be changed at install time by the user. This has worked fine up until attempting to patch the package. I successfully made a patch which patches the package without problem if it's installed to the default location, however if users choose to install the product in an alternate location and then patch the patch fails because it's still trying to change files on the default location. Any ideas on how I can dynamically set up the patch install location based on where the user installs our product? Thanks in advance. Big Jim. -- View this message in context: http://n2.nabble.com/Patching-problems-with-alternate-directories-tp4102386p4102386.html Sent from the wix-users mailing list archive at Nabble.com. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Uninstalling patch removes application files.
I ended up figuring this out on my own, it looks like the installer became corrupted somehow so rebuilding the patch from scratch corrected the issue. Not sure what caused the corruption though. Big Jim. -- View this message in context: http://n2.nabble.com/Uninstalling-patch-removes-application-files-tp4058882p4102402.html Sent from the wix-users mailing list archive at Nabble.com. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] New Custom Action Question
I am new to WiX. I have an example script working but need some help. In one of the dialogs (I didn't write), there is a pushbutton that gets a SQL path. The code for the button is below. How would I either force the button to be pushed when entering the dialog or break up these commands into a custom action and get it to run when entering the dialog. I don't mind if it runs before entering just as long as the properties are loaded once the dialog is run. Any help in code form would also really help. The button does run a custom action itself called ODBC_GetString. I think that's the part I'm getting stuck on. I don't know how to make a CustomAction run another CustomAction. Control Id=RecommendPath Type=PushButton X=40 Y=155 Width=100 Height=17 Text=Recommend Path Publish Property=ODBC_CONNECTION_STRING Value=Driver=SQL Server;Server=.;Trusted_Connection=yes; Order=11/Publish Publish Property=ODBC_SQL_QUERY Value=DECLARE @data_dir varchar(500); EXECUTE master.dbo.xp_instance_regread 'HKEY_LOCAL_MACHINE', 'SOFTWARE\Microsoft\MSSQLServer\Setup', 'SQLDataRoot', @param = @data_dir OUTPUT; SELECT @data_dir Order=11/Publish Publish Event=DoAction Value=ODBC_GetString Order=31/Publish Publish Property=MSSQL_DATABASE_MDF_PATH Value=[ODBC_SQL_RESULT]\[MSSQL_DATABASE_NAME].mdf Order=41/Publish Publish Property=MSSQL_DATABASE_LDF_PATH Value=[ODBC_SQL_RESULT]\[MSSQL_DATABASE_NAME].ldf Order=41/Publish Publish Event=SpawnDialog Value=CaErrorDlg Order=5![CDATA[CA_ERROR]]/Publish /Control Best Regards, Henry Sheldon BearWare, Inc. hshel...@bearwareinc.com -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Adding Entries to Add/Remove Programs Without MSI
Please forgive me for the off-topic question but I figured somebody here would know where I should look for an answer. I was asked today if there was any way to add entries to Add/Remove Programs *without* using a MSI. Is this possible? Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.comhttp://www.fiserv.com/ P Please consider the environment before printing this e-mail -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Registry preprocessor instruction uses 64-bit registry
I have a wix installer which collects some of its content files from installed program-files. For example, we use NLog, and the installer collects the DLL from the NLog install location. We minimize configuration by searching the registry for the location where NLog is installed, then using that value to populate a preprocessor variable, which is then used in the WiX XML. So, on our wix build properties tab, the 'define preprocessor variables' textbox looks like this: NLogInstallationPath=$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.N ETFramework\v2.0.50727\AssemblyFoldersEx\NLog); Then, the actual WiX Xml looks like this: File Id=DiagnosticsNLog Name=NLog.dll Source=$(var.NLogInstallationPath)\NLog.dll Vital=yes / This works really nicely, on a 32-bit machine. It seems that on a 64-bit machine, even though Visual Studio is running in 32-bit emulation-mode, the 64-bit hive is being used (I assume MSBuild is being triggered in a native process, i.e. 64-bit shell), and under that hive, the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\Assembly FoldersEx does not exist. instead - one must search the 32-bit sub-tree, which is this location HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50 727\AssemblyFoldersEx To overcome this, I created TWO 'defines', one for 32-bit, and one for 64-bit (one of which will always be empty), then the WiX becomes this: ?if $(env.PROCESSOR_ARCHITECTURE) = AMD64 ? File Id=DiagnosticsNLog Name=NLog.dll Source=$(var.NLog64InstallationPath)\NLog.dll Vital=yes / ?else? File Id=DiagnosticsNLog Name=NLog.dll Source=$(var.NLogInstallationPath)\NLog.dll Vital=yes / ?endif? Is this the correct way to achieve what I want (it does work), or is there a functionality/syntax that I am unaware of for taking care of this dilemma? Thanks! Adam Langley -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Logging from XML file?
Which XML file are you referring to, and what do you want to log that comes from that file? Off the top of my head I don't know of anything specific, but the answers to these questions will go a long way to getting you an answer. -Original Message- From: Slide [mailto:slide.o@gmail.com] Sent: Wednesday, December 02, 2009 11:15 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Logging from XML file? Is it possible to log something to the installer log file from the XML definition? Thanks, slide -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Registry preprocessor instruction uses 64-bit registry
That looks to me like an MSBuild question. I'm assuming that MSBuild 3.5 turns off registry redirection when reading registry keys to populate properties based on your experience, but I haven't searched MSDN to see if they describe 32/64-bit behaviors. -Original Message- From: Adam Langley [mailto:alang...@winscribe.com] Sent: Wednesday, December 02, 2009 2:30 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Registry preprocessor instruction uses 64-bit registry I have a wix installer which collects some of its content files from installed program-files. For example, we use NLog, and the installer collects the DLL from the NLog install location. We minimize configuration by searching the registry for the location where NLog is installed, then using that value to populate a preprocessor variable, which is then used in the WiX XML. So, on our wix build properties tab, the 'define preprocessor variables' textbox looks like this: NLogInstallationPath=$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.N ETFramework\v2.0.50727\AssemblyFoldersEx\NLog); Then, the actual WiX Xml looks like this: File Id=DiagnosticsNLog Name=NLog.dll Source=$(var.NLogInstallationPath)\NLog.dll Vital=yes / This works really nicely, on a 32-bit machine. It seems that on a 64-bit machine, even though Visual Studio is running in 32-bit emulation-mode, the 64-bit hive is being used (I assume MSBuild is being triggered in a native process, i.e. 64-bit shell), and under that hive, the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727\Assembly FoldersEx does not exist. instead - one must search the 32-bit sub-tree, which is this location HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v2.0.50 727\AssemblyFoldersEx To overcome this, I created TWO 'defines', one for 32-bit, and one for 64-bit (one of which will always be empty), then the WiX becomes this: ?if $(env.PROCESSOR_ARCHITECTURE) = AMD64 ? File Id=DiagnosticsNLog Name=NLog.dll Source=$(var.NLog64InstallationPath)\NLog.dll Vital=yes / ?else? File Id=DiagnosticsNLog Name=NLog.dll Source=$(var.NLogInstallationPath)\NLog.dll Vital=yes / ?endif? Is this the correct way to achieve what I want (it does work), or is there a functionality/syntax that I am unaware of for taking care of this dilemma? Thanks! Adam Langley -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patching problems with alternate directories
Are your patches MSP files performing either small updates or minor upgrades? If so, the patch application won't let you patch anywhere other than the currently installed location since the keypath of the components can't be changed without a major upgrade. -Original Message- From: XorPtr [mailto:reaper4...@gmail.com] Sent: Wednesday, December 02, 2009 1:12 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Patching problems with alternate directories I've been having an issue with my WiX patch which I haven't been able to find any information for. The company I work for wants to give users the freedom to install our product in a directory of their choice. We've given the installer a default directory which can be changed at install time by the user. This has worked fine up until attempting to patch the package. I successfully made a patch which patches the package without problem if it's installed to the default location, however if users choose to install the product in an alternate location and then patch the patch fails because it's still trying to change files on the default location. Any ideas on how I can dynamically set up the patch install location based on where the user installs our product? Thanks in advance. Big Jim. -- View this message in context: http://n2.nabble.com/Patching-problems-with-alternate-directories-tp4102386p 4102386.html Sent from the wix-users mailing list archive at Nabble.com. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding Entries to Add/Remove Programs Without MSI
MSDN documents this (a very little bit). Search for uninstall registry key. -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, December 02, 2009 2:00 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Adding Entries to Add/Remove Programs Without MSI Please forgive me for the off-topic question but I figured somebody here would know where I should look for an answer. I was asked today if there was any way to add entries to Add/Remove Programs *without* using a MSI. Is this possible? Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.comhttp://www.fiserv.com/ P Please consider the environment before printing this e-mail -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Logging from XML file?
Sorry, I meant my Product.wxs (or any other wix xml source). Generally I would just like to have something printed to the log if I did: msiexec /i myinstaller.msi /l* install.log I would like to do something like this: Component Guid=SOME-GUID-HERE Log Level=Info Message=Installing some component...MYPROPERTY=[MYPROPERTY]/ /Component Thanks, slide On Wed, Dec 2, 2009 at 6:44 PM, Blair os...@live.com wrote: Which XML file are you referring to, and what do you want to log that comes from that file? Off the top of my head I don't know of anything specific, but the answers to these questions will go a long way to getting you an answer. -Original Message- From: Slide [mailto:slide.o@gmail.com] Sent: Wednesday, December 02, 2009 11:15 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Logging from XML file? Is it possible to log something to the installer log file from the XML definition? Thanks, slide -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- slide-o-blog http://slide-o-blog.blogspot.com/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Showing custom progress in installer
In my installer I install 3rd party software like MS .net 3.5 (dotnetfx35). I have request to show progress in my pure Windows Installer while dotnetfx is installed. Of course it has its own progress bar, but my installer still shows static screen Prepare to install. During ExecuteSequence of course I cant launch dotnetfx35 installation due to the install mutex in Windows. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding Entries to Add/Remove Programs Without MSI
Thanks for the pointer. That page looks like it has enough information for my colleague. Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com Please consider the environment before printing this e-mail -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, December 02, 2009 5:41 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Adding Entries to Add/Remove Programs Without MSI MSDN documents this (a very little bit). Search for uninstall registry key. -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Wednesday, December 02, 2009 2:00 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Adding Entries to Add/Remove Programs Without MSI Please forgive me for the off-topic question but I figured somebody here would know where I should look for an answer. I was asked today if there was any way to add entries to Add/Remove Programs *without* using a MSI. Is this possible? Edwin G. Castro Software Developer - Staff Electronic Banking Services Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.comhttp://www.fiserv.com/ P Please consider the environment before printing this e-mail --- - -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users --- --- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Showing custom progress in installer
Unfortunately, not possible with those restrictions. On Wed, Dec 2, 2009 at 7:11 PM, Igor Lemsky igor.lem...@gmail.com wrote: In my installer I install 3rd party software like MS .net 3.5 (dotnetfx35). I have request to show progress in my pure Windows Installer while dotnetfx is installed. Of course it has its own progress bar, but my installer still shows static screen Prepare to install. During ExecuteSequence of course I cant launch dotnetfx35 installation due to the install mutex in Windows. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Logging from XML file?
Check out the MsiLogging property in the MSI SDK. On Wed, Dec 2, 2009 at 6:09 PM, Slide slide.o@gmail.com wrote: Sorry, I meant my Product.wxs (or any other wix xml source). Generally I would just like to have something printed to the log if I did: msiexec /i myinstaller.msi /l* install.log I would like to do something like this: Component Guid=SOME-GUID-HERE Log Level=Info Message=Installing some component...MYPROPERTY=[MYPROPERTY]/ /Component Thanks, slide On Wed, Dec 2, 2009 at 6:44 PM, Blair os...@live.com wrote: Which XML file are you referring to, and what do you want to log that comes from that file? Off the top of my head I don't know of anything specific, but the answers to these questions will go a long way to getting you an answer. -Original Message- From: Slide [mailto:slide.o@gmail.com] Sent: Wednesday, December 02, 2009 11:15 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Logging from XML file? Is it possible to log something to the installer log file from the XML definition? Thanks, slide -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- slide-o-blog http://slide-o-blog.blogspot.com/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX Roadmap
No but I've been working up to it. I'm staring down Burn right now. There have been some pretty large changes in the project that have taken a while to solidify. I wasn't talking about it in case things didn't happen (anyone remember the WiX toolset shipping in VS then not? Yeah, me too.). I'm out for a few days coming up and hope everything is locked when I get back. Anyway, the original schedule looks something like: WiX v3.5 ships a month or two after VS2010 ships with the following key features: 1. Visual Studio 2010 support. 2. Burn. We're clearly way off my original schedule ( http://robmensching.com/blog/posts/2009/7/14/Lets-talk-about-Burn) but I'm pretty sure WiX v3.5 ships before this time next year. WiX v4.0 comes next. Full feature set is far from worked out but there are two things I know I want to do: 1. Code clean up. Just like the beginning of WiX v3.0, we need to spend some significant time cleaning up the code (the Binder in particular did not fare well in all the patching changes). 2. WiX language simplifications. You can see things that we've done around the File element and the auto-generated Component GUIDs. In WiX v4, there is more to do and in v4 we'll have the freedom to introduce breaking changes if necessary. Of course, we'll update WixCop.exe just like we did in WiX v2 - WiX v3. Feedback welcome. On Mon, Nov 30, 2009 at 1:33 PM, Neil Sleightholm n...@x2systems.comwrote: Is there an up to date WiX Roadmap that shows how the development / features are planned to arrive over the next year or so? Regards Neil Neil Sleightholm X2 Systems Limited n...@x2systems.com mailto:n...@x2systems.com -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] IIS virtual directory
Why not use the WixIisExtension. It will correctly support upgrade, patching and rollback which your script below won't. smile/ On Mon, Nov 30, 2009 at 7:46 AM, Chris Carlson ccarl...@npr.org wrote: I need to create a tree of virtual directories in IIS. The root of the tree will refer to directories installed by my package, but I need at least one folder in the tree to refer to a directory not installed by my package; this could be a local folder or a network share. Is there a way to create virtual directories for arbitrary local folders or network shares with IIsExtension? I tried creating a VBScript CA to configure directories using the IIS ADSI provider, but it doesn't set any properties on the directories when called by the Windows Installer. Calling the same script using cscript or wscript configures the virtual directories as expected. The relevant portion of my VBScript CA code is as follows: --BEGIN-- Set oParent = GetObject(IIS://localhost/W3SVC/1/Root/MyApplication) Set oVDir = oParent.Create(IIsWebVirtualDir, data) oVDir.Put Path, Session.Property(DATA_FOLDER_PATH) oVDir.Put AccessRead, True oVDir.Put UNCUserName, Session.Property(IIS_USERNAME) oVDir.Put UNCPassword, Session.Property(IIS_PASSWORD) oVDir.SetInfo --END-- Any assistance would be appreciated. I'm using WiX 3.0 and I'm in no way attached to my VBScript CA. Thanks Chris -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] merge module schemata differences error halts nmake
38 is correct now (32 is an old incorrect value). The easiest way to solve this problem is to use the EnsureTable element for the Extension table. The WiX toolset will then use its definition (which is correct) for the column before the Merge Module is merged and fix the error. On Mon, Nov 30, 2009 at 6:28 PM, Alan Sinclair alan.sincl...@citrix.comwrote: I'm recoding a package in WiX. It includes a load of redistributable merge modules, and there are two different schemata defining the Feature and Feature_ columns. Light.exe gives this error: error LGHT0204 : ICE32: Possible Mis-Aligned Foreign Keys, Feature.1 = s38, Extension.Feature_ = s32 (oddly the error seems to be issued only for some of the differences; many are unreported.) The command line is light -ext WixUIExtension myfile.wixobj Which is correct string length for the Feature column, 32 or 38? Nmake halts the build when light exits. Is it safe to suppress the error (via light's command line switch)? Or should I go through the MSMs and adjust their schemata so all match? If they should be changed, is there an easier way than doing each individually in Orca? Thanks -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] NativeImage Priority=0 does not work
Can you please ensure a bug is open so this issue can be fixed? Thanks. On Mon, Nov 30, 2009 at 10:54 AM, John Vottero jvott...@mvpsi.com wrote: When specifying Priority=0 on the NativeImage extension, the installation properly executes an ngen command with no /queue qualifier and the native image is successfully generated but, at the end of the install the NativeImage extension executes an ngen update /queue command which deletes all of the native images and queues an update. The result is that native images are not available when the installation is complete. This is WiX V3.0.5405. The following is a fragment of the ngen.log file which shows the JAMSScheduler.exe image being generated and showing that it is missing at the end of the installation. I added comments enclosed in []. 11/25/2009 18:32:43 [3560]: Command line: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ngen.exe install C:\Program Files\MVPSI\JAMS\Scheduler\JAMSScheduler.exe 11/25/2009 18:32:43 [3560]: Installing assembly C:\Program Files\MVPSI\JAMS\Scheduler\JAMSScheduler.exe 11/25/2009 18:32:44 [3560]: Compiling assembly C:\Program Files\MVPSI\JAMS\Scheduler\JAMSScheduler.exe ... [other images from the installation are compiled] 11/25/2009 18:33:09 [3020]: Command line: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ngen.exe install C:\Program Files\MVPSI\JAMS\Agent\JAMSHost32.exe 11/25/2009 18:33:09 [3020]: Installing assembly C:\Program Files\MVPSI\JAMS\Agent\JAMSHost32.exe 11/25/2009 18:33:10 [3020]: All compilation targets are up to date. 11/25/2009 18:33:10 [3020]: ngen returning 0x 11/25/2009 18:33:10 [3704]: Command line: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ngen.exe update /queue 11/25/2009 18:33:10 [3704]: ngen returning 0x [That's the end of the NGEN commands executed by the MSI] [The following commands were entered by me to figure out what is going wrong] 11/25/2009 18:34:16 [2712]: Command line: ngen queue status 11/25/2009 18:34:16 [2712]: ngen returning 0x 11/25/2009 18:34:31 [804]: Command line: ngen display jamsscheduler 11/25/2009 18:34:31 [804]: Error: The specified assembly is not installed. 11/25/2009 18:34:31 [804]: ngen returning 0x 11/25/2009 18:34:37 [3768]: Command line: ngen display jamsshr 11/25/2009 18:34:37 [3768]: Error: The specified assembly is not installed. 11/25/2009 18:34:37 [3768]: ngen returning 0x [And some commands I entered later to verify that an update does delete everything] 11/30/2009 13:03:15 [10728]: Command line: ngen display jamswin 11/30/2009 13:03:15 [10728]: NGEN Roots: 11/30/2009 13:03:15 [10728]: C:\Program Files\MVPSI\JAMS\Client\JAMSWin.exe 11/30/2009 13:03:15 [10728]: NGEN Roots that depend on jamswin: 11/30/2009 13:03:15 [10728]: C:\Program Files\MVPSI\JAMS\Client\JAMSWin.exe 11/30/2009 13:03:15 [10728]: Native Images: 11/30/2009 13:03:15 [10728]: JAMSWin, Version=4.8.83.0, Culture=neutral, PublicKeyToken=7da961def3057cf2 11/30/2009 13:03:15 [10728]: ngen returning 0x 11/30/2009 13:04:46 [10936]: Command line: ngen update /queue 11/30/2009 13:04:47 [10936]: ngen returning 0x 11/30/2009 13:04:52 [10984]: Command line: ngen display jamswin 11/30/2009 13:04:52 [10984]: Error: The specified assembly is not installed. 11/30/2009 13:04:52 [10984]: ngen returning 0x -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] wix upgrade issue.
Your assembly is not loading. There could be a myriad of reasons causing that. You'll need to debug the assembly loading issue first. Searching the internet should give you the tools to debug assembly load failures. On Tue, Dec 1, 2009 at 2:53 AM, MYFLEX shrinuen...@gmail.com wrote: we have upgrade all the visual studio projects to visual studio 2008 But In Build machine we have visual studio 2005 and Wix 3.0.5419(Wix is upgrade from Wix3.0.2925). I have not upgraded Visual studio 2008 in build server. I installed .NET Framework3.5 and compiling all the .net projects. we have wixextension project, and is compiled in Visual studio 2008. This dll is used to compile the wix projects. But when I try to compile the wix projects , It is giving the error as follows. candle.exe : error CNDL0307: Either 'Microsoft.Tools.WindowsInstallerXml.Assemb lyDefaultWixExtensionAttribute' was not defined in the assembly or the type def ined in extension 'C:\C# Source\ProductDeployment.Wix.Extension\bin\Release\ProductDeployment.Wix.Exten sion.dll' could not be loaded. is it because of the dll compiled with .net framework3.5 version ? should I install Visual studio 2008 also in build machine? Please let me know what is the correct solution for it. -- View this message in context: http://n2.nabble.com/wix-upgrade-issue-tp4092985p4092985.html Sent from the wix-users mailing list archive at Nabble.com. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Custom Action From Merge Module
Hmm, this line is very confusing to me: CustomAction Id=Run_CustomAction.DDD8E6B5_8ADA_481F_B19D_55E2FFFAE621 Property=CustomAction.DDD8E6B5_8ADA_481F_B19D_55E2FFFAE621 Error=Merge Module Custom Action Failed Return=check/ I don't know what that would do. Maybe it will try to set the value of a Property to nothing or maybe it'll show an Error message. I'm a little surprised it compiles. I'm so confused I'm not sure what to suggest. On Fri, Nov 20, 2009 at 8:36 AM, Adrian Faciu adrian.fa...@iqstorm.comwrote: Hi and thanks for reading this, I have a Merge Module, developed with InstallShiled, which i include in my WIX project. The merge module has a custom action that calls a function from a certain C# library, included in the merge module, to add some entries to the registry. The problem is that in the log i can see the custom action being executed but i'm pretty sure that the function is not called since nothing happens. The log sais just that: Action ended 18:02:11: Run_CustomAction.DDD8E6B5_8ADA_481F_B19D_55E2FFFAE621. Return value 1. and no other adition info. I found no official info about how to use custom actions from within merge module. Here's a piece from my code: CustomAction Id=Run_CustomAction.DDD8E6B5_8ADA_481F_B19D_55E2FFFAE621 Property=CustomAction.DDD8E6B5_8ADA_481F_B19D_55E2FFFAE621 Error=Merge Module Custom Action Failed Return=check/ InstallExecuteSequence Custom Action=Run_CustomAction.DDD8E6B5_8ADA_481F_B19D_55E2FFFAE621 After=RegisterProduct Overridable=no/ /InstallExecuteSequence Where CustomAction is the name of the custom action and DDD8E6B5_8ADA_481F_B19D_55E2FFFAE621 is the GUID of the merge module that i'm using. I really hope that someone could help me since i'm just beginning to work with WIX. Thanks, Adrian Faciu http://www.iqstorm.com/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ProductLanguage property not included in transformation (created using Torch.exe)
Was this ever resolved? Are you really getting an error message talking about patching while using torch? On Fri, Nov 20, 2009 at 12:46 AM, Stefan Pavlik stefan.pav...@gmail.comwrote: Hi all I have problem that is described on: http://sourceforge.net/tracker/?func=detailatid=642714aid=2887011group_id=105970 In short: Language transformation created using command: torch.exe -t language Package_EN.msi Package_DE.msi -out 1031.mst does not contain the ProductLanguage property. I have received following answer: you need to add the PropertyRef to the PatchFamily element for a patch to include it in the patch. PatchFamily is a filter (and defines a patch family for the resulting MSP). The answer results in another question: I do not want to create the MSP file. I want to create the MST transformation that will (after applying to MSI) change the ProductLanguage property (and all the texts). Is it possible using torch.exe? Thanks Stefan -- Stefan Pavlik | stefan.pav...@gmail.com Lietavska 14 | 851 06 Bratislava | Slovak Republic -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to patch elements in InstallExecuteSequence table?
Did this ever get resolved? On Fri, Nov 20, 2009 at 1:01 PM, Sharat Janapareddy sharat.janapare...@microsoft.com wrote: We made some changes to the MSI installer that was released this year and we are releasing the SP soon. One of those changes include adding support to uninstall the patches. For this, we modified some Custom elements in InstallExecuteSequence table of the MSI generating WXS file. (I am not sure if these are the same as CustomActions though!) Anyway, how do we specify in the Patch.wxs that these Custom elements need to be patched? For instance, here's the change which says that we should not run this action when uninstalling the patch - Custom Action='_GetServiceState' After='_SetADName'![CDATA[Installed And REMOVEALL And Not MSIPATCHREMOVE ]]/Custom And here's how I listed it in the Patch.wxs - PatchFamily Id=AgentPatchFamily Version=1.0.0.1 Supersede=yes !-- Nothing here as of now -- CustomActionRef Id=_GetServiceState / /PatchFamily I have also tried this way - Fragment InstallExecuteSequence Custom Action=_GetServiceState After=_SetADName / InstallServices Sequence=5800 / DeleteServices Sequence=2000 / /InstallExecuteSequence /Fragment However in both the cases, when I generated the patch and applied it to the release MSI through ORCA, I don't see this change at all! Another similar issue is with InstallServices and DeleteServices elements of the same InstallExecuteSequence table. Can someone tell me if this is the right way to do this? Thanks, Sharat Janapareddy ~ 40269 -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Force upgrade of a file in the GAC regardless ofthe version number
Update the AssemblyFileVersion is the only way I know.
On Mon, Nov 23, 2009 at 11:13 AM, Mike Dion md...@vertical.com wrote:
I have an application which needs to install new bits for
Interop.FOOBARLib.DLL to the GAC. The problem is that the version
number is the same as the old version and the new bits do not get
written the GAC on an upgrade. We execute the RemoveExistingProducts
action after the InstallFinalize action.
We cannot move the RemoveExistingProducts action to earlier in the
install.
The foobar.dll component is not my component so I cannot increment the
type library version (which would cause the version of the interop to
increment).
Is there a way to FORCE the file to be upgraded in the GAC even if the
version is the same? I want behavior similar to gacutil.exe /f.
The component looks like:
Component Id=Interop.FOOBARLib.dll
Guid={4E0C173E-34DF-4249-A3A6-5530047FA65B}
File Id=Interop. FOOBARLib.dll Name=Interop.FOOBARLib.dll
KeyPath=yes Assembly=.net/
/Component
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
virtually, Rob Mensching - http://RobMensching.com LLC
--
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing.
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to find which files cause patch to force the reboot?
The MSI log file usually says what file causes the reboot. On Tue, Nov 24, 2009 at 3:46 PM, Tony Juricic tjuri...@tradestation.comwrote: I have verbose log and this is all the extra info that I find about the cause of the reboot: MSI (s) (4C:E8) [18:33:27:219]: RESTART MANAGER: Did detect that the client process of this installation holds file[s] in use, so a reboot will be necessary. Is there any way to find out which files MSI sees as being in use? My program is definitely not running as I can see in Task Manager. Message that is displayed in a MessageBox is not much more informative. I hoped to see the list of files in use but instead I just get this generic message saying: The setup must update files or services that cannot be updated while the system is running. If you choose to continue, a reboot will be required to complete the setup. Reboot that ensues does not even give user the option (as normally happens otherwise) to close open applications. I have applied quite few patches so far and this problem did not occur. It started with the latest patch application and I am quite at loss, after making sure that my program is not running, what could have suddenly caused MSI to see it as holding files open. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Platform Identification in WIX 3.0
Hi, I am facing issues when migrating the managed code from x86 to x64 platform. I have a WIX project to create a MSI which will be executed through Bootstrapper. On x86 Platform, files get copied in Program Files as per the Project.wxs file. But if the same MSI is installed on x64 Platform through Bootstrapper, all the installation files get copied by default in Program Files (x86) and the application's functionality got failed as it could not find the necessary files in 12-hive hierarchy of Program Files(for 64-bit it is C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\CONFIG). I have tried using preprocessor variables like ?if $(var.ProcessorArchitecture)=x64 ? but I need to hardcode this variable in project property to either x86 or x64. Finally I end up with two different MSIs for two different platforms which is not a desirable solution for me. So, through WIX , is it possible to identify the Platform to ensure installation at desired location ? Thanks, Vishwajit READER BEWARE: Unencrypted, unsigned Internet e-mail is inherently insecure. Internet messages may be corrupted, incomplete, misdirected or may incorrectly identify the sender. Therefore, nothing in this message or attachments may be considered legally binding. THIS MESSAGE IS ONLY INTENDED FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY BE PRIVILEGED. If you are not the intended recipient or their authorized agent, you may not forward or copy this information and must delete or destroy all copies of this message and attachments received. If you have received this communication in error, please notify Matrikon Inc. by telephone at (780) 448-1010 or emailing ad...@matrikon.com. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Logging from XML file?
You present a database of how you wish the world to be configured for your installation. Windows Installer takes that database and creates a script from it. That script first analyzes which components need what (to be installed, upgraded, repaired, removed) and then a script is written by checking the impact of each of the component's resources, then the script is run (in resource-order, not component-order). Let me illustrate with a simple-yet-contrived simplistic example: MSI File: Component A File A1 Registry R1 Component B Registry R2 Registry R3 Component C File C1 File C2 Registry R4 Imagine that in this example Component B was already installed from another product, and Component C is upgrading from a previous product installation (Component A is new). Windows Installer first determines that Component A and C will be installed, and B will be left alone. Then it will look to see if any registry entries need to be removed due to components that are being either installed or removed, and those get written into the script (none in our example). Then any files that need to be removed for similar reasons (none in our example). Then any files that need to be written from components being installed (A1, C1, C2), then any registry entries (R4). That is what all of the actions sequenced between InstallInitialize and InstallFinalize do. So, the built script for our example will have 4 entries in this order: Write File A1 Write File C1 - overwriting whatever may have already been there Write File C2 - overwriting whatever may have already been there Write Registry R1 Write Registry R4 - overwriting whatever may have already been there So, there is no moment of installing Component A (with everything in it) vs. a different moment of installing Component C (with everything in that), for instance. The conversion from described state to actual state is caused by this analysis of components (the atomic units of installation) and the resources connected to those components and is the heart of Windows Installer's state engine. It is possible to send messages to the UI and/or to the log to show state (that is how you can get Installing Files.. or even Installing path-of-file messages. In fact, the UI and the logging share the same code inside the Installer engine, so anything that can be sent to the one can be sent in a similar way to the other (for the most part). The question becomes one of when in the script you want it sent. -Original Message- From: Slide [mailto:slide.o@gmail.com] Sent: Wednesday, December 02, 2009 6:09 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Logging from XML file? Sorry, I meant my Product.wxs (or any other wix xml source). Generally I would just like to have something printed to the log if I did: msiexec /i myinstaller.msi /l* install.log I would like to do something like this: Component Guid=SOME-GUID-HERE Log Level=Info Message=Installing some component...MYPROPERTY=[MYPROPERTY]/ /Component Thanks, slide On Wed, Dec 2, 2009 at 6:44 PM, Blair os...@live.com wrote: Which XML file are you referring to, and what do you want to log that comes from that file? Off the top of my head I don't know of anything specific, but the answers to these questions will go a long way to getting you an answer. -Original Message- From: Slide [mailto:slide.o@gmail.com] Sent: Wednesday, December 02, 2009 11:15 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Logging from XML file? Is it possible to log something to the installer log file from the XML definition? Thanks, slide -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- slide-o-blog http://slide-o-blog.blogspot.com/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend
Re: [WiX-users] How to find which files cause patch to force the reboot?
Look for 1603 and 1903 INFO-type messages. You may need to add the x along with the rest of v* or voicewarmup (depending on how you are specifying the things to log) to get them but somewhere it will log telling you exactly which files are causing the reboot. So either voicewarmupx or v*x. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, December 02, 2009 9:35 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to find which files cause patch to force the reboot? The MSI log file usually says what file causes the reboot. On Tue, Nov 24, 2009 at 3:46 PM, Tony Juricic tjuri...@tradestation.comwrote: I have verbose log and this is all the extra info that I find about the cause of the reboot: MSI (s) (4C:E8) [18:33:27:219]: RESTART MANAGER: Did detect that the client process of this installation holds file[s] in use, so a reboot will be necessary. Is there any way to find out which files MSI sees as being in use? My program is definitely not running as I can see in Task Manager. Message that is displayed in a MessageBox is not much more informative. I hoped to see the list of files in use but instead I just get this generic message saying: The setup must update files or services that cannot be updated while the system is running. If you choose to continue, a reboot will be required to complete the setup. Reboot that ensues does not even give user the option (as normally happens otherwise) to close open applications. I have applied quite few patches so far and this problem did not occur. It started with the latest patch application and I am quite at loss, after making sure that my program is not running, what could have suddenly caused MSI to see it as holding files open. TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Platform Identification in WIX 3.0
You build one MSI for 32-bit platforms (they can't install into 64-bit locations) and another MSI for 64-bit platforms (which cannot be opened on 32-bit platforms). It is a limitation of Windows Installer. -Original Message- From: Vishwajit Walke [mailto:vishwajit.wa...@matrikon.com] Sent: Wednesday, December 02, 2009 9:34 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Platform Identification in WIX 3.0 Hi, I am facing issues when migrating the managed code from x86 to x64 platform. I have a WIX project to create a MSI which will be executed through Bootstrapper. On x86 Platform, files get copied in Program Files as per the Project.wxs file. But if the same MSI is installed on x64 Platform through Bootstrapper, all the installation files get copied by default in Program Files (x86) and the application's functionality got failed as it could not find the necessary files in 12-hive hierarchy of Program Files(for 64-bit it is C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\CONFIG). I have tried using preprocessor variables like ?if $(var.ProcessorArchitecture)=x64 ? but I need to hardcode this variable in project property to either x86 or x64. Finally I end up with two different MSIs for two different platforms which is not a desirable solution for me. So, through WIX , is it possible to identify the Platform to ensure installation at desired location ? Thanks, Vishwajit READER BEWARE: Unencrypted, unsigned Internet e-mail is inherently insecure. Internet messages may be corrupted, incomplete, misdirected or may incorrectly identify the sender. Therefore, nothing in this message or attachments may be considered legally binding. THIS MESSAGE IS ONLY INTENDED FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY BE PRIVILEGED. If you are not the intended recipient or their authorized agent, you may not forward or copy this information and must delete or destroy all copies of this message and attachments received. If you have received this communication in error, please notify Matrikon Inc. by telephone at (780) 448-1010 or emailing ad...@matrikon.com. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] [SPAM] - Re: Custom Action From Merge Module - Email found in subject
Thanks, Indeed there was a problem with that line, and with the others. It looks like WIX does not know how to look into a merge module created with InstallShield to see what is in there so the custom action always failed. I had to point the custom action to a binary file that is created at compile time by WIX and use a standard custom action. The code gets a little weird but it works without any problems. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Thursday, December 03, 2009 7:28 AM To: General discussion for Windows Installer XML toolset. Subject: [SPAM] - Re: [WiX-users] Custom Action From Merge Module - Email found in subject Hmm, this line is very confusing to me: CustomAction Id=Run_CustomAction.DDD8E6B5_8ADA_481F_B19D_55E2FFFAE621 Property=CustomAction.DDD8E6B5_8ADA_481F_B19D_55E2FFFAE621 Error=Merge Module Custom Action Failed Return=check/ I don't know what that would do. Maybe it will try to set the value of a Property to nothing or maybe it'll show an Error message. I'm a little surprised it compiles. I'm so confused I'm not sure what to suggest. On Fri, Nov 20, 2009 at 8:36 AM, Adrian Faciu adrian.fa...@iqstorm.comwrote: Hi and thanks for reading this, I have a Merge Module, developed with InstallShiled, which i include in my WIX project. The merge module has a custom action that calls a function from a certain C# library, included in the merge module, to add some entries to the registry. The problem is that in the log i can see the custom action being executed but i'm pretty sure that the function is not called since nothing happens. The log sais just that: Action ended 18:02:11: Run_CustomAction.DDD8E6B5_8ADA_481F_B19D_55E2FFFAE621. Return value 1. and no other adition info. I found no official info about how to use custom actions from within merge module. Here's a piece from my code: CustomAction Id=Run_CustomAction.DDD8E6B5_8ADA_481F_B19D_55E2FFFAE621 Property=CustomAction.DDD8E6B5_8ADA_481F_B19D_55E2FFFAE621 Error=Merge Module Custom Action Failed Return=check/ InstallExecuteSequence Custom Action=Run_CustomAction.DDD8E6B5_8ADA_481F_B19D_55E2FFFAE621 After=RegisterProduct Overridable=no/ /InstallExecuteSequence Where CustomAction is the name of the custom action and DDD8E6B5_8ADA_481F_B19D_55E2FFFAE621 is the GUID of the merge module that i'm using. I really hope that someone could help me since i'm just beginning to work with WIX. Thanks, Adrian Faciu http://www.iqstorm.com/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users orge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Delta patching a very large binary file.
The older technology (the one used by Windows Installer) is called PatchAPI (patchapi.h) and the newer one (not used by Windows Installer) is called MSDelta (msdelta.h) Both are described in this paper: http://msdn.microsoft.com/library/bb417345.aspx. You can see the clear advantages of MSDelta over PatchAPI, but I don't see a clear path for Windows Installer to transition. PatchAPI may have a bit more detail in this older paper: http://msdn.microsoft.com/library/ms811406.aspx but I doubt it. The newer paper pretty much simply adds to the older one. -Original Message- From: Darren Grant [mailto:therealklu...@gmail.com] Sent: Tuesday, November 24, 2009 11:24 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Delta patching a very large binary file. OK I determined the files are PE. The state of MS delta tech integration is really useful to know. Can you reveal the name of the new delta tech for keeping tabs? It seems that a third-party option will be required at this time. Thank you for your insights! --Darren On Mon, Nov 23, 2009 at 11:24 PM, Blair os...@live.com wrote: PE/PE+ question is referring to the files you are trying to ship the deltas of (your huge files). PE is the 32-bit binary file format Microsoft uses for .exe, .dll, etc. files. It is also the file format used for most .NET files. PE+ is the 64-bit binary file format Microsoft uses for the same file types. mspatch[c/a] are optimized for 32-bit binary files and are alleged to not be as efficient with 64-bit files. Microsoft has a newer delta-style technology/API that they want everyone to use instead of mspatch[c/a], but Windows Installer (for legacy reasons) is stuck using the older technology/API. -Original Message- From: Darren Grant [mailto:therealklu...@gmail.com] Sent: Monday, November 23, 2009 10:44 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Delta patching a very large binary file. Hi Blair, I did not supply mspatchc with the pdb, but I will try this as well as the dll's from a few other SDK versions. By PE/+ are you referring to the mspatch tools? These were 32-bit. Thank you, Darren On Mon, Nov 23, 2009 at 6:46 PM, Blair os...@live.com wrote: One additional question: are the binary files PE or PE+? mspatchc/mspatcha are documented to work better with 32-bit (PE) than 64-bit (PE+) files. -Original Message- From: Blair [mailto:os...@live.com] Sent: Monday, November 23, 2009 6:43 PM To: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Delta patching a very large binary file. Were you able to supply mspatchc with the symbols file (*.pdb) for the binary? It is documented to be able to better compress files when the PDB is supplied. I don't know what definition of better they mean, but you could try it both ways (with and without the PDBs). Unfortunately Windows Installer uses mspatcha to apply the delta to the file(s), and that doesn't appear to be overridable. If you can find a replacement for mspatchc that doesn't fail with the large files that produces output compatible with mspatcha (assuming mspatcha can deal with files that big), I can help you with the binder extension you would need to build your delta patches. Also mspatchc/mspatcha come from Windows (mspatchc in the SDK and mspatcha in Windows itself). You could try changing the mspatchc/mspatcha versions to see if the windows build/sdk they come from make any difference. -Original Message- From: Darren Grant [mailto:therealklu...@gmail.com] Sent: Monday, November 23, 2009 1:25 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Delta patching a very large binary file. Hi, I am new to WiX and MSI programming in general, coming from an imperative NSIS background where I used vpatch to apply delta patches to large ( 500-MB) binary files. Deferring to the experts out there, how do you achieve this with WiX? :) Unfortunately the files are too large for mspatchc and it just creates a replacement instead of a delta after almost a couple hours of processing. Thank you! --Darren -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what
Re: [WiX-users] WiX Script repository status...
Are you referring to WiX-contrib? (http://wixcontrib.codeplex.com/) I'm sure contributions are welcome. -Original Message- From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: Thursday, November 19, 2009 8:18 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] WiX Script repository status... Just wondering if there is any sort of update on the WiX Script repository that a few people talked about a few months ago. How can we submit scripts. I've got some scripts which I've built up over the last few months, which I think others could find useful. DOMINIQUE LOUIS | IS DEVELOPER, AMX DIGITAL MEDIA GROUP AMX AMX UK Auster Road Clifton Moor York, North Yorkshire United Kingdom YO30 4GD +44 (0) 1904 343100 office +44 (0) 1904 343101 fax AMX South 6th Floor Salisbury House London Wall London United Kingdom EC2M 5QQ +44 (0) 2076 529450 office +44 (0) 8701 991661 fax AMX Belgium Boerenkrijglaan, 96a B-2260 Westerlo Belgium + 32 (0) 1454 2763 office + 32 (0) 1454 2766 fax ## Attention: This e-mail message is privileged and confidential. If you are not the intended recipient please delete the message and notify the sender. Any views or opinions presented are solely those of the author. This email was scanned and cleared by NetIQ MailMarshal. ## -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] SQL Script sequencing/committing issues
Was this ever addressed? -Original Message- From: Jason Jibben [mailto:jason_jib...@starkey.com] Sent: Wednesday, November 18, 2009 8:46 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] SQL Script sequencing/committing issues Hello WiX-Users, I've been working on an installer that uses quite a few SQL scripts that are triggered based on conditions set during the UI prompts. The issue I've been having is that the SQL statements that are scheduled with a lower sequence number doesn't seem to be fired off (or completed) by the time the next statement is fired. The WiX code I use is rather basic, mostly copy/pasted from tutorial sites. The one change I did make that made a difference is: I set up a DB pointer for each script. By doing so the error went away, but recently I found out our testers have found instances where the error returned on slower machines and/or slower connections to a remote DB. I dislike doing this because it is redundant, and rather ugly. Is there a way to force a delay or check for a commit result before continuing to the next item in the sequence? Using latest build of WiX 3.0 I have about 45 scripts, and 20-23 will run on each install. I've omitted the majority of them, but the error usually comes while running the scripts in SQLBulk. The error refers to an object not existing that should have been created in a previous Script. Having one pointer to a DB will always cause the error. Having separated pointers allows the install to complete on most, but not all machines (as stated before). Thanks. Sample code: Component Id=DBSQL Guid=GUID IS HERE sql:SqlDatabase Id=DBSQL User=SQLUser Database=Foo Server=[SQLSERVERNAME] CreateOnInstall=yes DropOnUninstall=no sql:SqlScript Id=DBSQL.sql ExecuteOnInstall=yes BinaryKey=DBSQL Sequence=1 User=SQLUser/ /sql:SqlDatabase ConditionNEWDB = Yes AND SQLEXPRESS=No/Condition /Component Component Id=DBSQLExpress Guid=GUID IS HERE sql:SqlDatabase Id=DBSQLExpress User=SQLUser Database=Foo Server=[SQLSERVERNAME] CreateOnInstall=yes DropOnUninstall=no sql:SqlScript Id=DBSQLExpress.sql ExecuteOnInstall=yes BinaryKey=DBSQLExpress Sequence=1 User=SQLUser/ /sql:SqlDatabase ConditionNEWDB = Yes AND SQLEXPRESS=Yes/Condition /Component Component Id=SQLCreateFooDB Guid=GUID IS HERE sql:SqlScript SqlDb=FooDB01 Id=FooDB.sql ExecuteOnInstall=yes BinaryKey=FooDB Sequence=2 User=SQLUser/ ConditionNEWDB = Yes/Condition /Component Component Id=SQLReplication Guid=GUID IS HERE sql:SqlScript SqlDb=FooDB01 Id=DropReplicationSubscriberOnClient.sql ExecuteOnInstall=yes BinaryKey=drpRepSubClnt Sequence=2 User=SQLUser/ sql:SqlScript SqlDb=FooDB23 Id=ReplicationSubscriberOnClient.sql ExecuteOnInstall=yes BinaryKey=RepSubClient Sequence=20 User=SQLUser/ ConditionReplication=Yes/Condition /Component Component Id=SQLReplicationNewDB Guid=GUID IS HERE sql:SqlScript SqlDb=FooDB02 User=SQLUser Id=ReinitializeReplicationSubscriberOnClient.sql ExecuteOnInstall=no ExecuteOnReinstall=yes BinaryKey=ReInRepSubClnt Sequence=21/ ConditionReplication = Yes AND NEWDB = Yes/Condition /Component Component Id=SQLBulk Guid=GUID IS HERE sql:SqlScript SqlDb=FooDB04 User=SQLUser Id=x701UpdateFooDB.sql ExecuteOnInstall=yes BinaryKey=xVerUpdateDB Sequence=3/ sql:SqlScript SqlDb=FooDB05 User=SQLUser Id=MasterObjects.sql ExecuteOnInstall=yes BinaryKey=MasterObjects Sequence=4/ sql:SqlScript SqlDb=FooDB06 User=SQLUser Id=Functions.sql ExecuteOnInstall=yes BinaryKey=Functions Sequence=5/ sql:SqlScript SqlDb=FooDB07 User=SQLUser Id=FunctionsSpecial.sql ExecuteOnInstall=yes BinaryKey=FunctionsSpecial Sequence=6/ sql:SqlScript SqlDb=FooDB08 User=SQLUser Id=Views.sql ExecuteOnInstall=yes BinaryKey=Views Sequence=7/ sql:SqlScript SqlDb=FooDB09 User=SQLUser Id=ViewsSpecial.sql ExecuteOnInstall=yes BinaryKey=ViewsSpecial Sequence=9/ sql:SqlScript SqlDb=FooDB10 User=SQLUser Id=Triggers.sql ExecuteOnInstall=yes BinaryKey=Triggers Sequence=10/ sql:SqlScript SqlDb=FooDB11 User=SQLUser Id=ProceduresGenerated.sql ExecuteOnInstall=yes BinaryKey=ProcGen Sequence=11/ sql:SqlScript SqlDb=FooDB12 User=SQLUser Id=Procedures.sql ExecuteOnInstall=yes BinaryKey=Procedures Sequence=12/ sql:SqlScript SqlDb=FooDB13 User=SQLUser Id=ProceduresSpecial.sql ExecuteOnInstall=yes BinaryKey=ProceduresSpecial Sequence=13/ sql:SqlScript SqlDb=FooDB14 User=SQLUser Id=ActivityReportFunctions.sql ExecuteOnInstall=yes BinaryKey=ActRepFunct Sequence=14/ sql:SqlScript SqlDb=FooDB15 User=SQLUser Id=InitializeSecurity.sql ExecuteOnInstall=yes
Re: [WiX-users] File searching and SourceDir
I haven't seen any more traffic on this, but if it is still an issue, I noticed that if AppSearch runs in InstallUISequence it is suppressed in InstallExecuteSequence, so any properties you are using that aren't UI-only should probably be marked Secure as well. Also, AppSearch properties should always be PUBLIC properties. -Original Message- From: Nick Ball [mailto:nick.b...@grantadesign.com] Sent: Tuesday, November 03, 2009 2:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] File searching and SourceDir Ah yes, you are right, looking in the log, I can see that ResolveSource happens, but my property is never set. And so the feature is set to Request: Null, Action: Null. Now the full UI log sets all the search property in AppSearch. This doesn't happen in passive mode. Why not? BTW, I know the score with ResolveSource, but need a 'modular' configuration for production where they can take out features by just removing CAB files. As a consequence, I've disabled the 'change' option. -N -Original Message- From: Blair [mailto:os...@live.com] Sent: 02 November 2009 21:59 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] File searching and SourceDir I don't understand how ResolveSource (which looks for your installation MSI) applies to your situation. (ResolveSource in effect is a no-op in initial installations, since the source was supplied to begin with, and is used to ensure access to the non-stripped MSI during maintenance installations such as patching, repairs, and removals. It is generally frowned upon, intended for use when you want to error out early when you know you will need access to the source). Look at a verbose debug log and see what properties you have set in each sequence. Then backtrack in that same log to see where things are going wrong (feature state or filesearch). -Original Message- From: Nick Ball [mailto:nick.b...@grantadesign.com] Sent: Monday, November 02, 2009 10:07 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] File searching and SourceDir Hi All, I'm trying to write some conditional feature code, based on whether a certain file is available on the installation media. I've been setting a property like this: Property Id=Feature1 DirectorySearch Id=Feature1 Path=[SourceDir] FileSearch Id=Feature1 Name=feature1.cab/ /DirectorySearch /Property And then using it like this: Feature Id=Feature1 Title=Feature1 Level=1 Condition Level=0NOT Installed AND Feature1=/Condition .. /Feature This works, provided the installation has a UI. But when run in silent mode, this feature does not get installed. How can I schedule ResolveSource so that my property has the right value? Cheers Nick -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
