Re: [WiX-users] Burn: package ref-counting not working
There were some changes post-beta and we're working to get a new build published. Most of the scenarios are working now. Stayed tuned on http://blogs.msdn.com/heaths for more information when I can find time to start documenting the feature (and the protocol). On Thursday, January 12, 2012, Kryschan wrote: Hi folks, as I read in the WiX 3.6 Beta release notes, burn does support package ref-counting now, which according to my understanding should guarantee, that shared packages are uninstalled only if all bundles sharing the packages were removed. Here is a little example: - install Bundle1(containing SharedPackage, Package1) - install Bundle2(containing SharedPackage, Package2) - uninstall Bundle1 -- results in removal of SharedPackage and Package1 I would expect that only Package1 gets removed. Am I just misunderstanding the feature or may I miss something in my bundle definitions? Best regards Christian -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-package-ref-counting-not-working-tp7183258p7183258.html Sent from the wix-users mailing list archive at Nabble.com. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net javascript:; https://lists.sourceforge.net/lists/listinfo/wix-users -- *Heath Stewart *Visual Studio Professional Deployment Experience team, Microsoft http://blogs.msdn.com/heaths -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Applying a patch (.msp) doesn't increase the product version
You need to add PropertyRef Id=ProductVersion/ to a patch family. I recommend using a unique patch family only for that purpose. Note that if you have other components in the same entry section (i.e., Product element fragment) they will be included as well. It's best to always put anything that can be in a fragment in a fragment (like features, components, custom actions/binary, etc.). On Thursday, January 12, 2012, Bob Arnson wrote: On 11-Jan-12 03:00, Ulrich Proeller wrote: The switch -sf in the pyro command was added the get rid of a duplicate key error. That's likely the root cause of your problem. Fix the underlying bug before trying workarounds. -- sig://boB http://joyofsetup.com/ -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net javascript:; https://lists.sourceforge.net/lists/listinfo/wix-users -- *Heath Stewart *Visual Studio Professional Deployment Experience team, Microsoft http://blogs.msdn.com/heaths -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Burn EXEPackage Condition does not get evaluated when MSIPackage Installation is cancelled
Hi All, I have been having problems with the Burn bootstrapper when the MSIPackage is installed with the DisplayInternalUI=yes. We need this as a requirement. The problem I face is that When we click on Cancel for the MSI installation, the whole prerequisite is going into a reinstall or repair mode bypassing the InstallCondition of each EXEPackage that is defined. Is this a bug or am I doing it wrong? Also how can I block from the bundle from being installed when the MSI is already installed? I have tried the Condition element in the bundle but it seems to bypass that too. Below is my codes: BUNDLE.WXS: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util=http://schemas.microsoft.com/wix/UtilExtension; Bundle Version=6.0.0.16 Condition=NOT WixSOIInstalled IconSourceFile=..\SourceFiles\setup.ico UpgradeCode=7CD9A5CB-A250-426A-939A-49751499C42E BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.RtfLicense / WixVariable Id=WixStdbaLicenseRtf Value=..\SourceFiles\License.rtf / WixVariable Id=WixStdbaLogo Value=..\SourceFiles\logo_next.png / WixVariable Id=WixStdbaThemeXml Value=..\SourceFiles\ExactRtfTheme.xml/ util:ProductSearch Guid =183B99EC-EF7E-46ac-ACA0-28D06BEE1604 Id =SOIInstalledSearch Variable =WixSOIInstalled / Chain PackageGroupRef Id=NetFX40 / PackageGroupRef Id=VSTO40x86 / PackageGroupRef Id=VSTO40x64 / MsiPackage Name=Office Integration Compressed=yes Vital=yes SourceFile=..\SourceFiles\OfficeIntegration.msi DisplayInternalUI=yes InstallCondition=NOT WixSOIInstalled /MsiPackage /Chain /Bundle /Wix NETFX.WXS: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util=http://schemas.microsoft.com/wix/UtilExtension; Fragment util:RegistrySearch Root=HKLM Key=SOFTWARE\Microsoft\Net Framework Setup\NDP\v4\Full Value=Install Variable=NetFX40Install / util:RegistrySearch Root=HKLM Key=SOFTWARE\Wow6432Node\Microsoft\Net Framework Setup\NDP\v4\Full Value=Install Variable=NetFX40x64Install/ PackageGroup Id=NetFX40 ExePackage Id=dotNetFx40_Full_x86_x64.exe Vital=yes SourceFile=..\SourceFiles\dotNetFx40_Full_setup.exe DownloadUrl=http://www.microsoft.com/download/en/details.aspx?id=17851; InstallCommand=/q /norestart /log %TEMP%\dotNetFx40install.log DetectCondition=(NetFX40Install = 1) OR (NetFX40x64Install = 1) InstallCondition=NOT NetFX40Install OR (VersionNT64 AND NOT NetFX40x64Install) PerMachine =yes Permanent =yes Name =.NET Framework 4.0 full runtime / /PackageGroup /Fragment /Wix VSTO.WXS: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util=http://schemas.microsoft.com/wix/UtilExtension; Fragment util:RegistrySearch Root=HKLM Key=Software\Microsoft\vsto runtime setup\v4R Value=VSTORFeature_CLR40 Variable=VSTO40x86Install / PackageGroup Id=VSTO40x86 ExePackage Id=vstor40_x86.exe Vital=yes SourceFile=..\SourceFiles\vstor40_x86.exe DownloadUrl=http://www.microsoft.com/download/en/details.aspx?id=20479; InstallCommand=/q DetectCondition=VSTO40x86Install = 1 InstallCondition=NOT VersionNT64 AND NOT VSTO40x86Install PerMachine =yes Permanent =yes Name =Visual Studio 2010 for Office Runtime (x86) / /PackageGroup /Fragment /Wix -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Dependency Schema
Hi All I want to use a dependency on another product , can someone tell me how to do this? -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn EXEPackage Condition does not get evaluated when MSIPackage Installation is cancelled
Addiditonal info: If I try to Disable the UI for the MSIPackage, it fails since the UAC is turned on and the prompt to key in the admin credentials are not shown. The MSI already have the elevated value in its package. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-EXEPackage-Condition-does-not-get-evaluated-when-MSIPackage-Installation-is-cancelled-tp7183696p7183801.html Sent from the wix-users mailing list archive at Nabble.com. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068
On Fri, Jan 13, 2012 at 7:48 AM, Peter Hull peterhul...@hotmail.com wrote: Date: Thu, 12 Jan 2012 20:56:15 +0100 From: n...@panorama9.com I would start by digitally signing your burn bundle. The bundle is already signed with a Thawte code signing certificate The reported file name looks more like it's the extracted engine than your bundle itself. Have you signed the engine. I only think we have signed the bundle, so we are working on signing the engine and retesting to see if it makes a difference. Either should Trend Micro change there detection mechanism regarding the RunOnce key or the bundling framework of burn should change its default behavior . From the Trend docs I saw it seemed to suggest that 'Malware Behaviour Monitoring' could be turned off (indeed, terminating programs like this was not the default) and also that signed executables were exempt. So it maybe is a bug in Trend that means it doesn't work as documented? Maybe, but as this is the default setting for a Trend Micro installation it is quite a problem. The other thing is that other installers (InstallShield) don't seem to do this so does anyone understand how InstallShield handles the reboot issue? Don't know , but it could be that they don't look in the RunOnce key as default behavior in their engine and thereby don't have this issue ? Pete -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Best Regards Nikolaj Steensgaard Panorama9 A/S Langebrogade 5 1411 Copenhagen K Phone: +45 7020 3565 Mobile: +45 2124 3040 n...@panorama9.com Panorama9 is an IT management platform that shows you everything you need to know about your assets, IT availability, security vulnerabilities, and non-compliant systems – from a single Dashboard that’s amazingly easy to monitor and interpret. Your organization can cut IT costs through improved uptime and as a cloud-based solution, there is no infrastructure to deploy or manage. For more information - www.panorama9.com -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install
Those were my thoughts initially as well but for this particular setting that doesn't work. :( Jon -Original Message- From: Dan Gough [mailto:goug...@gmail.com] Sent: Thursday, January 12, 2012 6:21 PM To: chr...@iswix.com; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Or try applying the key to HKLM rather than HKCU in the first place. Many Windows settings can apply to either key to give you the flexibility of having each setting system-wide or per-user. On Thu, Jan 12, 2012 at 9:34 PM, Christopher Painter chr...@iswix.comwrote: The Registry element has a Root attribute that you can set to HKCU. If your program has an advertised shortcut you can use this to trigger resilency to complete the installation for each user who uses your app. It's an ugly story though like the old Office install that popped up every time you went to a new conference room and logged in. http://wix.sourceforge.net/manual-wix3/wix_xsd_registry.htm Here's an alternative approach that avoids all that: http://blogs.flexerasoftware.com/installtalk/2011/11/using-active-setu p-to-r epair-user-settings.html From: McCain, Jon jon.mcc...@inin.com Sent: Thursday, January 12, 2012 3:28 PM To: General discussion for Windows Installer XML toolset. (wix-users@lists.sourceforge.net) wix-users@lists.sourceforge.net Subject: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install I have been working on a new install where a context menu is added to the Right-Click Menu within Internet Explorer. Everything I have read regarding this requires the key be added to HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer. This does work but the issue I have is that our installs are run as per-machine installs and this causes other users that login to not have this menu. Links to MSDN articles explaining context menu additions for Internet Explorer: http://msdn.microsoft.com/en-us/library/aa753589%28VS.85%29.aspx The wxs code is quite simple for this addition: RegistryValue Id=ctd_classinfo_183 Action=write Type=string Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\keyName Value=[#FileID]/ RegistryValue Id=ctd_classinfo_184 Action=write Type=string Root=HKCU Key=Software\Microsoft\Internet Explorer\MenuExt\ keyName \Contexts Value=1/ Has anyone run into this or another issue where a per-machine install is performed but features or other items need to exist for all users in the above fashion? Thanks, Jon -- -- -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Writing JDK version verification code, and Wix debugging tip
Here is something I had put together quite a while ago that works for me. You should be able to modify it to do what you need. You could change the CustomAction to SetProperty elements. Condition Message=!(loc.Java160MustBeInstalled)JAVA_JRE_HOME/Condition Property Id=JAVA_JDK_CURRENT_VERSION/ Property Id=JAVA_JRE_CURRENT_VERSION/ Property Id=JAVA_JDK_HOME/ Property Id=JAVA_JRE_HOME/ Property Id=JAVA_JDK_VERSION RegistrySearch Id=SUN_JDK_VERSION Root=HKLM Key=SOFTWARE\Javasoft\Java Development Kit Name=CurrentVersion Type=raw/ /Property Property Id=JAVA_JRE_VERSION RegistrySearch Id=SUN_JRE_VERSION Root=HKLM Key=SOFTWARE\Javasoft\Java Runtime Environment Name=CurrentVersion Type=raw/ /Property CustomAction Id=SetJavaJDKCurrentVersion Property=JAVA_JDK_CURRENT_VERSION Value=HKLM\SOFTWARE\Javasoft\Java Development Kit\[JAVA_JDK_VERSION]/ CustomAction Id=SetJavaJRECurrentVersion Property=JAVA_JRE_CURRENT_VERSION Value=HKLM\SOFTWARE\Javasoft\Java Runtime Environment\[JAVA_JRE_VERSION]/ InstallUISequence Custom Action=SetJavaJDKCurrentVersion Before=FindRelatedProducts/ Custom Action=SetJavaJRECurrentVersion After=SetJavaJDKCurrentVersion/ Custom Action=SetJavaJdkJreHome After=SetJavaJRECurrentVersion/ /InstallUISequence ?include ..\..\build\SetJavaJdkJreHomeVBS.wxi? SetJavaJdkJreHomeVBS.wxi: ?xml version=1.0 encoding=UTF-8? Include xmlns=http://schemas.microsoft.com/wix/2006/wi; !-- Set the Java JDK and JRE home directory properties -- CustomAction Id=SetJavaJdkJreHome Script=vbscript ![CDATA[ jdkCurrentVersion = Session.Property(JAVA_JDK_CURRENT_VERSION) jreCurrentVersion = Session.Property(JAVA_JRE_CURRENT_VERSION) defaultVer = 1.6 defaultValue = notset jdkHomeKey = jdkCurrentVersion \JavaHome 'MsgBox Java JDK Home Reg Key = jdkHomeKey, vbOkOnly jdkHome = readfromRegistry(jdkHomeKey, defaultHome) jreHomeKey = jreCurrentVersion \JavaHome 'MsgBox Java JRE Home Reg Key = jreHomeKey, vbOkOnly jreHome = readfromRegistry(jreHomeKey, defaultHome) ' Only set the properties if a value was found in the registry if jdkHome defaultValue then Session.Property(JAVA_JDK_HOME) = jdkHome end if if jreHome defaultValue then Session.Property(JAVA_JRE_HOME) = jreHome end if function readFromRegistry (strRegistryKey, strDefault ) Dim WSHShell, value On Error Resume Next Set WSHShell = CreateObject(WScript.Shell) value = WSHShell.RegRead( strRegistryKey ) 'MsgBox SetJavaJdkJreHome vbCrLf _ ' Registry key to read: strRegistryKey vbCrLf _ ' Default value: strDefault vbCrLf _ ' Value read: ' value ' vbCrLf _ ' err.number = err.number, vbOkOnly if err.number 0 then readFromRegistry= strDefault else readFromRegistry=value end if set WSHShell = nothing end function ]] /CustomAction /Include On Thu, Jan 12, 2012 at 4:27 PM, Christopher Painter chr...@iswix.comwrote: My memory of the way Java stores there version information in the registry isn't very friendly to MSI's RegLocator pattern. You might need a custom action. From: T. Kuro Kurosaka k...@basistech.com Sent: Thursday, January 12, 2012 6:21 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Writing JDK version verification code, and Wix debugging tip Wix MSI newbie here. My product requires JDK 1.6 installation, and I'm trying to come up with Wix code to verify the system has JDK 1.5 installed before proceeding installation of my product. I thought this would work: Property Id=JDKVER RegistrySearch Id=NetFramework20 Root=HKLM Key=SOFTWARE\JavaSoft\Java Development Kit Name=CurrentVersion Type=raw / /Property Condition Message=This application requires Java Developer Kit 1.5 (or higher). ![CDATA[Installed OR (JDKVER 1.5 )]] !-- test with 1.6, 1.7, 1.8, etc. will be added later. -- /Condition But this didn't work. Even if JDK 1.5 is installed, this message is displayed. Anybody has experience doing JDK version check? In an attempt to debug this, I wanted to display the value of property JDKVER, and inserted this code. This is a modified version of the code I've found in the Internet: CustomAction Id=ShowProperty Script=vbscript Execute=immediate
Re: [WiX-users] Writing JDK version verification code, and Wix debugging tip
Why not check it when the application starts up ? It'll be easier to code and the user has the option of installing Java after your product instead of forcing it to be done beforehand. -Original Message- From: T. Kuro Kurosaka [mailto:k...@basistech.com] Sent: 12 January 2012 23:50 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Writing JDK version verification code,and Wix debugging tip Wix MSI newbie here. My product requires JDK 1.6 installation, and I'm trying to come up with Wix code to verify the system has JDK 1.5 installed before proceeding installation of my product. I thought this would work: Property Id=JDKVER RegistrySearch Id=NetFramework20 Root=HKLM Key=SOFTWARE\JavaSoft\Java Development Kit Name=CurrentVersion Type=raw / /Property Condition Message=This application requires Java Developer Kit 1.5 (or higher). ![CDATA[Installed OR (JDKVER 1.5 )]] !-- test with 1.6, 1.7, 1.8, etc. will be added later. -- /Condition But this didn't work. Even if JDK 1.5 is installed, this message is displayed. Anybody has experience doing JDK version check? In an attempt to debug this, I wanted to display the value of property JDKVER, and inserted this code. This is a modified version of the code I've found in the Internet: CustomAction Id=ShowProperty Script=vbscript Execute=immediate ![CDATA[ MsgBox JDKVER = + Session.Property(JDKVER) ]] /CustomAction InstallExecuteSequence Custom Action=ShowProperty Before=InstallFinalizeTrue/Custom !-- Not Installed didn't work either. -- /InstallExecuteSequence But no popup came out. What am I doing wrong here? Thank you in advance. T. Kuro Kurosaka - - RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ 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. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Writing JDK version verification code, and Wix debugging tip
The app being installed is a Java app. Can't run it without Java being installed. If Java isn't installed, the installer needs to quit with an error msg to the user. On Fri, Jan 13, 2012 at 7:28 AM, Peter Shirtcliffe pshirtcli...@sdl.comwrote: Why not check it when the application starts up ? It'll be easier to code and the user has the option of installing Java after your product instead of forcing it to be done beforehand. -Original Message- From: T. Kuro Kurosaka [mailto:k...@basistech.com] Sent: 12 January 2012 23:50 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Writing JDK version verification code,and Wix debugging tip Wix MSI newbie here. My product requires JDK 1.6 installation, and I'm trying to come up with Wix code to verify the system has JDK 1.5 installed before proceeding installation of my product. I thought this would work: Property Id=JDKVER RegistrySearch Id=NetFramework20 Root=HKLM Key=SOFTWARE\JavaSoft\Java Development Kit Name=CurrentVersion Type=raw / /Property Condition Message=This application requires Java Developer Kit 1.5 (or higher). ![CDATA[Installed OR (JDKVER 1.5 )]] !-- test with 1.6, 1.7, 1.8, etc. will be added later. -- /Condition But this didn't work. Even if JDK 1.5 is installed, this message is displayed. Anybody has experience doing JDK version check? In an attempt to debug this, I wanted to display the value of property JDKVER, and inserted this code. This is a modified version of the code I've found in the Internet: CustomAction Id=ShowProperty Script=vbscript Execute=immediate ![CDATA[ MsgBox JDKVER = + Session.Property(JDKVER) ]] /CustomAction InstallExecuteSequence Custom Action=ShowProperty Before=InstallFinalizeTrue/Custom !-- Not Installed didn't work either. -- /InstallExecuteSequence But no popup came out. What am I doing wrong here? Thank you in advance. T. Kuro Kurosaka - - RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ 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. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Writing JDK version verification code, and Wix debugging tip
Much as I don't like to put people off MSI, would something like Java Web Start serve you better ? We test for JRE installations in our product using the upgrade code/product code. This is easy to test for if you're only interested in a specific JRE/JDK version. You could do this with the upgrade table without resorting to custom actions. You'd have to download all the compatible versions and pull out the product and upgrade codes unless Oracle have a KB article for them. Just be careful of the upgrade/parallel installation option that modifies the product code. -Original Message- From: Mike Rerick [mailto:mrer...@iwsinc.com] Sent: 13 January 2012 15:38 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Writing JDK version verification code, and Wix debugging tip The app being installed is a Java app. Can't run it without Java being installed. If Java isn't installed, the installer needs to quit with an error msg to the user. On Fri, Jan 13, 2012 at 7:28 AM, Peter Shirtcliffe pshirtcli...@sdl.comwrote: Why not check it when the application starts up ? It'll be easier to code and the user has the option of installing Java after your product instead of forcing it to be done beforehand. -Original Message- From: T. Kuro Kurosaka [mailto:k...@basistech.com] Sent: 12 January 2012 23:50 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Writing JDK version verification code,and Wix debugging tip Wix MSI newbie here. My product requires JDK 1.6 installation, and I'm trying to come up with Wix code to verify the system has JDK 1.5 installed before proceeding installation of my product. I thought this would work: Property Id=JDKVER RegistrySearch Id=NetFramework20 Root=HKLM Key=SOFTWARE\JavaSoft\Java Development Kit Name=CurrentVersion Type=raw / /Property Condition Message=This application requires Java Developer Kit 1.5 (or higher). ![CDATA[Installed OR (JDKVER 1.5 )]] !-- test with 1.6, 1.7, 1.8, etc. will be added later. -- /Condition But this didn't work. Even if JDK 1.5 is installed, this message is displayed. Anybody has experience doing JDK version check? In an attempt to debug this, I wanted to display the value of property JDKVER, and inserted this code. This is a modified version of the code I've found in the Internet: CustomAction Id=ShowProperty Script=vbscript Execute=immediate ![CDATA[ MsgBox JDKVER = + Session.Property(JDKVER) ]] /CustomAction InstallExecuteSequence Custom Action=ShowProperty Before=InstallFinalizeTrue/Custom !-- Not Installed didn't work either. -- /InstallExecuteSequence But no popup came out. What am I doing wrong here? Thank you in advance. T. Kuro Kurosaka - - RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ 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. - - RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Writing JDK version verification code, and Wix debugging tip
Unfortunately, for a lot of our customers, the device/server the app is being installed on probably won't have access to the internet. The install had to be written to the lowest common denominator - a standalone device without any connectivity. On Fri, Jan 13, 2012 at 7:45 AM, Peter Shirtcliffe pshirtcli...@sdl.comwrote: Much as I don't like to put people off MSI, would something like Java Web Start serve you better ? We test for JRE installations in our product using the upgrade code/product code. This is easy to test for if you're only interested in a specific JRE/JDK version. You could do this with the upgrade table without resorting to custom actions. You'd have to download all the compatible versions and pull out the product and upgrade codes unless Oracle have a KB article for them. Just be careful of the upgrade/parallel installation option that modifies the product code. -Original Message- From: Mike Rerick [mailto:mrer...@iwsinc.com] Sent: 13 January 2012 15:38 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Writing JDK version verification code, and Wix debugging tip The app being installed is a Java app. Can't run it without Java being installed. If Java isn't installed, the installer needs to quit with an error msg to the user. On Fri, Jan 13, 2012 at 7:28 AM, Peter Shirtcliffe pshirtcli...@sdl.comwrote: Why not check it when the application starts up ? It'll be easier to code and the user has the option of installing Java after your product instead of forcing it to be done beforehand. -Original Message- From: T. Kuro Kurosaka [mailto:k...@basistech.com] Sent: 12 January 2012 23:50 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Writing JDK version verification code,and Wix debugging tip Wix MSI newbie here. My product requires JDK 1.6 installation, and I'm trying to come up with Wix code to verify the system has JDK 1.5 installed before proceeding installation of my product. I thought this would work: Property Id=JDKVER RegistrySearch Id=NetFramework20 Root=HKLM Key=SOFTWARE\JavaSoft\Java Development Kit Name=CurrentVersion Type=raw / /Property Condition Message=This application requires Java Developer Kit 1.5 (or higher). ![CDATA[Installed OR (JDKVER 1.5 )]] !-- test with 1.6, 1.7, 1.8, etc. will be added later. -- /Condition But this didn't work. Even if JDK 1.5 is installed, this message is displayed. Anybody has experience doing JDK version check? In an attempt to debug this, I wanted to display the value of property JDKVER, and inserted this code. This is a modified version of the code I've found in the Internet: CustomAction Id=ShowProperty Script=vbscript Execute=immediate ![CDATA[ MsgBox JDKVER = + Session.Property(JDKVER) ]] /CustomAction InstallExecuteSequence Custom Action=ShowProperty Before=InstallFinalizeTrue/Custom !-- Not Installed didn't work either. -- /InstallExecuteSequence But no popup came out. What am I doing wrong here? Thank you in advance. T. Kuro Kurosaka - - RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ 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. - - RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2
Re: [WiX-users] Writing JDK version verification code, and Wix debugging tip
In principal, you can search the environment variables (like JAVA_HOME) for the relevant executable. You could extend this to also search in all the usual locations where Java is installed also. Once you've got some candidates, you can check the versions of each of them for suitability in the usual manner. I'm thinking you'd probably want to have something like the ngen scanning action in the NetFX extension. That way, if there were multiple versions of Java installed (a definite possibility) you could reject those that are unsuitable and select the highest version that is suitable (or a specific version, in necessary). -- John Merryweather Cooper Build Install Engineer - Enterprise Application Development Jack Henry Associates, Inc.(r) Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Mike Rerick [mailto:mrer...@iwsinc.com] Sent: Friday, January 13, 2012 9:38 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Writing JDK version verification code, and Wix debugging tip The app being installed is a Java app. Can't run it without Java being installed. If Java isn't installed, the installer needs to quit with an error msg to the user. On Fri, Jan 13, 2012 at 7:28 AM, Peter Shirtcliffe pshirtcli...@sdl.comwrote: Why not check it when the application starts up ? It'll be easier to code and the user has the option of installing Java after your product instead of forcing it to be done beforehand. -Original Message- From: T. Kuro Kurosaka [mailto:k...@basistech.com] Sent: 12 January 2012 23:50 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Writing JDK version verification code,and Wix debugging tip Wix MSI newbie here. My product requires JDK 1.6 installation, and I'm trying to come up with Wix code to verify the system has JDK 1.5 installed before proceeding installation of my product. I thought this would work: Property Id=JDKVER RegistrySearch Id=NetFramework20 Root=HKLM Key=SOFTWARE\JavaSoft\Java Development Kit Name=CurrentVersion Type=raw / /Property Condition Message=This application requires Java Developer Kit 1.5 (or higher). ![CDATA[Installed OR (JDKVER 1.5 )]] !-- test with 1.6, 1.7, 1.8, etc. will be added later. -- /Condition But this didn't work. Even if JDK 1.5 is installed, this message is displayed. Anybody has experience doing JDK version check? In an attempt to debug this, I wanted to display the value of property JDKVER, and inserted this code. This is a modified version of the code I've found in the Internet: CustomAction Id=ShowProperty Script=vbscript Execute=immediate ![CDATA[ MsgBox JDKVER = + Session.Property(JDKVER) ]] /CustomAction InstallExecuteSequence Custom Action=ShowProperty Before=InstallFinalizeTrue/Custom !-- Not Installed didn't work either. -- /InstallExecuteSequence But no popup came out. What am I doing wrong here? Thank you in advance. T. Kuro Kurosaka - - RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ 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. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly
Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install
I have tried using the Active Setup keys but when the other user logs in the replication isn't occurring nor is the repair type install. Here is what my setup looks like: !--Installed at HKLM so that Active Setup keys can be imployed-- RegistryValue Id=ctd_classinfo_185 Action=write Type=string Root=HKLM Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem Value=[#ctxmenu.htm]/ RegistryValue Id=ctd_classinfo_186 Action=write Type=string Root=HKLM Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem\Contexts Value=1/ RegistryValue Id=ctd_activesetup_regfix_1 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Value=[ProductName] / RegistryValue Id=ctd_activesetup_regfix_2 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\StubPath Value=msiexec /fou [ProductCode] /qb/ RegistryValue Id=ctd_activesetup_regfix_3 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\Version Value=1,0,0/ HKCU items are in separate components so that they can have the KeyPath attribute set. !--Must be installed in HKCU for installing user to immediately use. All other users will have the plugin silently repaired using Active Setup-- Component Id=ctd_ieplugin_hkcu_menuext Guid=DB65E89E-C207-43BC-B4E9-E75D20A870AF SharedDllRefCount=yes RegistryValue Id=ctd_classinfo_183 Action=write Type=string Root=HKCU KeyPath=yes Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem Value=[#ctxmenu.htm]/ !--These two entries keep the install from re-running or repairing itself when the installing user logs back in.-- RegistryValue Id=ctd_activesetup_HKCU_COPY_1 Action=write Type=string Root=HKCU Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Value=[ProductName] / RegistryValue Id=ctd_activesetup_HKCU_COPY_2 Action=write Type=string Root=HKCU Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\Version Value=1,0,0/ /Component Component Id=ctd_ieplugin_hkcu_menuext_context Guid=327241A1-ECFF-454D-A8EC-34E0BF616904 SharedDllRefCount=yes RegistryValue Id=ctd_classinfo_184 Action=write Type=string Root=HKCU KeyPath=yes Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem\Contexts Value=1/ /Component The OS I am running this on is Windows 7 64 Bit. The installing user is also in the local admin group but the others users are not. Jon -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Thursday, January 12, 2012 7:12 PM To: Dan Gough; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Then there's the case of Office AddIns that allowed either HKCU or HKLM in 2003, took away in 2007 ( and put it back with a hotfix and enabling registry value ) and really put it back in 2010 leaving one hell of a mess for us installer guys to deal with. So, yes, YMMV... in the event it really needs to be HKCU like the poster asserted then my response below will help. From: Dan Gough goug...@gmail.com Sent: Thursday, January 12, 2012 5:21 PM To: chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Or try applying the key to HKLM rather than HKCU in the first place. Many Windows settings can apply to either key to give you the flexibility of having each setting system-wide or per-user. On Thu, Jan 12, 2012 at 9:34 PM, Christopher Painter chr...@iswix.com wrote: The Registry element has a Root attribute that you can set to HKCU. If your program has an advertised shortcut you can use this to trigger resilency to complete the installation for each user who uses your app. It's an ugly story though like the old Office install that popped up every time you went to a new conference room and logged in. http://wix.sourceforge.net/manual-wix3/wix_xsd_registry.htm Here's an alternative approach that avoids all that: http://blogs.flexerasoftware.com/installtalk/2011/11/using-active-setup-to-r epair-user-settings.html From: McCain, Jon jon.mcc...@inin.com Sent: Thursday, January 12, 2012 3:28 PM To: General discussion for Windows Installer XML toolset. (wix-users@lists.sourceforge.net) wix-users@lists.sourceforge.net Subject: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install I have been working on a new install where a context menu is added to the
[WiX-users] MergeModules being removed on upgrade
My WiX installer removes the VC10 redistributable merge modules on upgrade. It unpublishes the MMs but does not reinstall them (and yes, my RemoveExistingProducts action occurs AFTER InstallInitialize). I'm hoping someone on this list can assist me in figuring out the issue. Here is my WiX script and here is a link to a verbose MSI log (https://gist.github.com/1607604). Thanks! ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:netfx=http://schemas.microsoft.com/wix/NetFxExtension; Product Name=$(var.LongName) Id=* UpgradeCode=$(var.UpgradeGuid) Language=1033 Codepage=1252 Version=$(var.Version) Manufacturer=$(var.EmcLong) Package Id=* Keywords=Installer Description=$(var.ProjectDescription) Comments=$(var.ProjectDescription) Manufacturer=$(var.EmcLong) InstallerVersion=300 Languages=1033 Compressed=yes SummaryCodepage=1252 / !-- UPGRADES -- Upgrade Id=$(var.UpgradeGuid) UpgradeVersion Minimum=3.9.9 IncludeMinimum=yes Maximum=$(var.Version) IncludeMaximum=yes Property=OLDERVERSIONBEINGUPGRADED / UpgradeVersion Minimum=$(var.Version) IncludeMinimum=no OnlyDetect=yes Property=NEWERVERSIONDETECTED / /Upgrade !-- This is a very IMPORTANT section. Because I, akutz, farked up and did not put each file into an individual component, same version upgrades, which also allow downgrades, do not work correctly. This is because each component is not tied to a single file entry, and thus the file versions/dates do not get compared correctly - the file versioning rules (http://bit.ly/hIpqg2). To remedy the situation I am using a custom action, ExitEarlyWithSuccess, to exit the installer early if a key file has a verion that is greater than the version to be installed. This means a later version of the MSI is already installed. Also, there is a custom action defined as part of the InstallExecuteSequence that will invoke the ExitEarlyWithSuccess acution if this product is not installed and there is a new file version detected. -- !-- CUSTOM ACTIONS -- CustomActionRef Id=WixExitEarlyWithSuccess/ CustomAction Id=ExitEarlyWithSuccess VBScriptCall=Main Property=ExitEarlyWithSuccessScript / CustomAction Id=CopyMsiToInstallDir Script=vbscript ![CDATA[ msiFile = Session.Property(OriginalDatabase) installDir = Session.Property(LACFEATUREDIR) Set fso = CreateObject(Scripting.FileSystemObject) fso.CopyFile msiFile, installDir ]] /CustomAction !-- INSTALL SEQUENCES -- InstallExecuteSequence Custom Action=ExitEarlyWithSuccess After=InstallInitializeNOT Installed AND NEWERFILEVERSIONDETECTED/Custom RemoveExistingProducts After=InstallInitialize / Custom Action=CopyMsiToInstallDir After=InstallFinalizeNot Installed/Custom /InstallExecuteSequence !-- MEDIA -- Media Id=1 Cabinet=media.cab CompressionLevel=none EmbedCab=yes / !-- PROPERTIES -- Property Id=LACFEATUREDIR RegistrySearch Id=EmcVsiVSphere4LacDir Root=HKLM Key=SOFTWARE\$(var.EmcShort)\$(var.VsiLong)\vSphere4 Type=directory Name=LacPath / /Property Property Id=ARPSYSTEMCOMPONENT Value=1 / Property Id=ALLUSERS Value=1 / Property Id=ExitEarlyWithSuccessScript ![CDATA[ Function Main() Main = 5 End Function ]] /Property Property Id=NEWERFILEVERSIONDETECTED DirectorySearch Id=NewerFileVersionDirSearch Path=[LACFEATUREDIR] FileSearch Name=EMC.VSI.VSphere4.Features.SPO.Common.dll MinVersion=$(var.Version4)/ /DirectorySearch /Property !-- INSTALL CONDITIONS -- Condition Message=$(var.VsiForVSphereRequiredConditionMessage) Installed OR LACFEATUREDIR /Condition !-- DIRECTORY STRUCTURE -- Directory Id=TARGETDIR Name=SourceDir Directory Id=LACFEATUREDIR / /Directory !-- APPLICATION FILES -- DirectoryRef Id=LACFEATUREDIR Component Id=ApplicationFiles Guid=4A95A3AF-C64E-4011-80AE-CF9B659AEA93 File Source=$(var.BuildOutput)\EMC.VSI.VSphere4.Features.SPO.Common.dll / File Source=$(var.PowerPathWrapperPath)\PowerPathWrapper.dll / File Source=$(var.SEWrapperPath)\SEWrapper.dll / ?ifdef $(var.DEBUG) ? File Source=$(var.BuildOutput)\EMC.VSI.VSphere4.Features.SPO.Common.pdb / File Source=$(var.PowerPathWrapperPath)\PowerPathWrapper.pdb /
Re: [WiX-users] Writing JDK version verification code, and Wix debugging tip
On 1/13/12 7:28 AM, Peter Shirtcliffe wrote: Why not check it when the application starts up ? The product in question runs as a service. There is no GUI. The Java wrapper could only log the error and quit. For that reason, the product marketing tells us we should check the prerequisite software (i.e. JDK) is installed at our product installation time. I'm just a lone software engineer :-) Kuro -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install
Log in won't cause replication of the keys. An earlier post mentioned that you need an advertised shortcut. Phil W -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: Friday, January 13, 2012 8:06 AM To: chr...@iswix.com; General discussion for Windows Installer XML toolset.; Dan Gough Cc: McCain, Jon Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install I have tried using the Active Setup keys but when the other user logs in the replication isn't occurring nor is the repair type install. Here is what my setup looks like: !--Installed at HKLM so that Active Setup keys can be imployed-- RegistryValue Id=ctd_classinfo_185 Action=write Type=string Root=HKLM Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem Value=[#ctxmenu.htm]/ RegistryValue Id=ctd_classinfo_186 Action=write Type=string Root=HKLM Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem\Contexts Value=1/ RegistryValue Id=ctd_activesetup_regfix_1 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Value=[ProductName] / RegistryValue Id=ctd_activesetup_regfix_2 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\StubPath Value=msiexec /fou [ProductCode] /qb/ RegistryValue Id=ctd_activesetup_regfix_3 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\Version Value=1,0,0/ HKCU items are in separate components so that they can have the KeyPath attribute set. !--Must be installed in HKCU for installing user to immediately use. All other users will have the plugin silently repaired using Active Setup-- Component Id=ctd_ieplugin_hkcu_menuext Guid=DB65E89E-C207-43BC-B4E9-E75D20A870AF SharedDllRefCount=yes RegistryValue Id=ctd_classinfo_183 Action=write Type=string Root=HKCU KeyPath=yes Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem Value=[#ctxmenu.htm]/ !--These two entries keep the install from re-running or repairing itself when the installing user logs back in.-- RegistryValue Id=ctd_activesetup_HKCU_COPY_1 Action=write Type=string Root=HKCU Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Value=[ProductName] / RegistryValue Id=ctd_activesetup_HKCU_COPY_2 Action=write Type=string Root=HKCU Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\Version Value=1,0,0/ /Component Component Id=ctd_ieplugin_hkcu_menuext_context Guid=327241A1-ECFF-454D-A8EC-34E0BF616904 SharedDllRefCount=yes RegistryValue Id=ctd_classinfo_184 Action=write Type=string Root=HKCU KeyPath=yes Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem\Contexts Value=1/ /Component The OS I am running this on is Windows 7 64 Bit. The installing user is also in the local admin group but the others users are not. Jon -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Thursday, January 12, 2012 7:12 PM To: Dan Gough; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Then there's the case of Office AddIns that allowed either HKCU or HKLM in 2003, took away in 2007 ( and put it back with a hotfix and enabling registry value ) and really put it back in 2010 leaving one hell of a mess for us installer guys to deal with. So, yes, YMMV... in the event it really needs to be HKCU like the poster asserted then my response below will help. From: Dan Gough goug...@gmail.com Sent: Thursday, January 12, 2012 5:21 PM To: chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Or try applying the key to HKLM rather than HKCU in the first place. Many Windows settings can apply to either key to give you the flexibility of having each setting system-wide or per-user. On Thu, Jan 12, 2012 at 9:34 PM, Christopher Painter chr...@iswix.com wrote: The Registry element has a Root attribute that you can set to HKCU. If your program has an advertised shortcut you can use this to trigger resilency to complete the installation for each user who uses your app. It's an ugly story though like the old Office install that popped up every time you went to a new conference room and logged in. http://wix.sourceforge.net/manual-wix3/wix_xsd_registry.htm Here's an alternative approach that avoids all that: http://blogs.flexerasoftware.com/installtalk/2011/11/using-active-setup-to-r
Re: [WiX-users] Burn bootstrapper administrator mode log file bug
Definitely bug. Not sure that is known so please open. smile/ On Thu, Jan 12, 2012 at 9:18 PM, Naim Kingston naim.kings...@ancamotion.com wrote: I'm getting a strange bug where if I run a bootstrapper created with burn from an administrator command line prompt AND specify a log file, then the bootstrapper will hang before even opening up the UI. It's strange, running without a log file works fine from the administrator command line prompt, but attempting to use a log file causes it to hang and not return (for at least a couple of minutes). The bootstrapper in question is just to get used to burn and only installs 2 installers of 32kb each (a single, practically empty text file per installer). So, I'm assuming that's a bug of some sort? Is it already known? -Naim -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install
l've used the Active Setup technique and replication occurred right away when the user logged on. Make sure you are using a clean machine such as a snapshotted VM to ensure a good testing environment. It could be that replication already occurred and isn't occuring again because the Version value isn't changing/increasing. From: Wilson, Phil phil.wil...@invensys.com Sent: Friday, January 13, 2012 2:30 PM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net, chr...@iswix.com chr...@iswix.com, Dan Gough goug...@gmail.com Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Log in won't cause replication of the keys. An earlier post mentioned that you need an advertised shortcut. Phil W -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: Friday, January 13, 2012 8:06 AM To: chr...@iswix.com; General discussion for Windows Installer XML toolset.; Dan Gough Cc: McCain, Jon Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install I have tried using the Active Setup keys but when the other user logs in the replication isn't occurring nor is the repair type install. Here is what my setup looks like: !--Installed at HKLM so that Active Setup keys can be imployed-- RegistryValue Id=ctd_classinfo_185 Action=write Type=string Root=HKLM Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem Value=[#ctxmenu.htm]/ RegistryValue Id=ctd_classinfo_186 Action=write Type=string Root=HKLM Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem\Contexts Value=1/ RegistryValue Id=ctd_activesetup_regfix_1 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Value=[ProductName] / RegistryValue Id=ctd_activesetup_regfix_2 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\StubPath Value=msiexec /fou [ProductCode] /qb/ RegistryValue Id=ctd_activesetup_regfix_3 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\Version Value=1,0,0/ HKCU items are in separate components so that they can have the KeyPath attribute set. !--Must be installed in HKCU for installing user to immediately use. All other users will have the plugin silently repaired using Active Setup-- Component Id=ctd_ieplugin_hkcu_menuext Guid=DB65E89E-C207-43BC-B4E9-E75D20A870AF SharedDllRefCount=yes RegistryValue Id=ctd_classinfo_183 Action=write Type=string Root=HKCU KeyPath=yes Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem Value=[#ctxmenu.htm]/ !--These two entries keep the install from re-running or repairing itself when the installing user logs back in.-- RegistryValue Id=ctd_activesetup_HKCU_COPY_1 Action=write Type=string Root=HKCU Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Value=[ProductName] / RegistryValue Id=ctd_activesetup_HKCU_COPY_2 Action=write Type=string Root=HKCU Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\Version Value=1,0,0/ /Component Component Id=ctd_ieplugin_hkcu_menuext_context Guid=327241A1-ECFF-454D-A8EC-34E0BF616904 SharedDllRefCount=yes RegistryValue Id=ctd_classinfo_184 Action=write Type=string Root=HKCU KeyPath=yes Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem\Contexts Value=1/ /Component The OS I am running this on is Windows 7 64 Bit. The installing user is also in the local admin group but the others users are not. Jon -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Thursday, January 12, 2012 7:12 PM To: Dan Gough; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Then there's the case of Office AddIns that allowed either HKCU or HKLM in 2003, took away in 2007 ( and put it back with a hotfix and enabling registry value ) and really put it back in 2010 leaving one hell of a mess for us installer guys to deal with. So, yes, YMMV... in the event it really needs to be HKCU like the poster asserted then my response below will help. From: Dan Gough goug...@gmail.com Sent: Thursday, January 12, 2012 5:21 PM To: chr...@iswix.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Or try applying the key to HKLM rather than HKCU in the first place. Many Windows settings can apply to either key to give you the flexibility of having each setting system-wide or per-user. On
Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install
Actually I just realized I've been saying it all. I've been implying that the repair approach and the active setup approach are mutually exclusive. In fact the active setup is just a way to trigger the repair through a command line when an advertised shortcut is unavailable. I'm sorry if I was unclear or if I was clear and now I'm just confusing myself. :-) From: Christopher Painter chr...@iswix.com Sent: Friday, January 13, 2012 2:33 PM To: Wilson, Phil phil.wil...@invensys.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net, Dan Gough goug...@gmail.com Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install l've used the Active Setup technique and replication occurred right away when the user logged on. Make sure you are using a clean machine such as a snapshotted VM to ensure a good testing environment. It could be that replication already occurred and isn't occuring again because the Version value isn't changing/increasing. From: Wilson, Phil phil.wil...@invensys.com Sent: Friday, January 13, 2012 2:30 PM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net, chr...@iswix.com chr...@iswix.com, Dan Gough goug...@gmail.com Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Log in won't cause replication of the keys. An earlier post mentioned that you need an advertised shortcut. Phil W -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: Friday, January 13, 2012 8:06 AM To: chr...@iswix.com; General discussion for Windows Installer XML toolset.; Dan Gough Cc: McCain, Jon Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install I have tried using the Active Setup keys but when the other user logs in the replication isn't occurring nor is the repair type install. Here is what my setup looks like: !--Installed at HKLM so that Active Setup keys can be imployed-- RegistryValue Id=ctd_classinfo_185 Action=write Type=string Root=HKLM Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem Value=[#ctxmenu.htm]/ RegistryValue Id=ctd_classinfo_186 Action=write Type=string Root=HKLM Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem\Contexts Value=1/ RegistryValue Id=ctd_activesetup_regfix_1 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Value=[ProductName] / RegistryValue Id=ctd_activesetup_regfix_2 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\StubPath Value=msiexec /fou [ProductCode] /qb/ RegistryValue Id=ctd_activesetup_regfix_3 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\Version Value=1,0,0/ HKCU items are in separate components so that they can have the KeyPath attribute set. !--Must be installed in HKCU for installing user to immediately use. All other users will have the plugin silently repaired using Active Setup-- Component Id=ctd_ieplugin_hkcu_menuext Guid=DB65E89E-C207-43BC-B4E9-E75D20A870AF SharedDllRefCount=yes RegistryValue Id=ctd_classinfo_183 Action=write Type=string Root=HKCU KeyPath=yes Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem Value=[#ctxmenu.htm]/ !--These two entries keep the install from re-running or repairing itself when the installing user logs back in.-- RegistryValue Id=ctd_activesetup_HKCU_COPY_1 Action=write Type=string Root=HKCU Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Value=[ProductName] / RegistryValue Id=ctd_activesetup_HKCU_COPY_2 Action=write Type=string Root=HKCU Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\Version Value=1,0,0/ /Component Component Id=ctd_ieplugin_hkcu_menuext_context Guid=327241A1-ECFF-454D-A8EC-34E0BF616904 SharedDllRefCount=yes RegistryValue Id=ctd_classinfo_184 Action=write Type=string Root=HKCU KeyPath=yes Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem\Contexts Value=1/ /Component The OS I am running this on is Windows 7 64 Bit. The installing user is also in the local admin group but the others users are not. Jon -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Thursday, January 12, 2012 7:12 PM To: Dan Gough; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Then there's the case of Office AddIns that allowed either HKCU or HKLM in 2003, took away in 2007 ( and put it back with a hotfix and enabling registry
Re: [WiX-users] Copy Files from Bundle to Disk
You'd have to have an MSI that installs the MSI. On Thu, Jan 12, 2012 at 1:19 PM, Jammer jam...@jammer.biz wrote: Hey All, Is it possible to copy an .msi or .exe from within the bundle to the install location? I have a product included in my installer that I'd like to copy to the install location in case the user wishes to run that installer manually later. TIA, -- *Jammer* http://www.jammer.biz** -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn EXEPackage Condition does not get evaluated when MSIPackage Installation is cancelled
1. The InstallConditions are evaluated before any packages are executed. Look in the bundle log file and you should be able to see the plan that spells out what is going to be done to each package. 2. The Condition attribute on the Bundle element determines whether the Bundle can be launched at all. It can basically only use built in variables (i.e no searches are executed). What you want, for the bootstrapper application to run a condition. That is supported by the wixstdba that you are using by using the bal:Condition element. A little confusing until you understand the layering of the tools. On Fri, Jan 13, 2012 at 2:56 AM, Prem Kumar Ponuthorai prem.kumar.ponutho...@exact.com wrote: Hi All, I have been having problems with the Burn bootstrapper when the MSIPackage is installed with the DisplayInternalUI=yes. We need this as a requirement. The problem I face is that When we click on Cancel for the MSI installation, the whole prerequisite is going into a reinstall or repair mode bypassing the InstallCondition of each EXEPackage that is defined. Is this a bug or am I doing it wrong? Also how can I block from the bundle from being installed when the MSI is already installed? I have tried the Condition element in the bundle but it seems to bypass that too. Below is my codes: BUNDLE.WXS: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util= http://schemas.microsoft.com/wix/UtilExtension; Bundle Version=6.0.0.16 Condition=NOT WixSOIInstalled IconSourceFile=..\SourceFiles\setup.ico UpgradeCode=7CD9A5CB-A250-426A-939A-49751499C42E BootstrapperApplicationRef Id=WixStandardBootstrapperApplication.RtfLicense / WixVariable Id=WixStdbaLicenseRtf Value=..\SourceFiles\License.rtf / WixVariable Id=WixStdbaLogo Value=..\SourceFiles\logo_next.png / WixVariable Id=WixStdbaThemeXml Value=..\SourceFiles\ExactRtfTheme.xml/ util:ProductSearch Guid =183B99EC-EF7E-46ac-ACA0-28D06BEE1604 Id =SOIInstalledSearch Variable =WixSOIInstalled / Chain PackageGroupRef Id=NetFX40 / PackageGroupRef Id=VSTO40x86 / PackageGroupRef Id=VSTO40x64 / MsiPackage Name=Office Integration Compressed=yes Vital=yes SourceFile=..\SourceFiles\OfficeIntegration.msi DisplayInternalUI=yes InstallCondition=NOT WixSOIInstalled /MsiPackage /Chain /Bundle /Wix NETFX.WXS: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util= http://schemas.microsoft.com/wix/UtilExtension; Fragment util:RegistrySearch Root=HKLM Key=SOFTWARE\Microsoft\Net Framework Setup\NDP\v4\Full Value=Install Variable=NetFX40Install / util:RegistrySearch Root=HKLM Key=SOFTWARE\Wow6432Node\Microsoft\Net Framework Setup\NDP\v4\Full Value=Install Variable=NetFX40x64Install/ PackageGroup Id=NetFX40 ExePackage Id=dotNetFx40_Full_x86_x64.exe Vital=yes SourceFile=..\SourceFiles\dotNetFx40_Full_setup.exe DownloadUrl= http://www.microsoft.com/download/en/details.aspx?id=17851; InstallCommand=/q /norestart /log %TEMP%\dotNetFx40install.log DetectCondition=(NetFX40Install = 1) OR (NetFX40x64Install = 1) InstallCondition=NOT NetFX40Install OR (VersionNT64 AND NOT NetFX40x64Install) PerMachine =yes Permanent =yes Name =.NET Framework 4.0 full runtime / /PackageGroup /Fragment /Wix VSTO.WXS: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util= http://schemas.microsoft.com/wix/UtilExtension; Fragment util:RegistrySearch Root=HKLM Key=Software\Microsoft\vsto runtime setup\v4R Value=VSTORFeature_CLR40 Variable=VSTO40x86Install / PackageGroup Id=VSTO40x86 ExePackage Id=vstor40_x86.exe Vital=yes SourceFile=..\SourceFiles\vstor40_x86.exe DownloadUrl= http://www.microsoft.com/download/en/details.aspx?id=20479; InstallCommand=/q DetectCondition=VSTO40x86Install = 1 InstallCondition=NOT VersionNT64 AND NOT VSTO40x86Install PerMachine =yes Permanent =yes Name =Visual Studio 2010 for Office Runtime (x86) / /PackageGroup /Fragment /Wix -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2
Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068
Burn is a little different because it is designed to recover from power failures and unexpected reboots. To do that it writes to the RunOnce registry key up front. Other bootstrappers/chainers may not write to RunOnce except when a force reboot is required in the middle of the chain. Then the bootstrapper/chainer must write to RunOnce in order to complete the installation. If something (anti-virus in this case) kills processes writing to RunOnce then those other chainers could end up in a bad state if they didn't save their data before getting killed. Burn won't have that problem since it tries to register with RunOnce before modifying machine state. So, basically, Burn exposes the configuration problem that could leave other chainers in a bad state. Or maybe they would just work okay but you'd have to go figure out why they didn't resume after reboot. On Fri, Jan 13, 2012 at 4:36 AM, Nikolaj Steensgaard n...@panorama9.comwrote: On Fri, Jan 13, 2012 at 7:48 AM, Peter Hull peterhul...@hotmail.com wrote: Date: Thu, 12 Jan 2012 20:56:15 +0100 From: n...@panorama9.com I would start by digitally signing your burn bundle. The bundle is already signed with a Thawte code signing certificate The reported file name looks more like it's the extracted engine than your bundle itself. Have you signed the engine. I only think we have signed the bundle, so we are working on signing the engine and retesting to see if it makes a difference. Either should Trend Micro change there detection mechanism regarding the RunOnce key or the bundling framework of burn should change its default behavior . From the Trend docs I saw it seemed to suggest that 'Malware Behaviour Monitoring' could be turned off (indeed, terminating programs like this was not the default) and also that signed executables were exempt. So it maybe is a bug in Trend that means it doesn't work as documented? Maybe, but as this is the default setting for a Trend Micro installation it is quite a problem. The other thing is that other installers (InstallShield) don't seem to do this so does anyone understand how InstallShield handles the reboot issue? Don't know , but it could be that they don't look in the RunOnce key as default behavior in their engine and thereby don't have this issue ? Pete -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Best Regards Nikolaj Steensgaard Panorama9 A/S Langebrogade 5 1411 Copenhagen K Phone: +45 7020 3565 Mobile: +45 2124 3040 n...@panorama9.com Panorama9 is an IT management platform that shows you everything you need to know about your assets, IT availability, security vulnerabilities, and non-compliant systems – from a single Dashboard that’s amazingly easy to monitor and interpret. Your organization can cut IT costs through improved uptime and as a cloud-based solution, there is no infrastructure to deploy or manage. For more information - www.panorama9.com -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install
There are other triggers in the MSI that can cause install on demand from the MSI, advertised COM being one, and I think file extensions do it too, but I don't know if that's an option for this particular issue. Of course Active Setup can do it, yes, maybe that's a solution, getting Windows to run a command line often is ;) Phil From: Christopher Painter [mailto:chr...@iswix.com] Sent: Friday, January 13, 2012 12:40 PM To: Wilson, Phil; General discussion for Windows Installer XML toolset.; Dan Gough Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Actually I just realized I've been saying it all. I've been implying that the repair approach and the active setup approach are mutually exclusive. In fact the active setup is just a way to trigger the repair through a command line when an advertised shortcut is unavailable. I'm sorry if I was unclear or if I was clear and now I'm just confusing myself. :-) From: Christopher Painter chr...@iswix.com Sent: Friday, January 13, 2012 2:33 PM To: Wilson, Phil phil.wil...@invensys.com, General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net, Dan Gough goug...@gmail.com Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install l've used the Active Setup technique and replication occurred right away when the user logged on. Make sure you are using a clean machine such as a snapshotted VM to ensure a good testing environment. It could be that replication already occurred and isn't occuring again because the Version value isn't changing/increasing. From: Wilson, Phil phil.wil...@invensys.com Sent: Friday, January 13, 2012 2:30 PM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net, chr...@iswix.com chr...@iswix.com, Dan Gough goug...@gmail.com Subject: RE: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install Log in won't cause replication of the keys. An earlier post mentioned that you need an advertised shortcut. Phil W -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: Friday, January 13, 2012 8:06 AM To: chr...@iswix.com; General discussion for Windows Installer XML toolset.; Dan Gough Cc: McCain, Jon Subject: Re: [WiX-users] Adding Internet Explorer Context Menu item for all users in a per machine install I have tried using the Active Setup keys but when the other user logs in the replication isn't occurring nor is the repair type install. Here is what my setup looks like: !--Installed at HKLM so that Active Setup keys can be imployed-- RegistryValue Id=ctd_classinfo_185 Action=write Type=string Root=HKLM Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem Value=[#ctxmenu.htm]/ RegistryValue Id=ctd_classinfo_186 Action=write Type=string Root=HKLM Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem\Contexts Value=1/ RegistryValue Id=ctd_activesetup_regfix_1 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Value=[ProductName] / RegistryValue Id=ctd_activesetup_regfix_2 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\StubPath Value=msiexec /fou [ProductCode] /qb/ RegistryValue Id=ctd_activesetup_regfix_3 Action=write Type=string Root=HKLM Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\Version Value=1,0,0/ HKCU items are in separate components so that they can have the KeyPath attribute set. !--Must be installed in HKCU for installing user to immediately use. All other users will have the plugin silently repaired using Active Setup-- Component Id=ctd_ieplugin_hkcu_menuext Guid=DB65E89E-C207-43BC-B4E9-E75D20A870AF SharedDllRefCount=yes RegistryValue Id=ctd_classinfo_183 Action=write Type=string Root=HKCU KeyPath=yes Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem Value=[#ctxmenu.htm]/ !--These two entries keep the install from re-running or repairing itself when the installing user logs back in.-- RegistryValue Id=ctd_activesetup_HKCU_COPY_1 Action=write Type=string Root=HKCU Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode] Value=[ProductName] / RegistryValue Id=ctd_activesetup_HKCU_COPY_2 Action=write Type=string Root=HKCU Key=Software\Microsoft\Active Setup\Installed Components\[ProductCode]\Version Value=1,0,0/ /Component Component Id=ctd_ieplugin_hkcu_menuext_context Guid=327241A1-ECFF-454D-A8EC-34E0BF616904 SharedDllRefCount=yes RegistryValue Id=ctd_classinfo_184 Action=write Type=string Root=HKCU KeyPath=yes Key=Software\Microsoft\Internet Explorer\MenuExt\Report Click-To-Dial Problem\Contexts Value=1/ /Component The OS I am running this on is Windows 7
Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068
And the MSDN docs *recommend* RunOnce as a way to finish application setups. It does seem unfair for an AV product to decide to prevent completion of application setup. InstallShield uses the RunOnce key too, judging from search hits and their content. Phil W -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Friday, January 13, 2012 12:48 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Reopen Burn triggers virus checker - ID: 3431068 Burn is a little different because it is designed to recover from power failures and unexpected reboots. To do that it writes to the RunOnce registry key up front. Other bootstrappers/chainers may not write to RunOnce except when a force reboot is required in the middle of the chain. Then the bootstrapper/chainer must write to RunOnce in order to complete the installation. If something (anti-virus in this case) kills processes writing to RunOnce then those other chainers could end up in a bad state if they didn't save their data before getting killed. Burn won't have that problem since it tries to register with RunOnce before modifying machine state. So, basically, Burn exposes the configuration problem that could leave other chainers in a bad state. Or maybe they would just work okay but you'd have to go figure out why they didn't resume after reboot. On Fri, Jan 13, 2012 at 4:36 AM, Nikolaj Steensgaard n...@panorama9.comwrote: On Fri, Jan 13, 2012 at 7:48 AM, Peter Hull peterhul...@hotmail.com wrote: Date: Thu, 12 Jan 2012 20:56:15 +0100 From: n...@panorama9.com I would start by digitally signing your burn bundle. The bundle is already signed with a Thawte code signing certificate The reported file name looks more like it's the extracted engine than your bundle itself. Have you signed the engine. I only think we have signed the bundle, so we are working on signing the engine and retesting to see if it makes a difference. Either should Trend Micro change there detection mechanism regarding the RunOnce key or the bundling framework of burn should change its default behavior . From the Trend docs I saw it seemed to suggest that 'Malware Behaviour Monitoring' could be turned off (indeed, terminating programs like this was not the default) and also that signed executables were exempt. So it maybe is a bug in Trend that means it doesn't work as documented? Maybe, but as this is the default setting for a Trend Micro installation it is quite a problem. The other thing is that other installers (InstallShield) don't seem to do this so does anyone understand how InstallShield handles the reboot issue? Don't know , but it could be that they don't look in the RunOnce key as default behavior in their engine and thereby don't have this issue ? Pete -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Best Regards Nikolaj Steensgaard Panorama9 A/S Langebrogade 5 1411 Copenhagen K Phone: +45 7020 3565 Mobile: +45 2124 3040 n...@panorama9.com Panorama9 is an IT management platform that shows you everything you need to know about your assets, IT availability, security vulnerabilities, and non-compliant systems – from a single Dashboard that’s amazingly easy to monitor and interpret. Your organization can cut IT costs through improved uptime and as a cloud-based solution, there is no infrastructure to deploy or manage. For more information - www.panorama9.com -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your
Re: [WiX-users] Patching
Thanks again Peter. I think I will read the MS whitepaper on patching because it is clear that our current strategy does not fit with the MSI model of updates. We may take the opportunity to change our model as you suggest. Regards snajay -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 12 January 2012 10:20 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patching 1. There are a couple of ways that might work for you. It depends if you have to stick with your current upgrade strategy or if you have an opportunity to alter it. Firstly, most people find that producing major upgrade MSIs is by far the easiest way to support upgrades. You cant apply these out of order though. This blog post describes your scenario http://blogs.msdn.com/b/heaths/archive/2006/06/14/cumulative-service- packs-wi th-minorupdatetargetrtm.aspx This also won't allow you to apply patches out of order. You can apply a later patch first but, being cumulative, the earlier patch is included. It does however simplify the problem of supporting a product with many possible combinations of patches involved. You could also create patches that target multiple versions of the MSI. That fits your requirement better but problem with those is that, if you produce many patches that can be applied in any order, the number of possible installed products that need to be targeted increases rapidly. This increases patch size and testing complexity. If the patches are independent and don't change the product version, that may not be a problem. I believe you could also create small updates that do not alter the product version and could be combined freely. As long as all your files are versioned and backwards compatible, then you could mix these freely and the MSI versioning rules would always ensure the highest is installed. The number of possible combinations you allow could grow quickly and will be inherently tricky to support. Finding the best solution is really only something you can decide, knowing what your constraints are. Whatever you decide on, you should definitely make some test patches. I also strongly recommend reading the MS whitepaper. Its long and dry but explains many ways in which you can use patching and has some example scenarios too. 3. I think heat automatically generates components in fragments unless you use the -sfrag switch. Torch works with all kinds of files. Windows Installer works best if your executable files have a version resource that specifies the file version but it'll will handle unversioned binaries too. -Original Message- From: Sanjay Poria [mailto:sanjay.po...@xanalys.com] Sent: 11 January 2012 23:09 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Patching Thanks for the information Peter. Some follow up: 1) In previous versions of our app, we distributed patches to the customer as a set of files in a zip that the customer simply unzips into the application directory. While this isn't ideal (because of the problems associated with uninstalling patches etc.) it is very flexible in that we can distribute any number of patches that are not dependant on each other, and the customer can install and test the features in any order. For example, If we deliver patch P1 and P2 to the customer in that order, they may decide to install P2 first because it requires a smaller test effort than P1. I'm not sure how I achieve the same using the MSI patching. Let's say we have 3 wixpdb files: mainprod.wixpdb, patch1.wixpdb, patch2.wixpdb. When release Patch1 we use the transform (mainprod-patch1). Then we release patch2 which is not dependant on patch1 so we use the transforms (mainprod-patch2 and patch1-patch2) to generate it. But that wouldn't work if the customer decided to install patch2 first and then patch1 would it? Might be that i'm missing something obvious here! 3) I think I prefer to segment my components into different fragments and use the wixpdb to generate the mappings as doing admin install is a bit of a pain and potentially more error prone for us. Does anyone know if there is an easy way to do this (eg, if I harvest files using heat for my initial release, can it generate a different fragment for each component?). Another question and potential issue I thought of: Most of the files we distribute are binary (PowerBuilder) files. Will torch be able to generate the transform correctly for these? thanks sanjay -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: 11 January 2012 10:49 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patching I'll try and answer this but it's best to seek some other opinions too. 1. The order of patch installation wont usually matter. When
Re: [WiX-users] Burn EXEPackage Condition does not get evaluated when MSIPackage Installation is cancelled
Thanks Rob, will give it a go and keep informed if I manage to solve it. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-EXEPackage-Condition-does-not-get-evaluated-when-MSIPackage-Installation-is-cancelled-tp7183696p7186616.html Sent from the wix-users mailing list archive at Nabble.com. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] XmlFile element issues - any XPath experts out there?
In your XmlFile elements make sure you set @SelectionLanguage to XPath. The obsolete XSLPattern default value uses a now obsolete predecessor to XPath for the pattern matching. Blair -Original Message- From: Dan Gough [mailto:goug...@gmail.com] Sent: Wednesday, January 11, 2012 7:43 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] XmlFile element issues - any XPath experts out there? Hi, I've successfully set up a few xml file configuration items using the XmlFile element, but I have an instance that is not working as expected, hopefully somebody out there can help! This is a cut down sample of my xml file: ?xml version='1.0'? evidence_gatherer evidence evidence_type type=notification xslt_sqlUPDATEME/xslt_sql /evidence_type evidence_type type=ts_feature xslt_sqlUPDATEME/xslt_sql /evidence_type /evidence /evidence_gatherer And this is my WiX markup: util:XmlFile Id=Notif Action=setValue ElementPath=/evidence_gatherer/evidence/evidence_type[/[]@type='notificatio n'[/]]/xslt_sql File=[#evidence_gatherer.xml] Value=[#notification_sql.xsl]/ util:XmlFile Id=Feat Action=setValue ElementPath=/evidence_gatherer/evidence/evidence_type[/[]@type='ts_feature' [/]]/xslt_sql File=[#evidence_gatherer.xml] Value=[#ts_feature_sql.xsl]/ The result I get is that both statements end up selecting the same first node (where type='notification'), which ends up being left set to the value of the last operation. I believe I am correctly escaping the square brackets above. If I try to refer to them in order, e.g. /evidence_gatherer/evidence/evidence_type[1]/xslt_sql, that does not work either. Have I stumbled upon a bug (I'm using v3.6) or are my XPath statements wrong? Thanks, Dan -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] patches and custom actions
A patch is simply shipping part of an imaginary MSI that would have been installed using the v value as part of the REINSTALLMODE property supplied on the commandline. Thus, your upgraded authoring needs to include the authoring needed to get your custom action to do what it needs to do. That depends on the design of your custom action. Blair -Original Message- From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: Wednesday, January 11, 2012 7:09 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] patches and custom actions Hi everyone, If I create a package with a custom action and an upgrade of same with the same custom action, can I change the properties in the upgraded one in such a way that when the patch creator is run the resulting MSP package not only does the CA run in the patch, but also the relevant change in properties is also reflected in the patch so the CA runs appropriately? For example, the original install installs (amongst other things): LibA.dll LibB.dll and writes information to two files via CA 1.xml 2.xml This requires (due to the way an application works) creating the WXS for this installer in such a way as to create the details for 1.xml and 2.xml via properties. Later, as part of supporting new features in the applications, I want to add another of the support libraries, call it LibC.dll In order for the application now to use it, we need to write again to 1.xml and 2.xml via CA But the CA has to have its properties fed in again (basically the name of LibC.dll) to configure those files successfully. Can this be done automatically as part of the MSP generation? (For what it is worth, this is part of an upgrade to an existing application which includes device detection and management code as part of a hands free transmission application using various cellular modems. The LibX.dll mentioned are our libraries for detecting a given device, configuring it for the specified carrier, etc. They use a standard interface known by the application and abstract away from the vendor specifics.) - * - Alternatively, if I release future installers that do the equivalent (call it a small installer) of what the aforementioned MSP is *supposed* to do (i.e. install an additional file or two, update some configurations with the CA), what will happen when the large upgrade comes along and wants to install the same files as the small installer as well as updates to the main application, will this work? Will it damage the installation of the small installed bits? If so, does that matter? The contents of the small installed bits will likely at most be libraries written in managed code and perhaps their native counterparts for p/invoke or the like purposes, whereas the larger updates will include changes to the two applications that make use of these libraries. Thanks, Keith Douglas Statistics Canada | 170 Tunney's Pasture Driveway, Ottawa ON K1A 0T6 Statistique Canada | 170, promenade Tunney's Pasture, Ottawa ON K1A 0T6 keith.doug...@statcan.gc.ca Telephone | Téléphone 613-951-4405 Facsimile | Télécopieur 613-951-1966 Government of Canada | Gouvernement du Canada -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
