Re: [WiX-users] Managed Bootstrapper - Second Patch does not supersede first Patch
Thanks for the prompt reply. Here is the log snippet: Machine policy value 'EnforceUpgradeComponentRules' is 0 SELMGR: New components have been added to feature 'ProductFeature' SELMGR: Component 'QsTeamServer.x86.exe.config' is a new component added to feature 'ProductFeature' SELMGR: Component 'QsTeamServer.x86.exe' is a new component added to feature 'ProductFeature' And then again later on: Machine policy value 'EnforceUpgradeComponentRules' is 0 SELMGR: New components have been added to feature 'ProductFeature' SELMGR: Component 'QsTeamServer.x86.exe.config' is a new component added to feature 'ProductFeature' SELMGR: Component 'QsTeamServer.x86.exe' is a new component added to feature 'ProductFeature' Got lots of: File: C:\Program Files\Qualisystems\TestShell Server\QS.Contracts.dll; Overwrite; Won't patch;REINSTALLMODE specifies all files to be overwritten For all the files in the patch... even though the log specifies it's gonna overwrite... it dones't. -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: יום ד 13 מרץ 2013 18:33 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Managed Bootstrapper - Second Patch does not supersede first Patch ...and to exapand on that, look for your files in the log. There should be a FileCopy that will say something like Won't Overwrite;Won't patch; and give you a reason. If your patch is incorrect because of component rules, look for SELMGR in the log and any remarks about removing components not supported. Phil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, March 13, 2013 8:24 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Managed Bootstrapper - Second Patch does not supersede first Patch What does the action state for the *Components* show? That's what the Windows Installer is basing it's decision on. It would root cause the issue. It very likely could be the version of the files not changing but it would be best to *know* what fixed it, right? On Wed, Mar 13, 2013 at 8:18 AM, Tomer Cohen tome...@qualisystems.comwrote: Hi, Thanks for the reply. I have this in my log, this is the log of the second patch installation. The MSP itself has all assemblies, but only installs those files below. Patch Modified Files List: MSI (s) (C4:04) [15:51:46:984]: File = QualiSystems.ResourceManagement.Service.Plugin.config: Final State = Install MSI (s) (C4:04) [15:51:46:984]: File = MRV_MCC_4640.exe: Final State = Install MSI (s) (C4:04) [15:51:46:984]: File = MRV_MCC_4840.exe: Final State = Install MSI (s) (C4:04) [15:51:46:984]: File = ONPATH_HorizON_0204.exe: Final State = Install MSI (s) (C4:04) [15:51:46:984]: File = ONPATH_HorizON_0204_RuntimeConfig.xml: Final State = Install MSI (s) (C4:04) [15:51:46:984]: File = SNMP_Manager.tslib: Final State = Install MSI (s) (C4:04) [15:51:46:984]: File = TestShell_API.tslib: Final State = Install MSI (s) (C4:04) [15:51:46:984]: File = ONPATH_HorizON_0244_RuntimeConfig.xml: Final State = Install MSI (s) (C4:04) [15:51:46:984]: File = ONPATH_HorizON_0244.exe: Final State = Install I'll give the AssemblyFileVersion increment a chance. Thanks. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: יום ד 13 מרץ 2013 17:06 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Managed Bootstrapper - Second Patch does not supersede first Patch What does the verbose log file in the patch say the action states for the Components that you expect to be installed? Also, look at the File install log lines, those usually have quite a bit information about when the file is being applied and whether it is being patched. On Wed, Mar 13, 2013 at 7:19 AM, Tomer Cohen tome...@qualisystems.com wrote: Just to be clear, the files don't have a newer version, but they are different in size and binary... -Original Message- From: David Watson [mailto:dwat...@sdl.com] Sent: יום ד 13 מרץ 2013 16:04 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Managed Bootstrapper - Second Patch does not supersede first Patch Did you increase the assemblyfileversion of those dlls? -Original Message- From: Tomer Cohen [mailto:tome...@qualisystems.com] Sent: 13 March 2013 13:28 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Managed Bootstrapper - Second Patch does not supersede first Patch No no, you got me all wrong. I don't want cumulative patches! The opposite, I want the last patch that I install to supersede all others, overwriting the files. I have the MSP file and in z7 I can see that it has all the right files, that is the new files. But if I install it after I installed an earlier patch... those files don't get to the
[WiX-users] Finding Directory that was created by Wix
Hi, I have an installer that is currently working by using heat to harvest a published website. This works perfectly and I get my site installed. The problem is now I need to add in some additional dll's because of dependency injection. How do I find the created bin folder as part of the installer. I can see in the heat harvested file that it generates dirguid but that is no good if i am generating a new file everytime. Is there a way to look for a directory by name if you have the root? Brian -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Merge modules wixlib compatibility
Hello, I am trying to move from merge modules to wixlibs, but I am not sure whether all the functionality is preserved. Consider the following scenario: - one product goes into the merge module M1 - other product goes into the merge module M2 - a MSI is created containing both M1 and M2 and installed - the first product gets some important fix - new MSI is created just having the fixed M1 Now if I understand correctly, the installer correctly upgrades the M1 install with this MSI. Later when there is a new version of the whole product, it will correctly upgrade both fixed M1 and original M2. That is the case also when the M1 only MSI is installed first. Now does this work even when I switch from modules to wixlibs? Is there overall any reason why would one need to use merge modules instead of wixlib (apart from supporting non-WiX environment)? Thanks! Jan -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge modules wixlib compatibility
MSM is a Windows Installer standard, wixlib is not. Otherwise they are similar in function with wixlib being lighter weight and more flexible. But your scenario confuses me. An MSI can install one and only one product. It would be more accurate to say the files for one feature goes in M1 and the files for another feature go in M2. Unless you are really talking about patches, a new MSI is always going to have both M1 and M2. Either you stick with this monolithic design or you look at creating 2 MSI's and using Burn to chain them together. From: Jan Kucera t-j...@microsoft.com Sent: Thursday, March 14, 2013 6:29 AM To: wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net Subject: [WiX-users] Merge modules wixlib compatibility Hello, I am trying to move from merge modules to wixlibs, but I am not sure whether all the functionality is preserved. Consider the following scenario: - one product goes into the merge module M1 - other product goes into the merge module M2 - a MSI is created containing both M1 and M2 and installed - the first product gets some important fix - new MSI is created just having the fixed M1 Now if I understand correctly, the installer correctly upgrades the M1 install with this MSI. Later when there is a new version of the whole product, it will correctly upgrade both fixed M1 and original M2. That is the case also when the M1 only MSI is installed first. Now does this work even when I switch from modules to wixlibs? Is there overall any reason why would one need to use merge modules instead of wixlib (apart from supporting non-WiX environment)? Thanks! Jan -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge modules wixlib compatibility
Okay the 'product' term seems to be a bit overloaded here, even I have used it in two different meanings. So the one way we currently support is: ComponentGroup 1 - MSM 1 - single feature MSI containing MSM 1 only ComponentGroup 2 - MSM 2 - single feature MSI containing MSM 2 only ... The other way is to make a 'kit' installer, using MSM 1 + MSM 2 + ... - MSI containing all the MSMs (can be single feature or not) - For all upgrades, we do full uninstall and reinstall. - The number of MSMs can be like 50, and you definitely do not want to have them all in the control panel unless you install them separately. - The desired and observed behaviour is that the Windows Installer treats the component groups the same regardless of what MSI they were installed by. Not surprisingly this takes a considerable amount of time to compile. I thought we could speed it up a bit using wixlibs: ComponentGroup 1 - wixlib 1 - single feature MSI containing wixlib 1 only ComponentGroup 2 - wixlib 2 - single feature MSI containing wixlib 2 only ... or wixlib 1 + wixlib 2 + ... - single feature MSI containing all the wixlibs directly But I am wondering whether the component groups would be treated the same as in modules, i.e. the versioning would work (since merge modules do have a version). From your suggestions I understand that we cannot switch to wixlibs. Burn would save the compile time of the 'kit' installer, but is not really an option as it seems to just chain the individual MSIs, resulting in flooded control panel. By the way, where can I find Burn? It does not seem to be in the WiX binaries, and is there any documentation for it? Thanks, Jan -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: 14 March 2013 12:03 To: General discussion for Windows Installer XML toolset.; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Merge modules wixlib compatibility MSM is a Windows Installer standard, wixlib is not. Otherwise they are similar in function with wixlib being lighter weight and more flexible. But your scenario confuses me. An MSI can install one and only one product. It would be more accurate to say the files for one feature goes in M1 and the files for another feature go in M2. Unless you are really talking about patches, a new MSI is always going to have both M1 and M2. Either you stick with this monolithic design or you look at creating 2 MSI's and using Burn to chain them together. From: Jan Kucera t-j...@microsoft.com Sent: Thursday, March 14, 2013 6:29 AM To: wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net Subject: [WiX-users] Merge modules wixlib compatibility Hello, I am trying to move from merge modules to wixlibs, but I am not sure whether all the functionality is preserved. Consider the following scenario: - one product goes into the merge module M1 - other product goes into the merge module M2 - a MSI is created containing both M1 and M2 and installed - the first product gets some important fix - new MSI is created just having the fixed M1 Now if I understand correctly, the installer correctly upgrades the M1 install with this MSI. Later when there is a new version of the whole product, it will correctly upgrade both fixed M1 and original M2. That is the case also when the M1 only MSI is installed first. Now does this work even when I switch from modules to wixlibs? Is there overall any reason why would one need to use merge modules instead of wixlib (apart from supporting non-WiX environment)? Thanks! Jan -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn in the ARP
I've seen tangential posts regarding this, but no answer quite fit what I was looking for. I have a bootstrapper which will install several prereq's and then my product's MSI. In testing, I noticed that if the product is uninstalled from ARP and then the bootstrapper is run it thinks it is still installed and provides options to uninstall or repair. Obviously this is a confusing experience for the user. I found digging through the forums the suggestion of setting visible on the msi package to no will hide the msi in the ARP and this allows the bootstrapper to be the parent. I set visible to false and now I get no ARP entry at all, not even for the bootstrapper. This is my bundle node: Bundle Name=$(var.ProductName) IconSourceFile=InstallerFiles\$(var.SetupIcon) ParentName=$(var.ProductName) Version=$(var.ProductVersion) Manufacturer=DGI, Inc. Condition=((VersionNT = v5.1) AND (ServicePackLevel = 2)) OR ((VersionNT = v5.2) AND (ServicePackLevel = 2)) OR (VersionNT = v6.0) UpgradeCode=$(var.UpgradeCode) Any ideas why the bootstrapper is not appearing in the ARP? -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Any ideas on how to solve MessageBox focus, can be lost (using Custom Action DLL)
You shouldn't use MessageBox. MsiProcessMessage() is the right way, typically with INSTALLMESSAGE_USER. Phil -Original Message- From: StevenOgilvie [mailto:sogil...@msn.com] Sent: Wednesday, March 13, 2013 12:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Any ideas on how to solve MessageBox focus, can be lost (using Custom Action DLL) Hi all, I have a Custom Action DLL (C#) Within the Welcome page to the ready to install page I have been able to populate a MSI Property for any error messages/exceptions that are caused by the Custom Action calls.. i.e. At beginning of the Custom Action method: SetSessionProperty(session, CUSTOM_ACTION_ERROR, 1); within the Catch of the exception: SetSessionProperty(session, CUSTOM_ACTION_ERROR, 0); SetSessionProperty(session, CUSTOM_ACTION_ERROR_MESSAGE,Message for the generic error dialog + ex.message); then in the custom dialog WXS file I check when user select Next to see if the CUSTOM_ACTION_ERROR is 0, and then spawn the generic error dialog with the CUSTOM_ACTION_ERROR_MESSAGE This works great, during that time frame, but when the Progress dialog happens I can't do the same thing since I get an error within the custom action dll that Cannot access session details from a non-immediate custom action Does anyone know how I can pass along info back to the MSI during the Progress dialog or how to make the MessageBox modal to the MSI? thanks, Steve -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Any-ideas-on-h ow-to-solve-MessageBox-focus-can-be-lost-using-Custom-Action-DLL-tp7584319.h tml Sent from the wix-users mailing list archive at Nabble.com. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Finding Directory that was created by Wix
I would probably apply an XSLT to transform the output of heat to something more referenceable. On Thu, Mar 14, 2013 at 3:27 AM, Stones stone...@gmail.com wrote: Hi, I have an installer that is currently working by using heat to harvest a published website. This works perfectly and I get my site installed. The problem is now I need to add in some additional dll's because of dependency injection. How do I find the created bin folder as part of the installer. I can see in the heat harvested file that it generates dirguid but that is no good if i am generating a new file everytime. Is there a way to look for a directory by name if you have the root? Brian -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Merge modules wixlib compatibility
1. Burn will not flood ARP with entries. By default, the MSI package registration is suppressed so you'll only get the Bundle registration in the end. Burn is used when you create a Bundle element using WiX v3.6+. 2. Merge Modules are mostly useful when sharing setup logic with people that are not using the WiX toolset. If you just want to pull in ComponentGroups, then .wixlibs are much faster and integrate better with the whole build flow. The Merge Module version is not persisted outside of the MSI, so it's only really useful when talking about which Merge Module your consumer has, i.e. We just updated MM1 to v1.9.0.0, if you have an older version of our Merge Module be sure to update soon and re-release your MSI because old versions have a bad bug. On Thu, Mar 14, 2013 at 6:05 AM, Jan Kucera t-j...@microsoft.com wrote: Okay the 'product' term seems to be a bit overloaded here, even I have used it in two different meanings. So the one way we currently support is: ComponentGroup 1 - MSM 1 - single feature MSI containing MSM 1 only ComponentGroup 2 - MSM 2 - single feature MSI containing MSM 2 only ... The other way is to make a 'kit' installer, using MSM 1 + MSM 2 + ... - MSI containing all the MSMs (can be single feature or not) - For all upgrades, we do full uninstall and reinstall. - The number of MSMs can be like 50, and you definitely do not want to have them all in the control panel unless you install them separately. - The desired and observed behaviour is that the Windows Installer treats the component groups the same regardless of what MSI they were installed by. Not surprisingly this takes a considerable amount of time to compile. I thought we could speed it up a bit using wixlibs: ComponentGroup 1 - wixlib 1 - single feature MSI containing wixlib 1 only ComponentGroup 2 - wixlib 2 - single feature MSI containing wixlib 2 only ... or wixlib 1 + wixlib 2 + ... - single feature MSI containing all the wixlibs directly But I am wondering whether the component groups would be treated the same as in modules, i.e. the versioning would work (since merge modules do have a version). From your suggestions I understand that we cannot switch to wixlibs. Burn would save the compile time of the 'kit' installer, but is not really an option as it seems to just chain the individual MSIs, resulting in flooded control panel. By the way, where can I find Burn? It does not seem to be in the WiX binaries, and is there any documentation for it? Thanks, Jan -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: 14 March 2013 12:03 To: General discussion for Windows Installer XML toolset.; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Merge modules wixlib compatibility MSM is a Windows Installer standard, wixlib is not. Otherwise they are similar in function with wixlib being lighter weight and more flexible. But your scenario confuses me. An MSI can install one and only one product. It would be more accurate to say the files for one feature goes in M1 and the files for another feature go in M2. Unless you are really talking about patches, a new MSI is always going to have both M1 and M2. Either you stick with this monolithic design or you look at creating 2 MSI's and using Burn to chain them together. From: Jan Kucera t-j...@microsoft.com Sent: Thursday, March 14, 2013 6:29 AM To: wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net Subject: [WiX-users] Merge modules wixlib compatibility Hello, I am trying to move from merge modules to wixlibs, but I am not sure whether all the functionality is preserved. Consider the following scenario: - one product goes into the merge module M1 - other product goes into the merge module M2 - a MSI is created containing both M1 and M2 and installed - the first product gets some important fix - new MSI is created just having the fixed M1 Now if I understand correctly, the installer correctly upgrades the M1 install with this MSI. Later when there is a new version of the whole product, it will correctly upgrade both fixed M1 and original M2. That is the case also when the M1 only MSI is installed first. Now does this work even when I switch from modules to wixlibs? Is there overall any reason why would one need to use merge modules instead of wixlib (apart from supporting non-WiX environment)? Thanks! Jan -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone
Re: [WiX-users] Any ideas on how to solve MessageBox focus, can be lost (using Custom Action DLL)
Classification: Public I am using a C# dll and I can't seem to find info on how to use MsiProcessMessage() in C# -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: March-14-13 10:26 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Any ideas on how to solve MessageBox focus, can be lost (using Custom Action DLL) You shouldn't use MessageBox. MsiProcessMessage() is the right way, typically with INSTALLMESSAGE_USER. Phil -Original Message- From: StevenOgilvie [mailto:sogil...@msn.com] Sent: Wednesday, March 13, 2013 12:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Any ideas on how to solve MessageBox focus, can be lost (using Custom Action DLL) Hi all, I have a Custom Action DLL (C#) Within the Welcome page to the ready to install page I have been able to populate a MSI Property for any error messages/exceptions that are caused by the Custom Action calls.. i.e. At beginning of the Custom Action method: SetSessionProperty(session, CUSTOM_ACTION_ERROR, 1); within the Catch of the exception: SetSessionProperty(session, CUSTOM_ACTION_ERROR, 0); SetSessionProperty(session, CUSTOM_ACTION_ERROR_MESSAGE,Message for the generic error dialog + ex.message); then in the custom dialog WXS file I check when user select Next to see if the CUSTOM_ACTION_ERROR is 0, and then spawn the generic error dialog with the CUSTOM_ACTION_ERROR_MESSAGE This works great, during that time frame, but when the Progress dialog happens I can't do the same thing since I get an error within the custom action dll that Cannot access session details from a non-immediate custom action Does anyone know how I can pass along info back to the MSI during the Progress dialog or how to make the MessageBox modal to the MSI? thanks, Steve -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Any-ideas-on-h ow-to-solve-MessageBox-focus-can-be-lost-using-Custom-Action-DLL-tp7584319.h tml Sent from the wix-users mailing list archive at Nabble.com. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message has been marked as Public by Steven Ogilvie. The above classification labels were added to the message by TITUS Message Classification. Visit www.titus.com for more information. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn in the ARP
Try to not use 'ParentName=$(var.ProductName)'. Just remove this code. Alexey. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-in-the-ARP-tp7584342p7584348.html Sent from the wix-users mailing list archive at Nabble.com. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Update Element of the Bundle?
I missed that feature when I downloaded the extended BA yesterday. I'll study the Codeplex discussion and ask over there when I have more questions. I'll also search wix-devs. -Original Message- From: Neil Sleightholm [mailto:n...@x2systems.com] Sent: Wednesday, March 13, 2013 11:00 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Using Update Element of the Bundle? I implemented auto update in the extended BA (http://wixextba.codeplex.com/) I am not sure it is the best way to do it but it works. Check out the discussion on the site for information on how to use it. There was also a recent discuss on wix-devs about it. On Tue, Mar 12, 2013 at 1:31 PM, Wheeler, Blaine (DSHS/DCS) bwhee...@dshs.wa.gov wrote: I want to create a self updating setup.exe with Burn. I hope that using the Update element of the Bundle with Wix 3.7 will work. The Help says this piece wasn't working yet but it looks like you use it for Wix updates. True? Is there a reason you use a feed or was it just convenience? My plan: Set up a folder and file tree off a web server. From the Wix 3.7 source it looks like the UpdateURL attribute of the Bundle element in the refers to the root URL where all subsequent updates of this version of product will be. For example: http://ourhouse/releases/myAppName. Or Is Update Location='' / the critical element? Or are both necessary? For each update we would add a folder under MyAppName with a unique ID such as the setup.exe version number (1.0.0.0, 1.0.0.1 etc) If we have 4 packages per setup.exe would each sub folder have to all of the packages referenced by the bundle? I'm open to other ideas and I'd be happy to contribute code back or to the Help if I am on a useful track? Blaine Wheeler Department of Social and Health Services Project Coordinator SEMS Operations 360.664.5416 blaine.whee...@dshs.wa.gov -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Any ideas on how to solve MessageBox focus, can be lost (using Custom Action DLL)
If you're in DTF you might find that they have something that gets to MsiProcessMessage(), a Session.Message or something. Phil -Original Message- From: Steven Ogilvie [mailto:steven.ogil...@titus.com] Sent: Thursday, March 14, 2013 8:26 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Any ideas on how to solve MessageBox focus, can be lost (using Custom Action DLL) Classification: Public I am using a C# dll and I can't seem to find info on how to use MsiProcessMessage() in C# -Original Message- From: Phil Wilson [mailto:phil.wil...@mvps.org] Sent: March-14-13 10:26 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Any ideas on how to solve MessageBox focus, can be lost (using Custom Action DLL) You shouldn't use MessageBox. MsiProcessMessage() is the right way, typically with INSTALLMESSAGE_USER. Phil -Original Message- From: StevenOgilvie [mailto:sogil...@msn.com] Sent: Wednesday, March 13, 2013 12:05 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Any ideas on how to solve MessageBox focus, can be lost (using Custom Action DLL) Hi all, I have a Custom Action DLL (C#) Within the Welcome page to the ready to install page I have been able to populate a MSI Property for any error messages/exceptions that are caused by the Custom Action calls.. i.e. At beginning of the Custom Action method: SetSessionProperty(session, CUSTOM_ACTION_ERROR, 1); within the Catch of the exception: SetSessionProperty(session, CUSTOM_ACTION_ERROR, 0); SetSessionProperty(session, CUSTOM_ACTION_ERROR_MESSAGE,Message for the generic error dialog + ex.message); then in the custom dialog WXS file I check when user select Next to see if the CUSTOM_ACTION_ERROR is 0, and then spawn the generic error dialog with the CUSTOM_ACTION_ERROR_MESSAGE This works great, during that time frame, but when the Progress dialog happens I can't do the same thing since I get an error within the custom action dll that Cannot access session details from a non-immediate custom action Does anyone know how I can pass along info back to the MSI during the Progress dialog or how to make the MessageBox modal to the MSI? thanks, Steve -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Any-ideas-on-h ow-to-solve-MessageBox-focus-can-be-lost-using-Custom-Action-DLL-tp7584319.h tml Sent from the wix-users mailing list archive at Nabble.com. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message has been marked as Public by Steven Ogilvie. The above classification labels were added to the message by TITUS Message Classification. Visit www.titus.com for more information. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn in the ARP
Thanks, that worked perfectly! I knew it was something simple I did months ago, but just could not remember. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-in-the-ARP-tp7584342p7584352.html Sent from the wix-users mailing list archive at Nabble.com. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Looking at WiX to generate a Chained installpackage.
Not really sure what you are meaning by an embedded UI here. GPO publishes MSIs silently to client machines. Also its possible to push several MSIs as part of one policy (we have to document this for our customers so they can install prerequisites) so I don't see an absolute requirement for chaining apart from simplicity. Dave W. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 13 March 2013 18:14 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Looking at WiX to generate a Chained installpackage. That or a embedded UI would need to be implemented in the WiX toolset. Personally, I jumped over that feature and went for the full blown bootstrapper/chainer with Burn... but GPO functionality does suffer a bit. Might be an interesting feature to implement in the future to provide a stock embedded UI from WiX toolset. On Wed, Feb 27, 2013 at 6:22 AM, TimM timmay...@smarttech.com wrote: Since we still have a lot of our customers that still use GPO for pushing out our software we still have to have a .msi solution. So again it looks like we have to stay with InstallShield for all our chained projects. Tim. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Looking-at-WiX- to-generate-a-Chained-install-package-tp7583963p7583998.html Sent from the wix-users mailing list archive at Nabble.com. - - Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ 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. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Managed Boostrapper Application and Wix 3.7
I modified per your instruction, and then got a compiler error regarding WixMbaPrereqPackageId and WixMbaPrereqLicenseUrl. So I followed the example in http://blogs.msdn.com/b/heaths/archive/2011/10/28/introducing-managed-bootstrapper-applications.aspx. It again compiles, but when I run the exe, I now get: [1D54:18C8][2013-03-14T10:18:19]i000: Loading managed bootstrapper application. [1D54:18C8][2013-03-14T10:18:19]e000: Error 0x8007000b: Failed to create the managed bootstrapper application. [1D54:18C8][2013-03-14T10:18:19]e000: Error 0x8007000b: Failed to create UX. [1D54:18C8][2013-03-14T10:18:19]e000: Error 0x8007000b: Failed to load UX. [1D54:18C8][2013-03-14T10:18:19]e000: Error 0x8007000b: Failed while running Is there anything else that needs to change going from 3.6 to 3.7? Thanks. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Wednesday, March 13, 2013 10:35 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Managed Boostrapper Application and Wix 3.7 You must have something from very early in WiX v3.6. The correct way to reference the mbahost is like so: BootstrapperApplicationRef Id='ManagedBootstrapperApplicationHost' On Wed, Mar 13, 2013 at 8:58 PM, George Fleming gef...@microsoft.comwrote: I have an Burn app that works with Wix 3.6. The Bundle.wxs looks something like this: BootstrapperApplication Id='ManagedBootstrapperApplicationHost' SourceFile=$(var.WixToolsDir)\Burn\mbahost.dll Payload SourceFile=$(var.WixToolsDir)\SDK\BootstrapperCore.dll Name=BootstrapperCore.dll / Payload SourceFile=BootstrapperCore.config Name=BootstrapperCore.config / Trying to do the same thing with Wix 3.7, and I ran into problems (see my previous posts under Can Wix Bootstrapper project be a VS Startup project). Since Wix 3.7 doesn't have a mbahost.dll as part of the package, I copied the mbahost.dll from Wix 3.6, and I guess that's probably the source of the problem. Using this old dll, my application fails to create UX, according to the log file. So I guess the question is, for Wix 3.7, what is the correct way to do this? -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using transforms (regular) to install mulitple times per application
Ok, I am working with Jonathan today in my day job capacity and I have an
understanding of PROBABLY what is happening. If the WiX-devs list is better for
this, let me know...
Based on the install logs and the way BURN appears to work, transforms seem a
bit limited in how BURN handles them (and if someone knows the section of code
I would appreciate the pointer).
Background:
So the transform is working on install. The installation works as expected and
the appropriate transform is applied and installed. On uninstall they are
getting an error saying that the item is not installed (weird cause we did
install it). So looking at the log we see that the initial product GUID is one
value and the transform changes it to a different value. Also the registry
shows that the transform was applied as expected. So far so good.
When we go to uninstall we notice the GUID being used is the old GUID for the
application not the transformed one. This leads to the uninstall error.
What we believe is happening is that BURN is tracking the MSI GUIDs that are
being installed and when the transform is applied and changes that GUID, BURN
has no trace of it.
What we need:
So what we need to do is when a transform is applied, update the XML list that
BURN maintains with the new GUID so that the uninstall tracks it appropriately.
We just need to update this on install only. Once updated it should be fine
going forward. I can see in the BURN source where it reads this XML information
and operates based on that, but I am not 100% sure where this information is
generated. Is it on install or is this done at build time? If at build time is
there a way for us to tell BURN what the GUID will change to? That will resolve
their uninstall problem...
Below are some of the logs during install:
[09B4:06A0][2013-03-13T07:48:14]: Verified acquired payload:
cab07A065F47DD6E9FCDAE62ABCDDF335E7 at path: C:\Documents and Settings\All
Users\Application Data\Package
Cache\.unverified\cab07A065F47DD6E9FCDAE62ABCDDF335E7, moving to: C:\Documents
and Settings\All Users\Application Data\Package
Cache\{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}v1.0.0.0030\cab1.cab.
[09B4:0D50][2013-03-13T07:48:14]: Applying execute package: RADInstall30,
action: Install, path: C:\Documents and Settings\All Users\Application
Data\Package
Cache\{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}v1.0.0.0030\RADInstall30,
arguments: ' ARPSYSTEMCOMPONENT=1 MSIFASTINSTALL=7 TRANSFORMS=:Jon2T
ARPSYSTEMCOMPONENT=1'
[09B4:0D50][2013-03-13T07:48:16]: Unable to register source directory:
C:\Documents and Settings\All Users\Application Data\Package
Cache\{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}v1.0.0.0030\, product:
{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}, reason: 0x80070645. Continuing...
[09B4:0D50][2013-03-13T07:48:16]: Registering package dependency provider:
{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}, version: 1.0.0.0030, package:
RADInstall30
[09E8:0A84][2013-03-13T07:48:16]: Applied execute package: RADInstall30,
result: 0x0, restart: None
[09B4:0D50][2013-03-13T07:48:16]: Registering dependency:
{08b55420-861a-4f92-b56f-120c85eb2455} on package provider:
{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}, package: RADInstall30
[09B4:0D50][2013-03-13T07:48:16]: Removing cached package: RADInstall30, from
path: C:\Documents and Settings\All Users\Application Data\Package
Cache\{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}v1.0.0.0030\
[09E8:0A84][2013-03-13T07:48:16]: Apply complete, result: 0x0, restart: None,
ba requested restart: No
Final registry key after transform is applied:
Here is a snapshot of :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{CA11308E-C505-48B9-BD2F-340095256AE9}
Below is the log from the uninstall:
[07E8:0544][2013-03-13T07:55:15]: Detected partially cached package:
RADInstall30, invalid payload: RADInstall30, reason: 0x80070570
[07E8:0544][2013-03-13T07:55:15]: Detected partially cached package:
RADInstall30, invalid payload: cab07A065F47DD6E9FCDAE62ABCDDF335E7, reason:
0x80070570
[07E8:0544][2013-03-13T07:55:15]: Detected package: RADInstall30, state:
Absent, cached: Partial
[07E8:0544][2013-03-13T07:55:15]: Detect complete, result: 0x0
[07E8:0544][2013-03-13T07:55:17]: Plan 1 packages, action: Uninstall
[07E8:0544][2013-03-13T07:55:17]: Planned package: RADInstall30, state: Absent,
default requested: Absent, ba requested: Absent, execute: None, rollback: None,
cache: No, uncache: Yes, dependency: Unregister
[07E8:0544][2013-03-13T07:55:17]: Plan complete, result: 0x0
[07E8:0544][2013-03-13T07:55:17]: Apply begin
[0D8C:090C][2013-03-13T07:55:24]: Automatic updates could not be paused due to
error: 0x80070422. Continuing...
[0D8C:090C][2013-03-13T07:55:24]: Creating a system restore point.
[0D8C:090C][2013-03-13T07:55:28]: Created a system restore point.
[0D8C:090C][2013-03-13T07:55:28]: Removed dependency:
{08b55420-861a-4f92-b56f-120c85eb2455} on
Re: [WiX-users] Looking at WiX to generate a Chained installpackage.
And that is what we are looking for, simplicity for the admins. Our Chained product contains 5 main product installers and up to 59 language pack installers and therefore we did not want to have the system admin to have to enter so many installer .msi. So having a single chain .msi to push would be a lot better than having multiple msi's.. Thanks, Tim. From: Wyrdfish [via Windows Installer XML (WiX) toolset] [mailto:ml-node+s687559n7584353...@n2.nabble.com] Sent: Thursday, March 14, 2013 11:06 AM To: Tim Mayert Subject: Re: Looking at WiX to generate a Chained installpackage. Not really sure what you are meaning by an embedded UI here. GPO publishes MSIs silently to client machines. Also its possible to push several MSIs as part of one policy (we have to document this for our customers so they can install prerequisites) so I don't see an absolute requirement for chaining apart from simplicity. Dave W. -Original Message- From: Rob Mensching [mailto:[hidden email]/user/SendEmail.jtp?type=nodenode=7584353i=0] Sent: 13 March 2013 18:14 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Looking at WiX to generate a Chained installpackage. That or a embedded UI would need to be implemented in the WiX toolset. Personally, I jumped over that feature and went for the full blown bootstrapper/chainer with Burn... but GPO functionality does suffer a bit. Might be an interesting feature to implement in the future to provide a stock embedded UI from WiX toolset. On Wed, Feb 27, 2013 at 6:22 AM, TimM [hidden email]/user/SendEmail.jtp?type=nodenode=7584353i=1 wrote: Since we still have a lot of our customers that still use GPO for pushing out our software we still have to have a .msi solution. So again it looks like we have to stay with InstallShield for all our chained projects. Tim. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Looking-at-WiX- to-generate-a-Chained-install-package-tp7583963p7583998.html Sent from the wix-users mailing list archive at Nabble.com. - - Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb ___ WiX-users mailing list [hidden email]/user/SendEmail.jtp?type=nodenode=7584353i=2 https://lists.sourceforge.net/lists/listinfo/wix-users - - Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list [hidden email]/user/SendEmail.jtp?type=nodenode=7584353i=3 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. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list [hidden email]/user/SendEmail.jtp?type=nodenode=7584353i=4 https://lists.sourceforge.net/lists/listinfo/wix-users If you reply to this email, your message will be added to the discussion below: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Looking-at-WiX-to-generate-a-Chained-install-package-tp7583963p7584353.html To unsubscribe from Looking at WiX to generate a Chained install package., click herehttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=7583963code=VGltTWF5ZXJ0QHNtYXJ0dGVjaC5jb218NzU4Mzk2M3wtMTcxMzc3MTUwNA==. NAMLhttp://windows-installer-xml-wix-toolset.687559.n2.nabble.com/template/NamlServlet.jtp?macro=macro_viewerid=instant_html%21nabble%3Aemail.namlbase=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespacebreadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Looking-at-WiX-to-generate-a-Chained-install-package-tp7583963p7584358.html Sent from the wix-users mailing list archive at Nabble.com.
Re: [WiX-users] Any ideas on how to solve MessageBox focus, can be lost (using Custom Action DLL)
Solved :)
Using this:
catch (Exception ex)
{
WriteErrorLogInstall(session, Method failed: , ex, true);
if (session != null)
{
session.Message(
InstallMessage.User + (int)MessageBoxIcon.Error
+ (int)MessageBoxButtons.OK,
new Record { FormatString = Method failed: +
ex.Message });
}
}
thanks all!
Steve
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Any-ideas-on-how-to-solve-MessageBox-focus-can-be-lost-using-Custom-Action-DLL-tp7584319p7584360.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Consume MSDeploy Staged Web Site Output in a WIX Installer
Hi I was integrating wixproject into Main Project.
And below are the changes in Wix SETUP Project Properties.
This is generating the DropContent.WXS Fragment when ever project is build
(ie it is running Heat everytime the whole project is build.) But I want
Heat to be executed only once at first time to create DropContent.wxs .From
next time I don't want to get created for every build. Is their any property
setting possibility of Heat not be executed for every build?
ItemGroup
ProjectReference
Include=..\CBUDirect.Web\WebSite\CBUDirect.Web.csproj
NameCBUDirect.Web/Name
Project{9a937a48-2554-4fd2-b07b-f76f7e29b1e1}/Project
PrivateTrue/Private
DoNotHarvestTrue/DoNotHarvest
RefProjectOutputGroups
/RefProjectOutputGroups
RefTargetDirINSTALLLOCATION/RefTargetDir
WebProjectTrue/WebProject
/ProjectReference
/ItemGroup
Import Project=$(WixTargetsPath) /
Target Name=BeforeBuild
MSBuild Projects=%(ProjectReference.FullPath) Targets=Package
Properties=Configuration=$(Configuration);Platform=AnyCPU
Condition='%(ProjectReference.WebProject)'=='True' /
ItemGroup
LinkerBindInputPaths
Include=%(ProjectReference.RootDir)%(ProjectReference.Directory)obj\$(Configuration)\Package\PackageTmp\
/
/ItemGroup
HeatDirectory OutputFile=DropContent.wxs
Directory=%(ProjectReference.RootDir)%(ProjectReference.Directory)obj\$(Configuration)\Package\PackageTmp\
DirectoryRefId=INSTALLLOCATION ComponentGroupName=CBUDirect
AutogenerateGuids=true ToolPath=$(WixToolPath)
Condition='%(ProjectReference.WebProject)'=='True' /
/Target
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Consume-MSDeploy-Staged-Web-Site-Output-in-a-WIX-Installer-tp7584362.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Using Property's values in Messages
Hey all, can anyone tell me if there's a way to display the value of a property? I'm doing registry searches for different product install directories, and would like to display them to the QAs running the installer. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Property's values in Messages
You can do it various ways, the easiest way is to let QA see the value in the
MSI log file, in your product WXS file add:
Property Id=MsiLogging Value=voicewarmupx/
after the install is done in your %temp% folder will be a MSI log file, look
for the property name and its value will be recorded...
or display the properties via custom actions that will display a messagebox:
i.e.
[CustomAction]
public static ActionResult DisplayProperties(Session session)
{
try
{
if (session == null)
{
throw new ArgumentNullException(session);
}
string tempString = GetSessionProperty(session, MyProperty, false);
session.Message(
InstallMessage.User + (int)MessageBoxIcon.Info +
(int)MessageBoxButtons.OK,
new Record { FormatString = Display the property: +
tempString });
}
catch (Exception ex)
{
if (session != null)
{
session.Message(
InstallMessage.User + (int)MessageBoxIcon.Error +
(int)MessageBoxButtons.OK,
new Record { FormatString = DisplayProperties failed: +
ex.Message });
}
}
return ActionResult.Success;
}
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-Property-s-values-in-Messages-tp7584364p7584365.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Property's values in Messages
Classification: Public
Oops
String tempString = session[MyProperty];
-Original Message-
From: StevenOgilvie [mailto:sogil...@msn.com]
Sent: March-14-13 5:54 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Using Property's values in Messages
You can do it various ways, the easiest way is to let QA see the value in the
MSI log file, in your product WXS file add:
Property Id=MsiLogging Value=voicewarmupx/ after the install is done in
your %temp% folder will be a MSI log file, look for the property name and its
value will be recorded...
or display the properties via custom actions that will display a messagebox:
i.e.
[CustomAction]
public static ActionResult DisplayProperties(Session session) {
try
{
if (session == null)
{
throw new ArgumentNullException(session);
}
string tempString = GetSessionProperty(session, MyProperty, false);
session.Message(
InstallMessage.User + (int)MessageBoxIcon.Info +
(int)MessageBoxButtons.OK,
new Record { FormatString = Display the property: +
tempString });
}
catch (Exception ex)
{
if (session != null)
{
session.Message(
InstallMessage.User + (int)MessageBoxIcon.Error +
(int)MessageBoxButtons.OK,
new Record { FormatString = DisplayProperties failed: +
ex.Message });
}
}
return ActionResult.Success;
}
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-Property-s-values-in-Messages-tp7584364p7584365.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics Download AppDynamics Lite for free
today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
This message has been marked as Public by Steven Ogilvie.
The above classification labels were added to the message by TITUS Message
Classification.
Visit www.titus.com for more information.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] using wildcards with heat
Hi, I'm trying to use heat to harvest files. I'd ideally like to in thi case anyway harvest all *.bat files from a directory to go in to a component group. Is this possible currently. Help appreciated. Cheers Sean. -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn Engine Operations (WAS: Using transforms (regular) to install multiple times per application)
Ok so for an update. After digging through the Burn source I saw it was reading
an XML file from the package (and I assume that it includes the GUID for the
original MSI and not the transform). That is when I noticed that there was
nothing that actually wrote the XML. So I was wondering if it was created on
install or build.
So I took 7-Zip and was able to extract the files from my simple Burn package
and noticed a “0” file. This file seems to equate to the XML file that is being
read. That file seemed to have the GUID for the MSI package embedded. So I
THINK that answers that question.
So from my knowledge research, BURN pre-records the MSI GUID and the
transform effectively breaks the uninstall scenario without a custom action of
some sort.
So I recommended 2 options:
1: Use WiXLibs to package the install with the WiX project for the master MSI
instead of doing a transform. (depending on the environment this may not be
practical, but this gets rid of your need for a transform and tracking the
GUIDs)
2: package a MSIs for each main install you need. (more MSIs to build and
maintain, but no need to worry about transform)
A consideration was given to Merge Modules BUT they also seem to have a GUID
that would need to be transformed as well.
If there is a different scenario that I am missing or a way that I am not
initially seeing, let me know. But the engine doesn’t seem to handle the
transform of the ID GUID of the package well.
Richard Norman
TechX - Technology eXperts
Technical Support Consulting
Phone: 559.464.5042
Web: http://on.fb.me/Ztd9ns
Sent from Windows Mail
From: Richard Norman
Sent: March 14, 2013 10:35 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Using transforms (regular) to install mulitple times
per application
Ok, I am working with Jonathan today in my day job capacity and I have an
understanding of PROBABLY what is happening. If the WiX-devs list is better for
this, let me know...
Based on the install logs and the way BURN appears to work, transforms seem a
bit limited in how BURN handles them (and if someone knows the section of code
I would appreciate the pointer).
Background:
So the transform is working on install. The installation works as expected and
the appropriate transform is applied and installed. On uninstall they are
getting an error saying that the item is not installed (weird cause we did
install it). So looking at the log we see that the initial product GUID is one
value and the transform changes it to a different value. Also the registry
shows that the transform was applied as expected. So far so good.
When we go to uninstall we notice the GUID being used is the old GUID for the
application not the transformed one. This leads to the uninstall error.
What we believe is happening is that BURN is tracking the MSI GUIDs that are
being installed and when the transform is applied and changes that GUID, BURN
has no trace of it.
What we need:
So what we need to do is when a transform is applied, update the XML list that
BURN maintains with the new GUID so that the uninstall tracks it appropriately.
We just need to update this on install only. Once updated it should be fine
going forward. I can see in the BURN source where it reads this XML information
and operates based on that, but I am not 100% sure where this information is
generated. Is it on install or is this done at build time? If at build time is
there a way for us to tell BURN what the GUID will change to? That will resolve
their uninstall problem...
Below are some of the logs during install:
[09B4:06A0][2013-03-13T07:48:14]: Verified acquired payload:
cab07A065F47DD6E9FCDAE62ABCDDF335E7 at path: C:\Documents and Settings\All
Users\Application Data\Package
Cache\.unverified\cab07A065F47DD6E9FCDAE62ABCDDF335E7, moving to: C:\Documents
and Settings\All Users\Application Data\Package
Cache\{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}v1.0.0.0030\cab1.cab.
[09B4:0D50][2013-03-13T07:48:14]: Applying execute package: RADInstall30,
action: Install, path: C:\Documents and Settings\All Users\Application
Data\Package
Cache\{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}v1.0.0.0030\RADInstall30,
arguments: ' ARPSYSTEMCOMPONENT=1 MSIFASTINSTALL=7 TRANSFORMS=:Jon2T
ARPSYSTEMCOMPONENT=1'
[09B4:0D50][2013-03-13T07:48:16]: Unable to register source directory:
C:\Documents and Settings\All Users\Application Data\Package
Cache\{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}v1.0.0.0030\, product:
{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}, reason: 0x80070645. Continuing...
[09B4:0D50][2013-03-13T07:48:16]: Registering package dependency provider:
{8B14C1DC-38C4-4CC6-9B05-5AA4320EC3C5}, version: 1.0.0.0030, package:
RADInstall30
[09E8:0A84][2013-03-13T07:48:16]: Applied execute package: RADInstall30,
result: 0x0, restart: None
[09B4:0D50][2013-03-13T07:48:16]: Registering dependency:
Re: [WiX-users] Consume MSDeploy Staged Web Site Output in a WIX Installer
On Thu, Mar 14, 2013 at 2:09 PM, chennam chatrapathi.chen...@gmail.comwrote: Is their any property setting possibility of Heat not be executed for every build? I don't believe so. My first thought was to modify the Condition to execute HeatDirectory only when the OutputFile does not Exists() but then it occurred to me that you will probably commit this file to source control otherwise you'd be generating it on every build... Why not run Heat directly the one time? -- Edwin G. Castro -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using Property's values in Messages
Thank you Steven, I like the logging option and am running with that for
now.
On Thu, Mar 14, 2013 at 3:00 PM, Steven Ogilvie steven.ogil...@titus.comwrote:
Classification: Public
Oops
String tempString = session[MyProperty];
-Original Message-
From: StevenOgilvie [mailto:sogil...@msn.com]
Sent: March-14-13 5:54 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Using Property's values in Messages
You can do it various ways, the easiest way is to let QA see the value in
the MSI log file, in your product WXS file add:
Property Id=MsiLogging Value=voicewarmupx/ after the install is done
in your %temp% folder will be a MSI log file, look for the property name
and its value will be recorded...
or display the properties via custom actions that will display a
messagebox:
i.e.
[CustomAction]
public static ActionResult DisplayProperties(Session session) {
try
{
if (session == null)
{
throw new ArgumentNullException(session);
}
string tempString = GetSessionProperty(session, MyProperty,
false);
session.Message(
InstallMessage.User + (int)MessageBoxIcon.Info +
(int)MessageBoxButtons.OK,
new Record { FormatString = Display the property: +
tempString });
}
catch (Exception ex)
{
if (session != null)
{
session.Message(
InstallMessage.User + (int)MessageBoxIcon.Error +
(int)MessageBoxButtons.OK,
new Record { FormatString = DisplayProperties failed: +
ex.Message });
}
}
return ActionResult.Success;
}
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Using-Property-s-values-in-Messages-tp7584364p7584365.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics Download AppDynamics Lite for
free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
This message has been marked as Public by Steven Ogilvie.
The above classification labels were added to the message by TITUS Message
Classification.
Visit www.titus.com for more information.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
[image: Share and
enjoy]http://wikimediafoundation.org/wiki/Support_Wikipedia/en
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
