[WiX-users] Accessing Regsitry Values from an Immediate Custom Action
Hello, I have a wix based installer that writes some registry values using the standard wix registry element a bit like: RegistryValue Action=write Type=string Root=HKMU Key=Software\Company\Key Name=KeyName Value=1/ Is it possible for me to be able to read these values from a *immediate* custom action? If so when do I need to schedule it? I've currently got an immediate custom action that is scheduled *after WriteRegistryValues* but it doesn't seem to be able to read the written entries: RegOpenKeyEx returns ERROR_FILE_NOT_FOUND when trying to open the relevant key with read access. Custom action xml is: CustomAction Id=MyCustomAction Impersonate=yes Return=ignore Execute=immediate BinaryKey=MyCustomActionDll DllEntry=MyCustomAction / and the sequencing is: InstallExecuteSequence Custom Action=MyCustomAction After=WriteRegistryValuesNOT Installed/Custom /InstallExecuteSequence *Other Notes* * In the example ALLUSERS is 1 so the registry values will end up in the HKEY_LOCAL_MACHINE key. * As a result of the above the installation is given elevated privileges. * I've got the custom action's impersonate value set to yes as there are various pieces of user information I want to access from the CA. AFAIK this shouldn't be an issue as long as I only want to *read* keys from HKEY_LOCAL_MACHINE, which is the case. Any modification happens in the HKEY_CURRENT_USER key. *Environment* * Compiled using Wix v3.5 * Installing on a Windows 7 Enterprise (SP1) machine -- Liam -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Protect installed msi files
Thanks for the info Rob! Below is what I found in the decompiled old msi, is any of it relevant? And im afraid even if you point out what is relevant I would not know what to do with that in Wix, do you know what I would need to specify in Wix to make the self-healing happen for a File, Component or a Feature? ... assuming I do not have to toggle self-healing at Product level / assuming self-healing is not all or nothing per msi. CustomAction Id=ERRCA_UIANDADVERTISED Error=[VSDUIANDADVERTISED] / Custom Action=ERRCA_UIANDADVERTISED Sequence=5ProductState=1/Custom AdvertiseExecuteSequence CostInitialize Sequence=800 / CostFinalize Sequence=1000 / Custom Action=DIRCA_TARGETDIR Sequence=750TARGETDIR=/Custom InstallValidate Sequence=1400 / InstallInitialize Sequence=1500 / CreateShortcuts Sequence=4500 / RegisterClassInfo Sequence=4600 / RegisterExtensionInfo Sequence=4700 / RegisterMIMEInfo Sequence=4900 / RegisterProgIdInfo Sequence=4800 / PublishComponents Sequence=6200 / PublishFeatures Sequence=6300 / PublishProduct Sequence=6400 / InstallFinalize Sequence=6600 / MsiPublishAssemblies Sequence=6250 / /AdvertiseExecuteSequence -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 30 April 2012 01:17 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Protect installed msi files Self-healing is a feature of the Windows Installer. There are several ways to get it to kick in. The most common is through Advertised entry points. You might decompile your old VS setup/deployment project and see if it has things Advertised or otherwise organized differently. You could also get a verbose log file from the repair operations and see what was used in the past to kick off the self-healing. On Sun, Apr 29, 2012 at 2:01 PM, Kristjan Laane kristjan.la...@gmail.comwrote: Hello again When I used to create my msis through Visual Studio Setup and Deployment projects then these installers protected the files that got installed i.e. if I installed the application and then manually deleted a file (such as an included image content file) then when the next time the main executable was run this deleted file got restored i.e. the msi was found in the Windows store and it repaired my installation. With Wix this protection is not present any more. I think that is better for some of the (optional) files that are installed, but I would like to protect some of my dll's as before - do you know how I could do that in Wix? Atb, Kristjan P.S. My msi's were always per machine, but now are per user, so this may be the difference that is actually causing the lack of protection? If that is the case, is it still possible to protect certain File / Component / Feature elements when deploying per user msi's ? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Protect installed msi files
Or perhaps something in here?: InstallExecuteSequence Custom Action=DIRCA_CheckFX Sequence=1 / Custom Action=ERRCA_CANCELNEWERVERSION Sequence=201NEWERPRODUCTFOUND AND NOT Installed/Custom Custom Action=VSDCA_VsdLaunchConditions Sequence=399NOT Installed/Custom Custom Action=DIRCA_TARGETDIR Sequence=750TARGETDIR=/Custom LaunchConditions Sequence=400NOT Installed/LaunchConditions FindRelatedProducts Sequence=200 / AppSearch Sequence=100 / CCPSearch Sequence=500NOT Installed/CCPSearch RMCCPSearch Sequence=600NOT Installed/RMCCPSearch ValidateProductID Sequence=700 / CostInitialize Sequence=800 / FileCost Sequence=900 / IsolateComponents Sequence=950RedirectedDllSupport/IsolateComponents CostFinalize Sequence=1000 / SetODBCFolders Sequence=1100NOT Installed/SetODBCFolders InstallValidate Sequence=1400 / InstallInitialize Sequence=1500 / AllocateRegistrySpace Sequence=1550NOT Installed/AllocateRegistrySpace ProcessComponents Sequence=1600 / UnpublishComponents Sequence=1700 / UnpublishFeatures Sequence=1800 / StopServices Sequence=1900VersionNT/StopServices DeleteServices Sequence=2000VersionNT/DeleteServices UnregisterComPlus Sequence=2100 / SelfUnregModules Sequence=2200 / UnregisterTypeLibraries Sequence=2300 / RemoveODBC Sequence=2400 / UnregisterFonts Sequence=2500 / RemoveRegistryValues Sequence=2600 / UnregisterClassInfo Sequence=2700 / UnregisterExtensionInfo Sequence=2800 / UnregisterProgIdInfo Sequence=2900 / UnregisterMIMEInfo Sequence=3000 / RemoveIniValues Sequence=3100 / RemoveShortcuts Sequence=3200 / RemoveEnvironmentStrings Sequence=3300 / RemoveDuplicateFiles Sequence=3400 / RemoveFiles Sequence=3500 / RemoveFolders Sequence=3600 / CreateFolders Sequence=3700 / MoveFiles Sequence=3800 / InstallFiles Sequence=4000 / DuplicateFiles Sequence=4210 / PatchFiles Sequence=4090 / BindImage Sequence=4300 / CreateShortcuts Sequence=4500 / RegisterClassInfo Sequence=4600 / RegisterExtensionInfo Sequence=4700 / RegisterProgIdInfo Sequence=4800 / RegisterMIMEInfo Sequence=4900 / WriteRegistryValues Sequence=5000 / WriteIniValues Sequence=5100 / WriteEnvironmentStrings Sequence=5200 / RegisterFonts Sequence=5300 / InstallODBC Sequence=5400 / RegisterTypeLibraries Sequence=5500 / SelfRegModules Sequence=5600 / RegisterComPlus Sequence=5700 / InstallServices Sequence=5800VersionNT/InstallServices StartServices Sequence=5900VersionNT/StartServices RegisterUser Sequence=6000 / RegisterProduct Sequence=6100 / PublishComponents Sequence=6200 / PublishFeatures Sequence=6300 / PublishProduct Sequence=6400 / InstallFinalize Sequence=6600 / RemoveExistingProducts Sequence=6550 / InstallExecute Sequence=6500 / MsiPublishAssemblies Sequence=6250 / MsiUnpublishAssemblies Sequence=1650 / /InstallExecuteSequence -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 30 April 2012 01:17 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Protect installed msi files Self-healing is a feature of the Windows Installer. There are several ways to get it to kick in. The most common is through Advertised entry points. You might decompile your old VS setup/deployment project and see if it has things Advertised or otherwise organized differently. You could also get a verbose log file from the repair operations and see what was used in the past to kick off the self-healing. On Sun, Apr 29, 2012 at 2:01 PM, Kristjan Laane kristjan.la...@gmail.comwrote: Hello again When I used to create my msis through Visual Studio Setup and Deployment projects then these installers protected the files that got installed i.e. if I installed the application and then manually deleted a file (such as an included image content file) then when the next time the main executable was run this deleted file got restored i.e. the msi was found in the Windows store and it repaired my installation. With Wix this protection is not present any more. I think that is better for some of the (optional) files that are installed, but I would like to protect some of my dll's as before - do you know how I could do that in Wix? Atb, Kristjan
Re: [WiX-users] Burn - MSIPackage InstallCondition evaluates to false, attempts minor upgrade
Cheers Rob I'll give that a go see how it works out. Not quite what I was expecting but it sounds like it should do what I need. Any ideas on the Uninstall issue? I've got a few internal testers who can't uninstall the only Burn bundle I've provided thus far due to this issue which means they can't install any updated builds pretty much blocks us using Burn at all. Palbinder Sandher Software Platform Engineer 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: Rob Mensching [mailto:r...@robmensching.com] Sent: 29 April 2012 08:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Burn - MSIPackage InstallCondition evaluates to false, attempts minor upgrade Oh, well, this is far more advanced scenario than I thought you were trying to accomplish. The way I'd accomplish what you described using Burn is via slipstreaming. You include the MSI and MSP as you have it now but with none of the conditions. Then you have the MSI be the baseline you expect your customers have (like v2.0) and you have the MSP included in the Bundle be the update to go from v2.0 - latest. The patch, hopefully, is relatively small. The final piece is to mark the MSP as a slipstream of the MSI. You can do this by adding the SlipstreamMSP element to the MSI or in the next build, you can specify the MSP is a Slipstream=yes (or something like that) and it will slipstream the other way around. The end result is a constant (stable) evaluation that installs the baseline+MSP in one transaction if the baseline is not on the machine (aka: nothing installed or older version installed) or installs only the MSP if the basline is already on the machine. Using slipstreaming is a 300-level concept in Burn that definitely needs documentation. On Fri, Apr 27, 2012 at 4:13 AM, Pally Sandher pally.sand...@iesve.comwrote: Ah I probably wasn't clear. v1 had Product Code A, v2 has Product Code B. Hence I have a upgrade patch for versions 2.0 or 2.1 - 2.2 while a Major Upgrade for 1.x - 2.x Patching works fine now with Burn using the MSP, however for anyone who doesn't have any version of this product installed or has v1.x I would like to be able to have Burn run the Major Upgrade. Currently I can't do this because if they have v2.x installed, it first attempts a Minor Upgrade with the MSI first then tries to update using the MSP. Since both packages are downloaded rather than embedded, it unnecessarily downloads a 760 MB MSI followed by the required 360 MB MSP. Right now the solution is to leave the MSI out of the Burn bundle ask users to deal with it manually. Not an optimal solution but if I can't get Burn doing what we need it to, it'll have to do. Palbinder Sandher Software Platform Engineer 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: Rob Mensching [mailto:r...@robmensching.com] Sent: 26 April 2012 22:54 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Burn - MSIPackage InstallCondition evaluates to false, attempts minor upgrade Uhh, you can't Major Upgrade if the ProductCode is the same. I'm confused. People (maybe not you) have been asking for support for support for Minor Updates for a long time. Burn automatically handles it when an MSI doesn't change it's ProductCode but has a higher version. Burn also notifies the BA when a higher version of the MSI (Minor Update or Major Upgrade MSIs) is already present on the machine as a downgrade. I also don't understand the comment about patching. You can include patches in Burn and it will install them. You can even slipstream MSPs and Burn will be able to install the original MSI and the MSP in one transaction if the MSI isn't present already and only install the MSP if the MSI is already installed. It's really cool. On Thu, Apr 26, 2012 at 8:06 AM, Pally Sandher pally.sand...@iesve.com wrote: Not too bothered about 3 so I'll ignore it for now. Just mentioned it as one our QA guys noticed it today. Regarding 4, I do have the same product code higher version however my Upgrade Table code looks like the following: Upgrade Id=removed !--Original Shared Content UpgradeCode reinstated. This should never change-- UpgradeVersion Minimum=2.2.0 IncludeMinimum=yes OnlyDetect=yes Property=NEWERVERSIONDETECTED / UpgradeVersion Minimum=1.0.0 IncludeMinimum=yes
Re: [WiX-users] Accessing Regsitry Values from an Immediate CustomAction
It can be immediate if you schedule it after InstallFinalize. -Original Message- From: Liam Flanagan [mailto:l...@dyalog.com] Sent: Monday, April 30, 2012 9:04 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Accessing Regsitry Values from an Immediate CustomAction Hello, I have a wix based installer that writes some registry values using the standard wix registry element a bit like: RegistryValue Action=write Type=string Root=HKMU Key=Software\Company\Key Name=KeyName Value=1/ Is it possible for me to be able to read these values from a *immediate* custom action? If so when do I need to schedule it? I've currently got an immediate custom action that is scheduled *after WriteRegistryValues* but it doesn't seem to be able to read the written entries: RegOpenKeyEx returns ERROR_FILE_NOT_FOUND when trying to open the relevant key with read access. Custom action xml is: CustomAction Id=MyCustomAction Impersonate=yes Return=ignore Execute=immediate BinaryKey=MyCustomActionDll DllEntry=MyCustomAction / and the sequencing is: InstallExecuteSequence Custom Action=MyCustomAction After=WriteRegistryValuesNOT Installed/Custom /InstallExecuteSequence *Other Notes* * In the example ALLUSERS is 1 so the registry values will end up in the HKEY_LOCAL_MACHINE key. * As a result of the above the installation is given elevated privileges. * I've got the custom action's impersonate value set to yes as there are various pieces of user information I want to access from the CA. AFAIK this shouldn't be an issue as long as I only want to *read* keys from HKEY_LOCAL_MACHINE, which is the case. Any modification happens in the HKEY_CURRENT_USER key. *Environment* * Compiled using Wix v3.5 * Installing on a Windows 7 Enterprise (SP1) machine -- Liam - - Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Accessing Regsitry Values from an Immediate CustomAction
Peter, That worked perfectly =) I thought I'd tried this at some point whilst debugging but clearly I was mistaken... Thanks, Liam On 30/04/2012 11:53, Peter Shirtcliffe wrote: It can be immediate if you schedule it after InstallFinalize. -Original Message- From: Liam Flanagan [mailto:l...@dyalog.com] Sent: Monday, April 30, 2012 9:04 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Accessing Regsitry Values from an Immediate CustomAction Hello, I have a wix based installer that writes some registry values using the standard wix registry element a bit like: RegistryValue Action=write Type=string Root=HKMU Key=Software\Company\Key Name=KeyName Value=1/ Is it possible for me to be able to read these values from a *immediate* custom action? If so when do I need to schedule it? I've currently got an immediate custom action that is scheduled *after WriteRegistryValues* but it doesn't seem to be able to read the written entries: RegOpenKeyEx returns ERROR_FILE_NOT_FOUND when trying to open the relevant key with read access. Custom action xml is: CustomAction Id=MyCustomAction Impersonate=yes Return=ignore Execute=immediate BinaryKey=MyCustomActionDll DllEntry=MyCustomAction / and the sequencing is: InstallExecuteSequence Custom Action=MyCustomAction After=WriteRegistryValuesNOT Installed/Custom /InstallExecuteSequence *Other Notes* * In the example ALLUSERS is 1 so the registry values will end up in the HKEY_LOCAL_MACHINE key. * As a result of the above the installation is given elevated privileges. * I've got the custom action's impersonate value set to yes as there are various pieces of user information I want to access from the CA. AFAIK this shouldn't be an issue as long as I only want to *read* keys from HKEY_LOCAL_MACHINE, which is the case. Any modification happens in the HKEY_CURRENT_USER key. *Environment* * Compiled using Wix v3.5 * Installing on a Windows 7 Enterprise (SP1) machine -- Liam - - Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Setting the Bundle GUID
Are there plans to allow the Bundle GUID to be specified? At the moment I'd like it to stay the same since I'm not changing the MSI or version (only the BA), but it changes with each build. -- Bruce Cran -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Bootstrapper application example for .net framework 4.0
Hello All, can some one please send me working example of bootstrapper application in wix 3.6 and how to use it in the installer. i saw some online articles but couldn't follow. Thanks in advance. Loknath -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] building a custom bootstrapper application from wixstdba
in fact, this error is due to a test in the wixstdba code, my main problem is : i am trying to code a custom BA which is just slightly different from the wixstdba, i would like to transmit many informations in the same way it does. but i can't seem to do it : - is it possible to generate a bal:WixStandardBootstrapperApplication/ element, which would use a custom BA.dll ? or - is it possible to generate a BootstrapperApplication SourceFile=customBA.dll element, which would transmit information in a manifest node similar to /BootstrapperApplicationData/WixStdbaInformation ? thank you in advance, i am really stuck with this problem 2012/4/25 Rob Mensching r...@robmensching.com That error message must be coming from your custom.dll. I'm a little confused why the code would be looking for wixstdba data if it's not wixstdba. On Tue, Apr 24, 2012 at 10:00 AM, jean claude klodjan jcklod...@gmail.comwrote: but in that case, the bal:WixStandardBootstrapperApplication element will use the original wixstd ba - how can i tell it to use my custom dll ? 2012/4/24 Bruce Cran br...@cran.org.uk You need to use the bal:WixStandardBootstrapperApplication element to tell the ba where to find the license and logo. See the changing the wix standard bootstrapper application branding topic in the help file. -- Bruce Cran Sent from my iPad On 24 Apr 2012, at 17:31, jean claude klodjan jcklod...@gmail.com wrote: hello i have built a custom bootstrapper application, based on wixstdba. when i run the bootstrapper built using this dll, it can't probe for the thm.wxl and thm.xml files. i have added those files as payload, that way : BootstrapperApplication SourceFile=..\Resources\customba.dll Payload Id=thm.wxl-en_US Compressed=yes Name=1033\thm.wxl SourceFile=..\Resources\thm.wxl/ Payload Id=thm.xml-en_US Compressed=yes Name=1033\thm.xml SourceFile=..\Resources\thm.xml/ /BootstrapperApplication this solves that part of the problem, but now i get the following error : ...Error 0x80070057: BootstrapperApplication.xml manifest is missing wixstdba information. ...Error 0x80070057: Failed to read bootstrapper application data. ...Error 0x80070057: Failed to initialize data in bootstrapper application. Indeed, the code is looking for /BootstrapperApplicationData/WixStdbaInformation in BootstrapperApplication.xml .. what am i missing ? why should i do ? thank you in advance. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] PerUser Installation with a roaming profile
Hello, I'm investing a lot of time since a user had this problem but I didn't find any solution: UserA: S-1-5-21-the middle of the users SID-12617 UserA installs my MSI setup on ComputerA, there the following keys will be written during the install process from the MSI itself: [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\MyProductID] and additionally [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-21-the middle of the users SID-12617\Products\MyProductID] with the keys for the local cache file. The key: [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\MyProductID]will be roamed by default. If UserA wants now to update the MSI package on ComputerB, the MSI wants to uninstall the old MSI package, because of the registry key under: [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\MyProductID] Is there any chance to handle this? e.g.: I am able to override the uninstall logic with an own cleanup msi/tool with the registry key: [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall]? I am able to define the local cache directory for my MSI in my install directory? I am able to save a copy of my MSI install directory? (I would prefer this, but actually I have no idea if there is a msi conform way) Anyone have another idea? Or my package wasn't per user conform? Product and package information (the section that should contain the relevant information): Product Id=* Name=!(loc.ProductNamePerUser) Language=1033 Version=$(env.VERSION_SHORT) Manufacturer=$(env.Manufacturer) UpgradeCode=XYZ Package Description=$(env.WixDescription) Comments=$(env.WixComments) Manufacturer=$(env.Manufacturer) InstallerVersion=300 Compressed=yes InstallPrivileges=limited InstallScope=perUser / Best regards, Martin -Original Message- From: Albert van Peppen [mailto:alb...@insad.nl] Sent: Dienstag, 24. April 2012 11:44 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing into the roaming profile My policy is always to use a per machine install in roaming profile environments.. Besides the 'standard' discussion to determine if roaming profiles are a good idea in an organization. In most cases you will end up with a fragmented active directory; some users are with a roaming profile, others are not (due to several things). So in this scenario a per machine installation will always work, the per user part will likely only consist of some registry work, which you can handle through active directory policies :) Best regards, Albert van Peppen Senior System Engineer Insad Grafisch b.v. Mollevite 28 6931 KG Westervoort The Netherlands -Oorspronkelijk bericht- Van: Osanger, Martin [mailto:martin.osan...@fabasoft.com]mailto:[mailto:martin.osan...@fabasoft.com] Verzonden: 23 April 2012 09:20 Aan: General discussion for Windows Installer XML toolset. Onderwerp: Re: [WiX-users] Installing into the roaming profile Thanks for your answer. Is there any other opportunity or what's a better (supported) way to handle roaming profiles? only per machine installations? kind regards, Martin -Original Message- From: Rob Mensching [mailto:r...@robmensching.com]mailto:[mailto:r...@robmensching.com] Sent: Freitag, 20. April 2012 16:16 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing into the roaming profile I've never heard that Windows supported such behavior. Sounds interesting if it does. On Fri, Apr 20, 2012 at 6:37 AM, Osanger, Martin martin.osan...@fabasoft.commailto:martin.osan...@fabasoft.com wrote: Hello, Is there a Property or anything else I have to set on a per user installation with roaming profiles, so that the installation will be marked as roamed installation, and my setup will be shown in the ARP on another pc? Kind regards, martin -Original Message- From: Osanger, Martin [mailto:martin.osan...@fabasoft.com]mailto:[mailto:martin.osan...@fabasoft.com] Sent: Mittwoch, 18. April 2012 17:55 To: wix-users@lists.sourceforge.netmailto:wix-users@lists.sourceforge.net Subject: [WiX-users] Installing into the roaming profile Hello, My current situation (per user installation): I install my files to the AppDataFolder directory (in a subfolder). Now I can switch the pc's and have the installed data (saved to roaming profile) available. But I'm not able to uninstall the files, if I'm not on the pc where I installed the msi file (cached-msi-file and ARP entry was not roamed) Some customers delete their LocalAppDataFolder on logoff, so I have to install it to the AppDataFolder Are there any best practices for
Re: [WiX-users] Bundle failing to build after upgrading to latest release (3.6.2823)
Unfortunately still happens with 3.6.2328.0. I've updated the issue on SourceForge with a stack trace using the pdbs but as the formatting leaves a lot to be desired there I'll paste here too: light.exe(0,0): error LGHT0001: An item with the same key has already been added. Exception Type: System.ArgumentException Stack Trace: at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource) at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add) at System.Collections.ObjectModel.KeyedCollection`2.AddKey(TKey key, TItem item) at System.Collections.ObjectModel.KeyedCollection`2.InsertItem(Int32 index, TItem item) at System.Collections.ObjectModel.Collection`1.Add(T item) at Microsoft.Tools.WindowsInstallerXml.Binder.ChainPackageInfo.ResolveMspPackage(BinderCore core, Output bundle) in e:\delivery\Dev\wix36_public\src\wix\Binder.cs:line 7869 at Microsoft.Tools.WindowsInstallerXml.Binder.ChainPackageInfo..ctor(String id, String packageType, String payloadId, String installCondition, String installCommand, String repairCommand, String uninstallCommand, Object cacheData, String cacheId, Object attributesData, Object vitalData, Object perMachineData, String detectCondition, String msuKB, Object repairableData, String logPathVariable, String rollbackPathVariable, String protocol, Int32 installSize, Object suppressLooseFilePayloadGenerationData, Object enableFeatureSelectionData, Object forcePerMachineData, Object displayInternalUIData, Table wixGroupTable, Dictionary`2 allPayloads, Dictionary`2 containers, BinderFileManager fileManager, BinderCore core, Output bundle) in e:\delivery\Dev\wix36_public\src\wix\Binder.cs:line 7385 at Microsoft.Tools.WindowsInstallerXml.Binder.ChainPackageInfo..ctor(Row row, Table wixGroupTable, Dictionary`2 allPayloads, Dictionary`2 containers, BinderFileManager fileManager, BinderCore core, Output bundle) in e:\delivery\Dev\wix36_public\src\wix\Binder.cs:line 7249 at Microsoft.Tools.WindowsInstallerXml.Binder.BindBundle(Output bundle, String bundleFile) in e:\delivery\Dev\wix36_public\src\wix\Binder.cs:line 3224 at Microsoft.Tools.WindowsInstallerXml.Binder.Bind(Output output, String file) in e:\delivery\Dev\wix36_public\src\wix\Binder.cs:line 573 at Microsoft.Tools.WindowsInstallerXml.Tools.Light.Run(String[] args) in e:\delivery\Dev\wix36_public\src\light\light.cs:line 467 Binder temporary directory located at 'C:\Users\dev.build\AppData\Local\Temp\pfhwxuyl'. Palbinder Sandher Software Platform Engineer 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: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: 27 April 2012 16:07 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bundle failing to build after upgrading to latest release (3.6.2823) Will do Heath, thanks for resolving it so quickly. Apologies for not getting time to get some detailed debug info using the PDBs as Bob requested, was planning on making some time for doing it this afternoon but it's a moot point now =) Palbinder Sandher Software Platform Engineer 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: Heath Stewart [mailto:clubs...@gmail.com] Sent: 27 April 2012 06:19 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bundle failing to build after upgrading to latest release (3.6.2823) This should be fixed in the next build of WiX out Monday evening. Please verify and let me know. Thanks, On Thu, Apr 26, 2012 at 7:10 PM, Heath Stewart clubs...@gmail.com wrote: I've opened https://sourceforge.net/tracker/?func=detailaid=3521813group_id=105970atid=642714 to track this. On Wed, Apr 25, 2012 at 9:30 AM, Bob Arnson b...@joyofsetup.com wrote: On 25-Apr-12 11:45, Pally Sandher wrote: Microsoft (R) Windows Installer Xml Linker version 3.6.2823.0 Copyright (C) Microsoft Corporation. All rights reserved. light.exe(0,0): error LGHT0001: An item with the same key has already been added. Exception Type: System.ArgumentException That's bad. Can you unzip the .pdbs into your WiX
Re: [WiX-users] Bundle fails on WIN2K machine .exe is not a valid Win32 application
I agree with dropping support for Win2k but what is a shame is that running the exe doesn't display a more useful error message. I don't suppose there is anything that can be done to change this? Neil -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Random GUID generation
There are a couple of components that I need to generate a random GUID for on each build, but Wix does not allow me to use asterisk for them, because im using per user install that requires registry key (path) and file in same component. Any way to make asterisk work in this case? Also, if I use asterisk for a Component is it true that it will not generate a new GUID every build? i.e. Component/@Guid=* calculates a GUID that stays the same as long as your file path stays the same (http://stackoverflow.com/questions/5832315/wix-autogenerate-guid ) Does that mean Wix keeps some kind of database of builds past and compares the file paths of current and past builds to determine whether asterisk should generate a new GUID or stay same as last build? In any case, I need to also generate a random GUID for UPGRADECODE every build, because im trying to deploy an installation strategy with changing upgrade codes every version so that I can create parallel installs of different versions of the same app, in different target folders, the component files in which I would like to max out on reference count 1 (each). If * does not equal random guid every time, I was wondering if there already exist any Wix extension that I could call upon to generate random GUIDs for me, rather than burdening myself to semi-manually generate them every time ? Thank you for your expertise, Kristjan Error 12 The Component/@Guid attribute's value '*' is not valid for this component because it does not meet the criteria for having an automatically generated guid. Components with registry keypaths and files cannot use an automatically generated guid. Create multiple components, each with one file and/or one registry value keypath, to use automatically generated guids. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bundle fails on WIN2K machine .exe is not a valid Win32 application
All, Thanks for clearing that up. In the end not having a WIN2K bundle isn't that big a deal; the .MSI's run flawlessly and that's what counts. So a quick note of appreciation: We've been using WiX for almost three years to deploy/update client API adapters that connect 3rd party POS systems (mainly in grocery) to our Cloud based services. The power and flexibility of the WiX tool set has proved to be a critical component to scaling our solution - deploying thousands of client adapters. In our B2B world it's our ability to integrate with a customer's /existing/ platform that has proved a game changer. As an example, one of MSI packages, using C# Custom Actions, reads the 3rd party values in the registry and .ini files then selects the correct API.DLL to install (currently eight different versions), suppresses UI dialogue if it's self-checkout unit, updates our .NET app config files, and manages the GAC entries, etc. If the customer installs a POS patch then a simple Repair updates the API DLL. One click of script to run the WiX MSI in quiet mode replaces an 10 page/10 minute manual install procedure - InstallSheild package plus system configuration changes. Cheers! Rich - Rich Dingle Accelitec, Inc. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bundle-fails-on-WIN2K-machine-exe-is-not-a-valid-Win32-application-tp7507520p7514752.html Sent from the wix-users mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WiX3.6 Uninstall Failed / Installing Votive
Thank you for you help, the command you gave me seemed to do the trick. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/WiX3-6-Uninstall-Failed-Installing-Votive-tp7500775p7514760.html Sent from the wix-users mailing list archive at Nabble.com. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Standard bootrapper with Wix - how to specify relative paths
Hi, I am building a bootstrapper with Wix - I am using the tag MsiPackage and specifying the SourceFile attribute. How do I specify a relative path to a msi package using this? I will have the pre-requisite on my media in a folder called Support which is at the level of the Setup.exe. I am new to the Wix Bootstrapper project and will be very appreciative of any help. Thanks! Uma- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Standard bootrapper with Wix - how to specify relative paths
You set the MsiPackage/@Name attribute e.g. Name='Support\your.msi' Neil -Original Message- From: Uma Harano [mailto:uhar...@esri.com] Sent: 30 April 2012 21:51 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Standard bootrapper with Wix - how to specify relative paths Hi, I am building a bootstrapper with Wix - I am using the tag MsiPackage and specifying the SourceFile attribute. How do I specify a relative path to a msi package using this? I will have the pre-requisite on my media in a folder called Support which is at the level of the Setup.exe. I am new to the Wix Bootstrapper project and will be very appreciative of any help. Thanks! Uma- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Standard bootrapper with Wix - how to specify relative paths
I get this error now (below) Should I copy the msi package to the Bootstrap solution location too? Error 1 The system cannot find the file 'SourceDir\Support\your.msi'. C:\test\Wix\Burn\Bootstrapper1\Bundle.wxs 9 1 Bootstrapper1 -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: Monday, April 30, 2012 2:06 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Standard bootrapper with Wix - how to specify relative paths You set the MsiPackage/@Name attribute e.g. Name='Support\your.msi' Neil -Original Message- From: Uma Harano [mailto:uhar...@esri.com] Sent: 30 April 2012 21:51 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Standard bootrapper with Wix - how to specify relative paths Hi, I am building a bootstrapper with Wix - I am using the tag MsiPackage and specifying the SourceFile attribute. How do I specify a relative path to a msi package using this? I will have the pre-requisite on my media in a folder called Support which is at the level of the Setup.exe. I am new to the Wix Bootstrapper project and will be very appreciative of any help. Thanks! Uma- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WiX support for (gulp!) WinNT4
We have an older product that supports WinNT4 (with SP6+IE4). The installer for this product was built using WiX 3.0.5419.0. The last release was November 2010. We found that running the MSI file on WinNT4+SP6+IE4 appears to work except that the user cannot get past selecting a target folder, because clicking Next always reports Installation directory must be on a local hard drive even for C:\Program Files\RMCWin. Just today, I rebuilt the MSI file using the same source and WiX toolset (3.0.5419.0). However, this time, running the MSI file on WinNT4+SP6+IE4 gives error 1620 (This installation package could not be opened. Contact the application vendor to verify that this is a valid Windows Installer package) immediately. Both MSI files are marked with Schema 200, and the pristine WinNT4+SP6+IE4 virtual machine has Windows Installer 2.00.2600.2 installed on it. Question #1: Any ideas on the source of either failure mode, or why it changed when building with the same source and toolset but on very different dates? The toolset and source are version controlled by Perforce. Question #1: What versions of WiX can generate Window NT4+SP6/WindowsInstaller2.00 compatible MSI files? Quinton Tormanen Software Engineer Delta Computer Systems, Inc. http://www.deltamotion.comhttp://www.deltamotion.com/ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Setting the Bundle GUID
No. The Bundle Id is like the PackageCode. Different with every build. On Mon, Apr 30, 2012 at 5:52 AM, Bruce Cran br...@cran.org.uk wrote: Are there plans to allow the Bundle GUID to be specified? At the moment I'd like it to stay the same since I'm not changing the MSI or version (only the BA), but it changes with each build. -- Bruce Cran -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
