Re: [WiX-users] Adding msi/exe packages outside the burn chain
No. Burn provides a very strong security statement for the contained packages. If you add packages, you'll want to update the bundle to include them in the chain or include the additional packages in a related bundle and launch them in succession. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: gowri.malas...@non.agilent.com [mailto:gowri.malas...@non.agilent.com] Sent: Thursday, April 10, 2014 4:04 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Adding msi/exe packages outside the burn chain Hi, Is there anyway burn can handle installing/uninstalling exe/msi packages which are not part of the chain. In other words these msi/exe packages will be added later at runtime. Currently, I have bunch of MSIs I run part of my burn chain, but the requirement is that burn should be able to pick additional MSIs added to media at later point in time. Thanks Gowri -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] advertised install and user permissions
Is your MSI per-machine? ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: Phill Hogland [mailto:phogl...@rimage.com] Sent: Thursday, April 10, 2014 4:21 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] advertised install and user permissions I have a bundle with a number of msi pacakges, one of which has a feature which is advertised. Recently (probably because I changed something in the authoring) I am noticing a behavior where if I install the bundle, then after that completes successfully, click on the advertised shortcut, then the advertised package is installed. But the change in behaviour is that one of the registry keys produces a warning that the user does not have the correct permissions to write to that key. (The key location is in HKLM.) If I run the bundle again selecting 'repair' (with a verbose log) there is no warning and the key is written successfully. When the bundle launches the package the ALLUSERS is 1. Even though I am using InstallerVersion='500' and testing on Windows 8 x64, when I have MsiLogging=v* I don't get any additional information from the log produced by the advertised portion of the install, which only indicates that it failed to write this specific key. Can someone help my understand the problem and advise on the best approach for a situation were I want the install to be per-machine and I need to write to HKLM. Should I just disallow the advertised feature, or is there something else I should do? Thanks for the assistance! -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/advertised-install-and-user-permissions-tp7594058.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Relative path sometimes used for WiX extension references.
Hi, When I add a reference to WixUtilExtension in my WiX project, this is what gets added to the .wixproj: ItemGroup WixExtension Include=WixUtilExtension HintPath$(WixExtDir)\WixUtilExtension.dll/HintPath NameWixUtilExtension/Name /WixExtension /ItemGroup When my colleague does this, he sometimes gets the above, but usually gets this: ItemGroup WixExtension Include=WixUtilExtension HintPath ..\..\..\..\..\..\..\..\..\..\..\..\..\Program Files (x86)\WiX Toolset v3.8\bin\WixUtilExtension.dll /HintPath NameWixUtilExtension/Name /WixExtension /ItemGroup Which causes an error for me. Although we both have WiX 3.8 installed to the default location (c:\Program Files (x86)\WiX Toolset v3.8) I have all my source on a different drive, so that's where the relative path starts from. Since there's no way that a relative path will ever be able to reference a file on a different drive, it fails on my machine. My colleague is having to check his project changes carefully to make sure he doesn't accidentally break it, and we think the tools could help us more. I'm pretty sure that in his case Votive is thinking aha, I can draw a relative path from here to there! and just using that, while in my case it's deciding it can't possibly do that so it's falling back on whatever $(var.WixExtDir) tells it to do. I found a bug (http://sourceforge.net/p/wix/bugs/2209/) on SourceForge, but though it says migrated I was unable to find a bug on the new bug tracking system. The closest I could find was this one : http://wixtoolset.org/issues/2834/ but that's a totally separate issue. I wonder if 2209 got lost along the way from SF to the new system. Should I create it in the new system? In terms of a fix, I feel like it should always use $(WixExtDir) regardless of whether a relative path *could* be used. Meanwhile, we have to decide how to handle it on our side until it's fixed. We have tools that we could use to check this for us, but that's less than ideal. We could also do what this guy does : http://wixtoolset.org/issues/2834/ and keep our WiX toolset in source control but for various reasons we didn't want to do that. Any ideas? Thanks -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Environment variable ProjectPath is expanded, possible to turn off?
When: 1) A cmd prompt is opened (in this case using the VS2010 CMD prompt) 2) A batch file which has setlocal also has a set projectPath=some_path_to_a_folder (case of the variable name does not matter) 3) And at some point in the same batch file or a different batch file (also using setlocal) but executed in the same CMD window, then light.exe generates LGHT0281 with the message error LGHT0281: The -wixprojectfile option requires a file, but the provided path is a directory: path to the project without project name It also displays the full path to the project file, including the project fil name, as passed into MSBuild. So the message is confusing. Even after the variable in the batch script is removed or renamed, LGHT0281 error continues to be reported until the CMD window is closed and the changed batch file is executed in a new CMD window. While this behavior is a little different than the original post, the core issue seems to be that variables in batch scripts, even different batch scripts run in a particular CMD window, are in the same namespace as environment variables and MSBuild variable, so it would be wise to prefix variable names in a unique manner. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Environment-variable-ProjectPath-is-expanded-possible-to-turn-off-tp7587463p7594066.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Harvesting Performance Counters with Heat
I think you have to register the performance counters using the .NET tools and then harvest them. Neil Apologies in advance for the noob question - I HAVE tried various options but I'm stuck! I have a C# project (VS 2010) that creates a .NET DLL containing (amongst other things) a number of performance counters all in a single category. I'd like to harvest them using heat.exe rather than having to transcribe the details from the .NET designer to my .wxs file. I've tried executing heat.exe perf PerformanceCategoryName -o perf.wxs in various directories within the projects and every time it comes back with heat.exe : error HEAT5060 : Performance category 'PerformanceCategoryName' not found. I'm clearly missing something but what? Many thanks in advance David -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] advertised install and user permissions
Yes, the MSI package has the following: Package Platform=x86 Description=$(var.AppNameLong) InstallerVersion=500 Compressed=yes InstallScope=perMachine SummaryCodepage=!(loc.SummaryCodepage) / When this package is launched as part of the bundle chain the log indicates that ALLUSERS is 1. This package has been installing with the feature advertized, but without complaining about this registry value for some time. However I recently refactored some of the wxs files to make then more maintainable, and I moved this registry key to a different fragment, but also associated with the same advertised feature. This old code, which did not result in an error, and the key was written during the advertised portion of the install: Fragment ComponentGroup Id=QD_HKLM_SOFTWARE_RegKeys Component Directory=QuickDiscDir RegistryValue Root=HKLM Key=SOFTWARE\Company Name=SDA Value=0 Type=integer KeyPath=yes / /Component /ComponentGroup /Fragment This is the current code which does result in the error (but only when being installed as result of advertised feature): Fragment ComponentGroup Id=$(var.ProductAbreviation).uniqueProperties Directory=$(var.ProductDir) Component RegistryValue Root=HKLM Key=$(var.Release_CompanyRegKey) Name=SDA Value=[SDA] Type=integer KeyPath=yes / /Component /ComponentGroup /Fragment I also found that I can add AllowAdvertise=no to the feature and avoid the problem, but I appreciate any advice so that I can understand this behavior and learn the best practices to avoid this problem. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/advertised-install-and-user-permissions-tp7594058p7594070.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Can a Wixlib contain a merge module?
Thanks Rob... It actually turned out to be the first build I did from TeamCity did not link in the merge module as it did not have access to it at the time. So the wixlib that went into the parent just did not have the merge module to install. So I re-verified with the latest build and it correctly linked in the merge module and installed correctly. So everything is working fine now -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Can-a-Wixlib-contain-a-merge-module-tp7594055p7594071.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Testing for Version Numbers??
It worked... Quoting Carter Young ecyo...@grandecom.net: I'm aiming for RuntimeVersion =13.0.8, I'll give this a try tomorrow... Carter On Thursday, April 10, 2014 04:49:47 PM Phill Hogland wrote: In the prior post I meant to have the entity display: InstallCondition=RuntimeVersion amp;lt;=vx.x.x.x -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Testing-for-Version-Numbers-tp7594059p7594061.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- There is one difference between a tax collector and a taxidermist -- the taxidermist leaves the hide. -- Mortimer Caplan -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Best Practice for Updating UI from Custom Action
Hi, I would like to know, what's the best Way for Updating PeogressBar and StatusText From c# Custom Action. Sincerly Chris Wichtiger Hinweis: Diese E-Mail und etwa angehängte Dateien können vertrauliche Informationen enthalten und sind ausschließlich für den/die Adressaten bestimmt. Sollten Sie irrtümlich diese E-Mail erhalten haben, bitten wir Sie, uns darüber zu informieren und die E-Mail aus Ihrem System zu löschen. Das unerlaubte Kopieren und die unbefugte Weitergabe dieser Mail und ihrer Inhalte sind nicht gestattet. Important notice: This email and some of the attached files can contain confidential information and are intended solely for the addressee. Should you have received this email in error, we ask that you inform us about this and delete the email from your system. The illegal copying and unauthorised re-distribution of this email and its contents are not permitted. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding msi/exe packages outside the burn chain
Thanks Rob. Is there a work around to achieve this? -Original Message- From: Rob Mensching [mailto:r...@firegiant.com] Sent: Thursday, April 10, 2014 11:34 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain No. Burn provides a very strong security statement for the contained packages. If you add packages, you'll want to update the bundle to include them in the chain or include the additional packages in a related bundle and launch them in succession. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: gowri.malas...@non.agilent.com [mailto:gowri.malas...@non.agilent.com] Sent: Thursday, April 10, 2014 4:04 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Adding msi/exe packages outside the burn chain Hi, Is there anyway burn can handle installing/uninstalling exe/msi packages which are not part of the chain. In other words these msi/exe packages will be added later at runtime. Currently, I have bunch of MSIs I run part of my burn chain, but the requirement is that burn should be able to pick additional MSIs added to media at later point in time. Thanks Gowri -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding msi/exe packages outside the burn chain
Is there a way to bypass the security features of the Burn engine designed to prevent evil people from slipping malware into your Bundle? I certainly hope not. If you find such a bug, please do let us know. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: gowri.malas...@non.agilent.com [mailto:gowri.malas...@non.agilent.com] Sent: Friday, April 11, 2014 10:26 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain Thanks Rob. Is there a work around to achieve this? -Original Message- From: Rob Mensching [mailto:r...@firegiant.com] Sent: Thursday, April 10, 2014 11:34 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain No. Burn provides a very strong security statement for the contained packages. If you add packages, you'll want to update the bundle to include them in the chain or include the additional packages in a related bundle and launch them in succession. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: gowri.malas...@non.agilent.com [mailto:gowri.malas...@non.agilent.com] Sent: Thursday, April 10, 2014 4:04 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Adding msi/exe packages outside the burn chain Hi, Is there anyway burn can handle installing/uninstalling exe/msi packages which are not part of the chain. In other words these msi/exe packages will be added later at runtime. Currently, I have bunch of MSIs I run part of my burn chain, but the requirement is that burn should be able to pick additional MSIs added to media at later point in time. Thanks Gowri -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding msi/exe packages outside the burn chain
Got it. Thank you Rob. -Original Message- From: Rob Mensching [mailto:r...@firegiant.com] Sent: Friday, April 11, 2014 10:38 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain Is there a way to bypass the security features of the Burn engine designed to prevent evil people from slipping malware into your Bundle? I certainly hope not. If you find such a bug, please do let us know. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: gowri.malas...@non.agilent.com [mailto:gowri.malas...@non.agilent.com] Sent: Friday, April 11, 2014 10:26 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain Thanks Rob. Is there a work around to achieve this? -Original Message- From: Rob Mensching [mailto:r...@firegiant.com] Sent: Thursday, April 10, 2014 11:34 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain No. Burn provides a very strong security statement for the contained packages. If you add packages, you'll want to update the bundle to include them in the chain or include the additional packages in a related bundle and launch them in succession. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: gowri.malas...@non.agilent.com [mailto:gowri.malas...@non.agilent.com] Sent: Thursday, April 10, 2014 4:04 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Adding msi/exe packages outside the burn chain Hi, Is there anyway burn can handle installing/uninstalling exe/msi packages which are not part of the chain. In other words these msi/exe packages will be added later at runtime. Currently, I have bunch of MSIs I run part of my burn chain, but the requirement is that burn should be able to pick additional MSIs added to media at later point in time. Thanks Gowri -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Best Practice for Updating UI from Custom Action
The general methodology is here: http://msdn.microsoft.com/en-us/library/aa367525(v=vs.85).aspx That covers the APIs which probably have C# mappings in DTF (if that's what you're using) The status text comes from the ActionText MSI table, WiX ProgressText. The format is templated and many setups use standard lists of actions. You don't need any code to show your custom action in the status, it's just an action in ProgressText with whatever text you want to provide. If you have the need to dynamically provide your own text, see this: http://stackoverflow.com/questions/11722541/wix-dynamically-changing-the-status-text-during-customaction --- Phil Wilson On Fri, Apr 11, 2014 at 9:53 AM, Arthur, Christopher christopher.art...@vaps.de wrote: Hi, I would like to know, what's the best Way for Updating PeogressBar and StatusText From c# Custom Action. Sincerly Chris Wichtiger Hinweis: Diese E-Mail und etwa angehängte Dateien können vertrauliche Informationen enthalten und sind ausschließlich für den/die Adressaten bestimmt. Sollten Sie irrtümlich diese E-Mail erhalten haben, bitten wir Sie, uns darüber zu informieren und die E-Mail aus Ihrem System zu löschen. Das unerlaubte Kopieren und die unbefugte Weitergabe dieser Mail und ihrer Inhalte sind nicht gestattet. Important notice: This email and some of the attached files can contain confidential information and are intended solely for the addressee. Should you have received this email in error, we ask that you inform us about this and delete the email from your system. The illegal copying and unauthorised re-distribution of this email and its contents are not permitted. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] advertised install and user permissions
When you say it's advertised, I'm not sure whether you're referring to other users on the machine, and if some of the scenarios are about an administrator doing a repair but a limited user can't use the advertised feature correctly. If it's registry data intended for different users it typically goes into HKCU so that each new user gets the data when they use the feature. Windows Installer does not violate security rules, so if the basic situation is that a limited user is doing something that installs registry data to HKLM then I can't see that working without some administrator blessing somewhere (such as via group policy). You probably need logging policy set to get log for these spontaneous repair-type situations: http://support.microsoft.com/kb/223300 or the issue might be that you're using * in MsiLogging, which seems to like * so spell out the options: http://msdn.microsoft.com/en-us/library/aa370322(v=vs.85).aspx --- Phil Wilson On Fri, Apr 11, 2014 at 6:20 AM, Phill Hogland phogl...@rimage.com wrote: Yes, the MSI package has the following: Package Platform=x86 Description=$(var.AppNameLong) InstallerVersion=500 Compressed=yes InstallScope=perMachine SummaryCodepage=!(loc.SummaryCodepage) / When this package is launched as part of the bundle chain the log indicates that ALLUSERS is 1. This package has been installing with the feature advertized, but without complaining about this registry value for some time. However I recently refactored some of the wxs files to make then more maintainable, and I moved this registry key to a different fragment, but also associated with the same advertised feature. This old code, which did not result in an error, and the key was written during the advertised portion of the install: Fragment ComponentGroup Id=QD_HKLM_SOFTWARE_RegKeys Component Directory=QuickDiscDir RegistryValue Root=HKLM Key=SOFTWARE\Company Name=SDA Value=0 Type=integer KeyPath=yes / /Component /ComponentGroup /Fragment This is the current code which does result in the error (but only when being installed as result of advertised feature): Fragment ComponentGroup Id=$(var.ProductAbreviation).uniqueProperties Directory=$(var.ProductDir) Component RegistryValue Root=HKLM Key=$(var.Release_CompanyRegKey) Name=SDA Value=[SDA] Type=integer KeyPath=yes / /Component /ComponentGroup /Fragment I also found that I can add AllowAdvertise=no to the feature and avoid the problem, but I appreciate any advice so that I can understand this behavior and learn the best practices to avoid this problem. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/advertised-install-and-user-permissions-tp7594058p7594070.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] advertised install and user permissions
...ooops MsiLogging, which seems NOT to like * so spell out the options.. --- Phil Wilson On Fri, Apr 11, 2014 at 12:01 PM, Phil Wilson phildgwil...@gmail.com wrote: When you say it's advertised, I'm not sure whether you're referring to other users on the machine, and if some of the scenarios are about an administrator doing a repair but a limited user can't use the advertised feature correctly. If it's registry data intended for different users it typically goes into HKCU so that each new user gets the data when they use the feature. Windows Installer does not violate security rules, so if the basic situation is that a limited user is doing something that installs registry data to HKLM then I can't see that working without some administrator blessing somewhere (such as via group policy). You probably need logging policy set to get log for these spontaneous repair-type situations: http://support.microsoft.com/kb/223300 or the issue might be that you're using * in MsiLogging, which seems to like * so spell out the options: http://msdn.microsoft.com/en-us/library/aa370322(v=vs.85).aspx --- Phil Wilson On Fri, Apr 11, 2014 at 6:20 AM, Phill Hogland phogl...@rimage.com wrote: Yes, the MSI package has the following: Package Platform=x86 Description=$(var.AppNameLong) InstallerVersion=500 Compressed=yes InstallScope=perMachine SummaryCodepage=!(loc.SummaryCodepage) / When this package is launched as part of the bundle chain the log indicates that ALLUSERS is 1. This package has been installing with the feature advertized, but without complaining about this registry value for some time. However I recently refactored some of the wxs files to make then more maintainable, and I moved this registry key to a different fragment, but also associated with the same advertised feature. This old code, which did not result in an error, and the key was written during the advertised portion of the install: Fragment ComponentGroup Id=QD_HKLM_SOFTWARE_RegKeys Component Directory=QuickDiscDir RegistryValue Root=HKLM Key=SOFTWARE\Company Name=SDA Value=0 Type=integer KeyPath=yes / /Component /ComponentGroup /Fragment This is the current code which does result in the error (but only when being installed as result of advertised feature): Fragment ComponentGroup Id=$(var.ProductAbreviation).uniqueProperties Directory=$(var.ProductDir) Component RegistryValue Root=HKLM Key=$(var.Release_CompanyRegKey) Name=SDA Value=[SDA] Type=integer KeyPath=yes / /Component /ComponentGroup /Fragment I also found that I can add AllowAdvertise=no to the feature and avoid the problem, but I appreciate any advice so that I can understand this behavior and learn the best practices to avoid this problem. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/advertised-install-and-user-permissions-tp7594058p7594070.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding msi/exe packages outside the burn chain
Note: there have been discussions about adding a feature called modifiable chain to Burn. However, the security implications are massively challenging and backwards compatibility would be ratcheted up. At this point, is far more straight forward and secure to distribute an updated bundle. Since Burn is so smart about sharing packages, updates where most of the packages are already on the machine are really fast. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: gowri.malas...@non.agilent.com [mailto:gowri.malas...@non.agilent.com] Sent: Friday, April 11, 2014 11:54 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain Got it. Thank you Rob. -Original Message- From: Rob Mensching [mailto:r...@firegiant.com] Sent: Friday, April 11, 2014 10:38 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain Is there a way to bypass the security features of the Burn engine designed to prevent evil people from slipping malware into your Bundle? I certainly hope not. If you find such a bug, please do let us know. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: gowri.malas...@non.agilent.com [mailto:gowri.malas...@non.agilent.com] Sent: Friday, April 11, 2014 10:26 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain Thanks Rob. Is there a work around to achieve this? -Original Message- From: Rob Mensching [mailto:r...@firegiant.com] Sent: Thursday, April 10, 2014 11:34 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Adding msi/exe packages outside the burn chain No. Burn provides a very strong security statement for the contained packages. If you add packages, you'll want to update the bundle to include them in the chain or include the additional packages in a related bundle and launch them in succession. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: gowri.malas...@non.agilent.com [mailto:gowri.malas...@non.agilent.com] Sent: Thursday, April 10, 2014 4:04 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Adding msi/exe packages outside the burn chain Hi, Is there anyway burn can handle installing/uninstalling exe/msi packages which are not part of the chain. In other words these msi/exe packages will be added later at runtime. Currently, I have bunch of MSIs I run part of my burn chain, but the requirement is that burn should be able to pick additional MSIs added to media at later point in time. Thanks Gowri -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration
[WiX-users] unsubscribe
-- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Util:XmlFile Custom Action Displaying Sensitive Information in Log Files
Hi all, How does one handle the situation where the Util:XmlFile custom action logs sensitive information to the log file? Eg: MSI (s) (F8:8C) [11:43:03:072]: Executing op: ActionStart(Name=ExecXmlFile,,) MSI (s) (F8:8C) [11:43:03:074]: Executing op: CustomActionSchedule(Action=ExecXmlFile,ActionType=3073,Source=BinaryData,Target=ExecXmlFile,CustomActionData=2€0€C:\Program Files\ABC\File.exe.config€3€0€//configuration/connectionStrings/add[@name='ABC']€connectionString€User ID=user;Password='q9h581)D3]';) This messagehttps://www.mail-archive.com/wix-users@lists.sourceforge.net/msg54073.html by RobM suggests that the situation is a bug. (Dec 2012) It looks like this issue was addressed previously (bug3859http://wixtoolset.org/issues/3859/), but the result was that it is not a bug by Bob Arnson (Oct 2013). I found the workaround hack of adjusting the Type in the CustomAction table for the ExecXmlFile Action after the msi is produced... Is this the only way? Thanks, Kevin -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] advertised install and user permissions
I don't want to violate the security. The applications in the bundle were installed on the first install in a per-machine install. Burn was elevated at the UAC prompt. There are many other keys which are part of this app which are also written under HKLM. (I am not intending to do a per-user install.) However in one MSI package in my bundle chain, the only Feature had: Feature Id=QuickDisc Title=$(var.AppName) Level=1 InstallDefault=local TypicalDefault=advertise and there is a shortcut on the desktop which is advertised. So for some time now (testing on Windows 8) I run the bundle and all packages get installed, but the files related to this particular package do not get installed, until after the bundle completes and I click on the application's desktop shortcut. At which point msiexec launches the package to do what I am calling the 'advertised' install of the files, and then launches the application. (I did not realize that it is a 'repair' if that is the case.) So these registry keys that write to HKLM have been part of the package for some time, but only recently does this one fragment, which I moved from one wxs to another wxs file start displaying this error. The log for this package when Burn is running is verbose, but when the shortcut launches msiexec only the error line is displayed. I will work on this more next week. Since I want to install the application on a per-machine basis (and write config info to HKLM) it sounds like I should not allow the feature to be advertised (or go back to the application developer and get them to write the application so that interaction with HKLM is not needed, which I would prefer). I think I assumed that when Burn was run, and UAC was accepted to elevate the install, that the automatic invoking of msiexec by clicking on the advertised shortcut would either also run elevated (or that the elevated stuff had already been done when the package was launched by burn as a per-machine ALLUSER=1 package). So am a little confused wondering: 1) why it worked for so long and when I moved source code it stopped working? (I know, I should know what I changed more than others.) But I wonder if I am missing something in understanding this. 2) If the install of the application (by clicking on the advertised shortcut) is in a per user context, and this is a per-machine setup, should I disable advertising the feature? or do something else to prevent this? In the MSI package (on Win 7 and later, based on the MSDN ALLUSERS docs) should set the properties in my MSI of ALLUSERS and MSIINSTALLPERUSER to assure a per-machine installation? I'm just wondering what the best approach for a per-machine installation, and not trying to do something that would violate security. thanks for any advice. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/advertised-install-and-user-permissions-tp7594058p7594083.html Sent from the wix-users mailing list archive at Nabble.com. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
