Re: [WiX-users] Just upgraded to v3.6.3303.0 and now can't build... Resolved
Obviously. Please file a bug so the next person benefits. On Mon, Oct 15, 2012 at 8:09 PM, Robert MacFadyen wrote: > Hey all, > > More details... > > The problem seems to be restricted to elements with a > child > . > > Here's some pre 3.6 code that was fine: > > > > GenericAll="yes" /> > > > > > > This generates the following warning: > > The RegistryKey/@Action attribute has been deprecated. In most cases, you > can simply omit @Action. If you need to force Windows Installer to create > an empty key or recursively delete the key, use the ForceCreateOnInstall or > ForceDeleteOnUninstall attributes instead. > > > Believing the "In most cases, you can simply omit @Action." I removed > action: > > > > GenericAll="yes" /> > > > > > > And bang... I get the error "Cannot set column 'SecureObject' with a null > value because this is a required field". > > > Adding ForceCreateOnInstall="yes" resolves the problem. > > > It would be nice if exceptions that occur during parsing/compiling/linking > were trapped and reported better. It took a lot of effort to track down > that > the problem was caused by a simple change to remove a warning (a change > that > was explicitly recommend by the warning message itself). > > > Regards, > > Rob > > > > -Original Message- > From: Robert MacFadyen [mailto:rmacfad...@rmtrack.com] > Sent: October-15-12 10:35 PM > To: 'General discussion for Windows Installer XML toolset.' > Subject: Re: [WiX-users] Just upgraded to v3.6.3303.0 and now can't > build... > > Runing the candle command from a command line window yields additional > exception output. As a side note, any ideas why wouldn't the exception > details be captured as part of the build output when invoked from VS2010 > (sure would have saved me a ton of time)? > > Here's the output: > Exception Type: System.InvalidOperationException > > Stack Trace: >at > Microsoft.Tools.WindowsInstallerXml.ColumnDefinition.ValidateValue(Object > value) >at > Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParsePermissio > nExElement(XmlNode node, String objectId, String componentId, Boolean > win64, > Str ing tableName) >at > Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParseElement(S > ourceLineNumberCollection sourceLineNumbers, XmlElement parentElement, > XmlElemen t element, String& keyPath, String[] contextValues) >at > Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParseElement(S > ourceLineNumberCollection sourceLineNumbers, XmlElement parentElement, > XmlElemen t element, String[] contextValues) >at > Microsoft.Tools.WindowsInstallerXml.CompilerCore.ParseExtensionElement(Sou > rceLineNumberCollection sourceLineNumbers, XmlElement parentElement, > XmlElement element, String[] contextValues) >at > Microsoft.Tools.WindowsInstallerXml.Compiler.ParseRegistryKeyElement(XmlNo > de node, String componentId, Int32 root, String parentKey, Boolean > win64Componen t, String& possibleKeyPath) >at > Microsoft.Tools.WindowsInstallerXml.Compiler.ParseComponentElement(XmlNode > node, ComplexReferenceParentType parentType, String parentId, String > parentLang uage, Int32 diskId, String directoryId, String srcPath) >at > Microsoft.Tools.WindowsInstallerXml.Compiler.ParseDirectoryRefElement(XmlN > ode node) >at > Microsoft.Tools.WindowsInstallerXml.Compiler.ParseFragmentElement(XmlNode > node) >at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseWixElement(XmlNode > node) > >at Microsoft.Tools.WindowsInstallerXml.Compiler.Compile(XmlDocument > source) >at Microsoft.Tools.WindowsInstallerXml.Tools.Candle.Run(String[] args) > > > So... it looks like perhaps the problem is in ParsePemissionExElement. > > Assuming this is complaining about element I'm > left > little better off. I use this in quite a few places and they all follow the > same pattern: > GenericExecute="yes" /> > GenericExecute="yes" /> > GenericExecute="yes" /> > > > > Commenting out every element allows the build to > succeed. > > Adding back a single GenericAll="yes" /> causes the build to fail with the " Cannot set column > 'SecureObject' with a null value because this is a required field" error. > > I have a reference to util (C:\Program Files (x86)\WiX Toolset > v3.6\bin\\WixUtilExtension.dll) and I have included the namespace: > http://schemas.microsoft.com/wix/2006/wi"; > xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"; > > > > Has been dropped from 3.6? > > Any suggestions? > > Regards, > > Rob > > -Original Message- > From: Robert MacFadyen [mailto:rmacfad...@rmtrack.com] > Sent: October-15-12 9:53 PM > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Just upgraded to v3.6.3303.0 and now can't build... > > Hey all, > > > > Just upgraded and tried to rebuild my VS2010 wix project. Cleaned up a few > warnings and now it compiles clean... _except_ for the following error: > > > > candle.exe(0,0): e
Re: [WiX-users] Just upgraded to v3.6.3303.0 and now can't build... Resolved
Hey all, More details... The problem seems to be restricted to elements with a child . Here's some pre 3.6 code that was fine: This generates the following warning: The RegistryKey/@Action attribute has been deprecated. In most cases, you can simply omit @Action. If you need to force Windows Installer to create an empty key or recursively delete the key, use the ForceCreateOnInstall or ForceDeleteOnUninstall attributes instead. Believing the "In most cases, you can simply omit @Action." I removed action: And bang... I get the error "Cannot set column 'SecureObject' with a null value because this is a required field". Adding ForceCreateOnInstall="yes" resolves the problem. It would be nice if exceptions that occur during parsing/compiling/linking were trapped and reported better. It took a lot of effort to track down that the problem was caused by a simple change to remove a warning (a change that was explicitly recommend by the warning message itself). Regards, Rob -Original Message- From: Robert MacFadyen [mailto:rmacfad...@rmtrack.com] Sent: October-15-12 10:35 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Just upgraded to v3.6.3303.0 and now can't build... Runing the candle command from a command line window yields additional exception output. As a side note, any ideas why wouldn't the exception details be captured as part of the build output when invoked from VS2010 (sure would have saved me a ton of time)? Here's the output: Exception Type: System.InvalidOperationException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.ColumnDefinition.ValidateValue(Object value) at Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParsePermissio nExElement(XmlNode node, String objectId, String componentId, Boolean win64, Str ing tableName) at Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParseElement(S ourceLineNumberCollection sourceLineNumbers, XmlElement parentElement, XmlElemen t element, String& keyPath, String[] contextValues) at Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParseElement(S ourceLineNumberCollection sourceLineNumbers, XmlElement parentElement, XmlElemen t element, String[] contextValues) at Microsoft.Tools.WindowsInstallerXml.CompilerCore.ParseExtensionElement(Sou rceLineNumberCollection sourceLineNumbers, XmlElement parentElement, XmlElement element, String[] contextValues) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseRegistryKeyElement(XmlNo de node, String componentId, Int32 root, String parentKey, Boolean win64Componen t, String& possibleKeyPath) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseComponentElement(XmlNode node, ComplexReferenceParentType parentType, String parentId, String parentLang uage, Int32 diskId, String directoryId, String srcPath) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseDirectoryRefElement(XmlN ode node) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseFragmentElement(XmlNode node) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseWixElement(XmlNode node) at Microsoft.Tools.WindowsInstallerXml.Compiler.Compile(XmlDocument source) at Microsoft.Tools.WindowsInstallerXml.Tools.Candle.Run(String[] args) So... it looks like perhaps the problem is in ParsePemissionExElement. Assuming this is complaining about element I'm left little better off. I use this in quite a few places and they all follow the same pattern: Commenting out every element allows the build to succeed. Adding back a single causes the build to fail with the " Cannot set column 'SecureObject' with a null value because this is a required field" error. I have a reference to util (C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixUtilExtension.dll) and I have included the namespace: http://schemas.microsoft.com/wix/2006/wi"; xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"; > Has been dropped from 3.6? Any suggestions? Regards, Rob -Original Message- From: Robert MacFadyen [mailto:rmacfad...@rmtrack.com] Sent: October-15-12 9:53 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Just upgraded to v3.6.3303.0 and now can't build... Hey all, Just upgraded and tried to rebuild my VS2010 wix project. Cleaned up a few warnings and now it compiles clean... _except_ for the following error: candle.exe(0,0): error CNDL0001: Cannot set column 'SecureObject' with a null value because this is a required field. The error output leaves a lot to be desired: 1. What source file is causing this? 2. What table does the column belong too? The full candle command is (some names changed to protect the innocent): candle.exe -sw1008 -sw1009 -v -dConfiguration=Release -dOutDir=bin\Release\ -dPlatform=x86 -d"ProjectDir=C:\..snip..\MyProject\\" -dProjectExt=.wixproj -dProjectFileName=MyProject.wixproj -dProjectName=MyP
Re: [WiX-users] Just upgraded to v3.6.3303.0 and now can't build...
Runing the candle command from a command line window yields additional exception output. As a side note, any ideas why wouldn't the exception details be captured as part of the build output when invoked from VS2010 (sure would have saved me a ton of time)? Here's the output: Exception Type: System.InvalidOperationException Stack Trace: at Microsoft.Tools.WindowsInstallerXml.ColumnDefinition.ValidateValue(Object value) at Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParsePermissio nExElement(XmlNode node, String objectId, String componentId, Boolean win64, Str ing tableName) at Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParseElement(S ourceLineNumberCollection sourceLineNumbers, XmlElement parentElement, XmlElemen t element, String& keyPath, String[] contextValues) at Microsoft.Tools.WindowsInstallerXml.Extensions.UtilCompiler.ParseElement(S ourceLineNumberCollection sourceLineNumbers, XmlElement parentElement, XmlElemen t element, String[] contextValues) at Microsoft.Tools.WindowsInstallerXml.CompilerCore.ParseExtensionElement(Sou rceLineNumberCollection sourceLineNumbers, XmlElement parentElement, XmlElement element, String[] contextValues) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseRegistryKeyElement(XmlNo de node, String componentId, Int32 root, String parentKey, Boolean win64Componen t, String& possibleKeyPath) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseComponentElement(XmlNode node, ComplexReferenceParentType parentType, String parentId, String parentLang uage, Int32 diskId, String directoryId, String srcPath) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseDirectoryRefElement(XmlN ode node) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseFragmentElement(XmlNode node) at Microsoft.Tools.WindowsInstallerXml.Compiler.ParseWixElement(XmlNode node) at Microsoft.Tools.WindowsInstallerXml.Compiler.Compile(XmlDocument source) at Microsoft.Tools.WindowsInstallerXml.Tools.Candle.Run(String[] args) So... it looks like perhaps the problem is in ParsePemissionExElement. Assuming this is complaining about element I'm left little better off. I use this in quite a few places and they all follow the same pattern: Commenting out every element allows the build to succeed. Adding back a single causes the build to fail with the " Cannot set column 'SecureObject' with a null value because this is a required field" error. I have a reference to util (C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixUtilExtension.dll) and I have included the namespace: http://schemas.microsoft.com/wix/2006/wi"; xmlns:util="http://schemas.microsoft.com/wix/UtilExtension"; > Has been dropped from 3.6? Any suggestions? Regards, Rob -Original Message- From: Robert MacFadyen [mailto:rmacfad...@rmtrack.com] Sent: October-15-12 9:53 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Just upgraded to v3.6.3303.0 and now can't build... Hey all, Just upgraded and tried to rebuild my VS2010 wix project. Cleaned up a few warnings and now it compiles clean... _except_ for the following error: candle.exe(0,0): error CNDL0001: Cannot set column 'SecureObject' with a null value because this is a required field. The error output leaves a lot to be desired: 1. What source file is causing this? 2. What table does the column belong too? The full candle command is (some names changed to protect the innocent): candle.exe -sw1008 -sw1009 -v -dConfiguration=Release -dOutDir=bin\Release\ -dPlatform=x86 -d"ProjectDir=C:\..snip..\MyProject\\" -dProjectExt=.wixproj -dProjectFileName=MyProject.wixproj -dProjectName=MyProject -d"ProjectPath=C:\ ..snip..\MyProject.wixproj" -d"TargetDir=C:\ snip..\MyProject\bin\Release\\" -dTargetExt=.msi -dTargetFileName=MyProject.msi -dTargetName=MyProject -d"TargetPath=C:\ snip..\MyProject\bin\Release\MyProject.msi" -out obj\Release\ -arch x86 -ext "C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixNetFxExtension.dll" -ext "C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixUtilExtension.dll" -ext "C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixUIExtension.dll" -ext "C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixIIsExtension.dll" Application.wxs CustomDialogs.wxs ErrorText.wxs Files.wxs MicrosoftAssemblies.wxs MyAssemblies.wxs MyCustomActionDefinitions.wxs MyEventLog.wxs MyRegistry.wxs I've been through every element and removed Secure="yes" but this has not helped. I've reviewed this bug: http://sourceforge.net/p/wix/bugs/2941/ and its original posting (http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/MSI-projects- fail-to-build-after-upgrading-to-v3-6-2914-0-td7559640.html) but my project is not suppressing .wixpdb output (even tried turning it on and then off). Does anyone have any suggestions on what I can do to move past this problem? Any suggestions on how to gather more output from candle to get a clue as to the orig
[WiX-users] Just upgraded to v3.6.3303.0 and now can't build...
Hey all, Just upgraded and tried to rebuild my VS2010 wix project. Cleaned up a few warnings and now it compiles clean... _except_ for the following error: candle.exe(0,0): error CNDL0001: Cannot set column 'SecureObject' with a null value because this is a required field. The error output leaves a lot to be desired: 1. What source file is causing this? 2. What table does the column belong too? The full candle command is (some names changed to protect the innocent): candle.exe -sw1008 -sw1009 -v -dConfiguration=Release -dOutDir=bin\Release\ -dPlatform=x86 -d"ProjectDir=C:\..snip..\MyProject\\" -dProjectExt=.wixproj -dProjectFileName=MyProject.wixproj -dProjectName=MyProject -d"ProjectPath=C:\ ..snip..\MyProject.wixproj" -d"TargetDir=C:\ ...snip..\MyProject\bin\Release\\" -dTargetExt=.msi -dTargetFileName=MyProject.msi -dTargetName=MyProject -d"TargetPath=C:\ ...snip..\MyProject\bin\Release\MyProject.msi" -out obj\Release\ -arch x86 -ext "C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixNetFxExtension.dll" -ext "C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixUtilExtension.dll" -ext "C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixUIExtension.dll" -ext "C:\Program Files (x86)\WiX Toolset v3.6\bin\\WixIIsExtension.dll" Application.wxs CustomDialogs.wxs ErrorText.wxs Files.wxs MicrosoftAssemblies.wxs MyAssemblies.wxs MyCustomActionDefinitions.wxs MyEventLog.wxs MyRegistry.wxs I've been through every element and removed Secure="yes" but this has not helped. I've reviewed this bug: http://sourceforge.net/p/wix/bugs/2941/ and its original posting (http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/MSI-projects- fail-to-build-after-upgrading-to-v3-6-2914-0-td7559640.html) but my project is not suppressing .wixpdb output (even tried turning it on and then off). Does anyone have any suggestions on what I can do to move past this problem? Any suggestions on how to gather more output from candle to get a clue as to the origin of the problem? Thanks! Rob -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Some in burn wixstba similar to msiexec /x ProductCode
Yes, all true. None implemented yet. On Mon, Oct 15, 2012 at 11:05 AM, Wesley Manning wrote: > Very True. I was thinking that there would not be a security issue if you > check the UpgradeCode on the downloaded bundle before installing but > anybody could make a bundle with my upgrade code. :) Maybe you could > support it only in cases were the bundle is signed? You could check that > the signature from both bundles come from the same company once downloaded. > Is this reasonable? And/or add a URL attribute for wixstba in the wix > project that gets compiled and that only allow checks for updates from this > URL or based off this URL??? > > Anyways I was trying to take the easy route but looks like going to have > to implement my own BA. :) > > Thanks. > > Wes > > -Original Message- > From: Rob Mensching [mailto:r...@robmensching.com] > Sent: October-15-12 2:17 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /x > ProductCode > > Having the update URL come from outside the Bundle would be a very large > security gap. Essentially, any Bundle could be used to launch any other > random Bundle. That's not right. There is certainly work that could be > done in the wixstdba to support "bundle self-update" but I don't think > passing the update URL via the command-line is the right way to do that. > > > On Sun, Oct 14, 2012 at 5:56 PM, Wesley Manning > wrote: > > > Sorry, for (1) I meant I don't want to do it from a custom BA. I want > > to do it by calling the bundle from the application software that my > > bundle installs. I know for wixstba you provide /uninstall and /repair > commands. > > I use wixstba for my bundle so it would be nice if there was an > "/upgrade" > > command line option in wixstba where I pass the URL of the update and > > the bundle downloads and installs it. Is this something that you guys > > can do for version 3.7? > > > > Thanks for the info on UninstallKey in the registry. I actually > > forgot about that. I see it has a BundleCachePath value so I can use > > that to call my bundle. All I need is for the wixstba to have a > > command line argument to do an upgrade. Questions 2 and 3 are moot now. > > > > Wes > > > > -Original Message- > > From: Rob Mensching [mailto:r...@robmensching.com] > > Sent: October 14, 2012 12:37 AM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /x > > ProductCode > > > > 1. I don't quite understand the question. The bundle self-update > > feature allows a BA to check the internet and tell the engine that > > there is a newer version of itself and to download then launch that > > instead. It is not clear to me what the command-line has to do with it. > > > > 2. Bundles are registered in ARP (aka: Program and Features, aka: the > > UninstallKey). That's how you can click on the "Uninstall" button in > > ARP and Burn launches to remove the bundle. You can search for it that > > way if you want. > > > > 3. Again, the self-update happens inside a Burn bundle. It isn't > > driven from a command-line argument. I may just be confused by not > > understanding your first question. > > > > You always have the Bundle. It's cached. That's how ARP works. > > > > On Fri, Oct 12, 2012 at 10:44 AM, Wesley Manning > >wrote: > > > > > Hi, have some questions about wixstba: > > > > > > (1) Wix 3.7 bundle self update feature: Is it possible (or any > > > plans to make it possible) to run from the command line? You would > > > need to run the bundle exe (thus have to know where its located). > > > There is already -uninstall, -repair, etc. > > > (2) Since Windows installer is part of the operating system it is > > > possible to install/uninstall/repair by running msiexec /x > > > ProductCode. You don't need to have the MSi file or know where it > > > is on the computer. Is there something similar for bundles? This > > > question is really about burn in general. > > > (3) Similar to (2) above but for the wix 3.7 self update feature: > > > give an upgrade code and URL and have it download and upgrade the > bundle. > > > Is this possible? > > > > > > I was hoping to have our software update itself / show its own > > > install progress UI so the user doesn't have to use the bundle for > > > that (they may not have the bundle anymore). The bundle would only > > > be used to install our software on a clean computer or if user goes > > > to ARP they can interact with the bundle. I see in > > > Wix37\src\burn\Samples there is an example on how to get progress from > burn. > > > > > > I could write code to download the burn exe myself but burn can > > > already download updates so... > > > > > > Wes > > > > > > -Original Message- > > > From: James Johnston [mailto:johnst...@inn-soft.com] > > > Sent: October-12-12 1:15 PM > > > To: wix-users@lists.sourceforge.net > > > Subj
Re: [WiX-users] Some in burn wixstba similar to msiexec /x ProductCode
Very True. I was thinking that there would not be a security issue if you check the UpgradeCode on the downloaded bundle before installing but anybody could make a bundle with my upgrade code. :) Maybe you could support it only in cases were the bundle is signed? You could check that the signature from both bundles come from the same company once downloaded. Is this reasonable? And/or add a URL attribute for wixstba in the wix project that gets compiled and that only allow checks for updates from this URL or based off this URL??? Anyways I was trying to take the easy route but looks like going to have to implement my own BA. :) Thanks. Wes -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: October-15-12 2:17 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /x ProductCode Having the update URL come from outside the Bundle would be a very large security gap. Essentially, any Bundle could be used to launch any other random Bundle. That's not right. There is certainly work that could be done in the wixstdba to support "bundle self-update" but I don't think passing the update URL via the command-line is the right way to do that. On Sun, Oct 14, 2012 at 5:56 PM, Wesley Manning wrote: > Sorry, for (1) I meant I don't want to do it from a custom BA. I want > to do it by calling the bundle from the application software that my > bundle installs. I know for wixstba you provide /uninstall and /repair > commands. > I use wixstba for my bundle so it would be nice if there was an "/upgrade" > command line option in wixstba where I pass the URL of the update and > the bundle downloads and installs it. Is this something that you guys > can do for version 3.7? > > Thanks for the info on UninstallKey in the registry. I actually > forgot about that. I see it has a BundleCachePath value so I can use > that to call my bundle. All I need is for the wixstba to have a > command line argument to do an upgrade. Questions 2 and 3 are moot now. > > Wes > > -Original Message- > From: Rob Mensching [mailto:r...@robmensching.com] > Sent: October 14, 2012 12:37 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /x > ProductCode > > 1. I don't quite understand the question. The bundle self-update > feature allows a BA to check the internet and tell the engine that > there is a newer version of itself and to download then launch that > instead. It is not clear to me what the command-line has to do with it. > > 2. Bundles are registered in ARP (aka: Program and Features, aka: the > UninstallKey). That's how you can click on the "Uninstall" button in > ARP and Burn launches to remove the bundle. You can search for it that > way if you want. > > 3. Again, the self-update happens inside a Burn bundle. It isn't > driven from a command-line argument. I may just be confused by not > understanding your first question. > > You always have the Bundle. It's cached. That's how ARP works. > > On Fri, Oct 12, 2012 at 10:44 AM, Wesley Manning >wrote: > > > Hi, have some questions about wixstba: > > > > (1) Wix 3.7 bundle self update feature: Is it possible (or any > > plans to make it possible) to run from the command line? You would > > need to run the bundle exe (thus have to know where its located). > > There is already -uninstall, -repair, etc. > > (2) Since Windows installer is part of the operating system it is > > possible to install/uninstall/repair by running msiexec /x > > ProductCode. You don't need to have the MSi file or know where it > > is on the computer. Is there something similar for bundles? This > > question is really about burn in general. > > (3) Similar to (2) above but for the wix 3.7 self update feature: > > give an upgrade code and URL and have it download and upgrade the bundle. > > Is this possible? > > > > I was hoping to have our software update itself / show its own > > install progress UI so the user doesn't have to use the bundle for > > that (they may not have the bundle anymore). The bundle would only > > be used to install our software on a clean computer or if user goes > > to ARP they can interact with the bundle. I see in > > Wix37\src\burn\Samples there is an example on how to get progress from burn. > > > > I could write code to download the burn exe myself but burn can > > already download updates so... > > > > Wes > > > > -Original Message- > > From: James Johnston [mailto:johnst...@inn-soft.com] > > Sent: October-12-12 1:15 PM > > To: wix-users@lists.sourceforge.net > > Subject: [WiX-users] Broken links on WiX web site > > > > Hi, > > > > The page at: > > http://wix.sourceforge.net/manual-wix3/WixUI_dialog_library.htm > > contains some broken links. Specifically, WixUI_Mondo and > > WixUI_Minimal are broken (404 Not Found). >
Re: [WiX-users] Some in burn wixstba similar to msiexec/xProductCode
3.7 is in a development/potentially unstable state, so I wouldn't upgrade to 3.7 for a production deployment as of yet. -Original Message- From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] Sent: Monday, October 15, 2012 12:45 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec/xProductCode Thanks, I will try updating again and hopefully I don't have more issues Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, October 15, 2012 1:39 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec/xProductCode New feature in v3.7: http://robmensching.com/blog/posts/2012/8/21/Enter-WiX-v3.7-toolset On Mon, Oct 15, 2012 at 10:29 AM, Michael Ogilvie < michael.ogil...@pixelink.com> wrote: > Does v3.6 have the bundle self-update feature or only v3.7? > > > Thank you, > Michael Ogilvie > Application Support Specialist | PixeLINK > > 1900 City Park Drive, Suite 410. > Ottawa, Ontario K1J 1A3 > > tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | > skype: pixelink.mogilvie > www.pixelink.com > > > -Original Message- > From: Rob Mensching [mailto:r...@robmensching.com] > Sent: Monday, October 15, 2012 1:17 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec > /xProductCode > > Having the update URL come from outside the Bundle would be a very > large security gap. Essentially, any Bundle could be used to launch > any other random Bundle. That's not right. There is certainly work > that could be done in the wixstdba to support "bundle self-update" but > I don't think passing the update URL via the command-line is the right way to > do that. > > > On Sun, Oct 14, 2012 at 5:56 PM, Wesley Manning > wrote: > > > Sorry, for (1) I meant I don't want to do it from a custom BA. I > > want to do it by calling the bundle from the application software > > that my bundle installs. I know for wixstba you provide /uninstall > > and /repair > commands. > > I use wixstba for my bundle so it would be nice if there was an > "/upgrade" > > command line option in wixstba where I pass the URL of the update > > and the bundle downloads and installs it. Is this something that > > you guys can do for version 3.7? > > > > Thanks for the info on UninstallKey in the registry. I actually > > forgot about that. I see it has a BundleCachePath value so I can > > use that to call my bundle. All I need is for the wixstba to have > > a command line argument to do an upgrade. Questions 2 and 3 are moot now. > > > > Wes > > > > -Original Message- > > From: Rob Mensching [mailto:r...@robmensching.com] > > Sent: October 14, 2012 12:37 AM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /x > > ProductCode > > > > 1. I don't quite understand the question. The bundle self-update > > feature allows a BA to check the internet and tell the engine that > > there is a newer version of itself and to download then launch that > > instead. It is not clear to me what the command-line has to do with it. > > > > 2. Bundles are registered in ARP (aka: Program and Features, aka: > > the UninstallKey). That's how you can click on the "Uninstall" > > button in ARP and Burn launches to remove the bundle. You can search > > for it that way if you want. > > > > 3. Again, the self-update happens inside a Burn bundle. It isn't > > driven from a command-line argument. I may just be confused by not > > understanding your first question. > > > > You always have the Bundle. It's cached. That's how ARP works. > > > > On Fri, Oct 12, 2012 at 10:44 AM, Wesley Manning > > > >wrote: > > > > > Hi, have some questions about wixstba: > > > > > > (1) Wix 3.7 bundle self update feature: Is it possible (or any > > > plans to make it possible) to run from the command line? You > > > would need to run the bundle exe (thus have to know where its located). > > > There is already -uninstall, -repair, etc. > > > (2) Since Windows installer is part of the operating system it is > > > possible to install/uninstall/repair by running msiexec /x > > > ProductCode. You don't need to have the MSi file or know where it > > > is on the computer. Is there something similar for bundles? This > > > question is really about burn in general. > > > (3) Similar to (2) above but for the wix 3.7 self update feature: > > > give an upgrade code and URL and have it download and upgrade the > bundle. > > > Is this possible? > > > > > > I w
Re: [WiX-users] Some in burn wixstba similar to msiexec/xProductCode
Thanks, I will try updating again and hopefully I don't have more issues Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, October 15, 2012 1:39 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec/xProductCode New feature in v3.7: http://robmensching.com/blog/posts/2012/8/21/Enter-WiX-v3.7-toolset On Mon, Oct 15, 2012 at 10:29 AM, Michael Ogilvie < michael.ogil...@pixelink.com> wrote: > Does v3.6 have the bundle self-update feature or only v3.7? > > > Thank you, > Michael Ogilvie > Application Support Specialist | PixeLINK > > 1900 City Park Drive, Suite 410. > Ottawa, Ontario K1J 1A3 > > tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | > skype: pixelink.mogilvie > www.pixelink.com > > > -Original Message- > From: Rob Mensching [mailto:r...@robmensching.com] > Sent: Monday, October 15, 2012 1:17 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec > /xProductCode > > Having the update URL come from outside the Bundle would be a very > large security gap. Essentially, any Bundle could be used to launch > any other random Bundle. That's not right. There is certainly work > that could be done in the wixstdba to support "bundle self-update" but > I don't think passing the update URL via the command-line is the right way to > do that. > > > On Sun, Oct 14, 2012 at 5:56 PM, Wesley Manning > wrote: > > > Sorry, for (1) I meant I don't want to do it from a custom BA. I > > want to do it by calling the bundle from the application software > > that my bundle installs. I know for wixstba you provide /uninstall > > and /repair > commands. > > I use wixstba for my bundle so it would be nice if there was an > "/upgrade" > > command line option in wixstba where I pass the URL of the update > > and the bundle downloads and installs it. Is this something that > > you guys can do for version 3.7? > > > > Thanks for the info on UninstallKey in the registry. I actually > > forgot about that. I see it has a BundleCachePath value so I can > > use that to call my bundle. All I need is for the wixstba to have > > a command line argument to do an upgrade. Questions 2 and 3 are moot now. > > > > Wes > > > > -Original Message- > > From: Rob Mensching [mailto:r...@robmensching.com] > > Sent: October 14, 2012 12:37 AM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /x > > ProductCode > > > > 1. I don't quite understand the question. The bundle self-update > > feature allows a BA to check the internet and tell the engine that > > there is a newer version of itself and to download then launch that > > instead. It is not clear to me what the command-line has to do with it. > > > > 2. Bundles are registered in ARP (aka: Program and Features, aka: > > the UninstallKey). That's how you can click on the "Uninstall" > > button in ARP and Burn launches to remove the bundle. You can search > > for it that way if you want. > > > > 3. Again, the self-update happens inside a Burn bundle. It isn't > > driven from a command-line argument. I may just be confused by not > > understanding your first question. > > > > You always have the Bundle. It's cached. That's how ARP works. > > > > On Fri, Oct 12, 2012 at 10:44 AM, Wesley Manning > > > >wrote: > > > > > Hi, have some questions about wixstba: > > > > > > (1) Wix 3.7 bundle self update feature: Is it possible (or any > > > plans to make it possible) to run from the command line? You > > > would need to run the bundle exe (thus have to know where its located). > > > There is already -uninstall, -repair, etc. > > > (2) Since Windows installer is part of the operating system it is > > > possible to install/uninstall/repair by running msiexec /x > > > ProductCode. You don't need to have the MSi file or know where it > > > is on the computer. Is there something similar for bundles? This > > > question is really about burn in general. > > > (3) Similar to (2) above but for the wix 3.7 self update feature: > > > give an upgrade code and URL and have it download and upgrade the > bundle. > > > Is this possible? > > > > > > I was hoping to have our software update itself / show its own > > > install progress UI so the user doesn't have to use the bundle for > > > that (they may not have the bundle anymore). The bundle would > > > only be used to install our software on a clean computer or if > > > user goes to ARP they can interact with the bundle. I see in > > > Wix37\src\burn\Samples there is an e
Re: [WiX-users] Some in burn wixstba similar to msiexec /xProductCode
New feature in v3.7: http://robmensching.com/blog/posts/2012/8/21/Enter-WiX-v3.7-toolset On Mon, Oct 15, 2012 at 10:29 AM, Michael Ogilvie < michael.ogil...@pixelink.com> wrote: > Does v3.6 have the bundle self-update feature or only v3.7? > > > Thank you, > Michael Ogilvie > Application Support Specialist | PixeLINK > > 1900 City Park Drive, Suite 410. > Ottawa, Ontario K1J 1A3 > > tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | > skype: pixelink.mogilvie > www.pixelink.com > > > -Original Message- > From: Rob Mensching [mailto:r...@robmensching.com] > Sent: Monday, October 15, 2012 1:17 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec > /xProductCode > > Having the update URL come from outside the Bundle would be a very large > security gap. Essentially, any Bundle could be used to launch any other > random Bundle. That's not right. There is certainly work that could be > done in the wixstdba to support "bundle self-update" but I don't think > passing the update URL via the command-line is the right way to do that. > > > On Sun, Oct 14, 2012 at 5:56 PM, Wesley Manning > wrote: > > > Sorry, for (1) I meant I don't want to do it from a custom BA. I want > > to do it by calling the bundle from the application software that my > > bundle installs. I know for wixstba you provide /uninstall and /repair > commands. > > I use wixstba for my bundle so it would be nice if there was an > "/upgrade" > > command line option in wixstba where I pass the URL of the update and > > the bundle downloads and installs it. Is this something that you guys > > can do for version 3.7? > > > > Thanks for the info on UninstallKey in the registry. I actually > > forgot about that. I see it has a BundleCachePath value so I can use > > that to call my bundle. All I need is for the wixstba to have a > > command line argument to do an upgrade. Questions 2 and 3 are moot now. > > > > Wes > > > > -Original Message- > > From: Rob Mensching [mailto:r...@robmensching.com] > > Sent: October 14, 2012 12:37 AM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /x > > ProductCode > > > > 1. I don't quite understand the question. The bundle self-update > > feature allows a BA to check the internet and tell the engine that > > there is a newer version of itself and to download then launch that > > instead. It is not clear to me what the command-line has to do with it. > > > > 2. Bundles are registered in ARP (aka: Program and Features, aka: the > > UninstallKey). That's how you can click on the "Uninstall" button in > > ARP and Burn launches to remove the bundle. You can search for it that > > way if you want. > > > > 3. Again, the self-update happens inside a Burn bundle. It isn't > > driven from a command-line argument. I may just be confused by not > > understanding your first question. > > > > You always have the Bundle. It's cached. That's how ARP works. > > > > On Fri, Oct 12, 2012 at 10:44 AM, Wesley Manning > >wrote: > > > > > Hi, have some questions about wixstba: > > > > > > (1) Wix 3.7 bundle self update feature: Is it possible (or any > > > plans to make it possible) to run from the command line? You would > > > need to run the bundle exe (thus have to know where its located). > > > There is already -uninstall, -repair, etc. > > > (2) Since Windows installer is part of the operating system it is > > > possible to install/uninstall/repair by running msiexec /x > > > ProductCode. You don't need to have the MSi file or know where it > > > is on the computer. Is there something similar for bundles? This > > > question is really about burn in general. > > > (3) Similar to (2) above but for the wix 3.7 self update feature: > > > give an upgrade code and URL and have it download and upgrade the > bundle. > > > Is this possible? > > > > > > I was hoping to have our software update itself / show its own > > > install progress UI so the user doesn't have to use the bundle for > > > that (they may not have the bundle anymore). The bundle would only > > > be used to install our software on a clean computer or if user goes > > > to ARP they can interact with the bundle. I see in > > > Wix37\src\burn\Samples there is an example on how to get progress from > burn. > > > > > > I could write code to download the burn exe myself but burn can > > > already download updates so... > > > > > > Wes > > > > > > -Original Message- > > > From: James Johnston [mailto:johnst...@inn-soft.com] > > > Sent: October-12-12 1:15 PM > > > To: wix-users@lists.sourceforge.net > > > Subject: [WiX-users] Broken links on WiX web site > > > > > > Hi, > > > > > > The page at: > > > http://wix.sourceforge.net/manual-wix3/WixUI_dialog_library.htm > > > contains some broken links. Specifically, WixUI_Mondo and > > > WixUI_Minimal are broken (404 Not Fou
Re: [WiX-users] Some in burn wixstba similar to msiexec /xProductCode
Does v3.6 have the bundle self-update feature or only v3.7? Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, October 15, 2012 1:17 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /xProductCode Having the update URL come from outside the Bundle would be a very large security gap. Essentially, any Bundle could be used to launch any other random Bundle. That's not right. There is certainly work that could be done in the wixstdba to support "bundle self-update" but I don't think passing the update URL via the command-line is the right way to do that. On Sun, Oct 14, 2012 at 5:56 PM, Wesley Manning wrote: > Sorry, for (1) I meant I don't want to do it from a custom BA. I want > to do it by calling the bundle from the application software that my > bundle installs. I know for wixstba you provide /uninstall and /repair > commands. > I use wixstba for my bundle so it would be nice if there was an "/upgrade" > command line option in wixstba where I pass the URL of the update and > the bundle downloads and installs it. Is this something that you guys > can do for version 3.7? > > Thanks for the info on UninstallKey in the registry. I actually > forgot about that. I see it has a BundleCachePath value so I can use > that to call my bundle. All I need is for the wixstba to have a > command line argument to do an upgrade. Questions 2 and 3 are moot now. > > Wes > > -Original Message- > From: Rob Mensching [mailto:r...@robmensching.com] > Sent: October 14, 2012 12:37 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /x > ProductCode > > 1. I don't quite understand the question. The bundle self-update > feature allows a BA to check the internet and tell the engine that > there is a newer version of itself and to download then launch that > instead. It is not clear to me what the command-line has to do with it. > > 2. Bundles are registered in ARP (aka: Program and Features, aka: the > UninstallKey). That's how you can click on the "Uninstall" button in > ARP and Burn launches to remove the bundle. You can search for it that > way if you want. > > 3. Again, the self-update happens inside a Burn bundle. It isn't > driven from a command-line argument. I may just be confused by not > understanding your first question. > > You always have the Bundle. It's cached. That's how ARP works. > > On Fri, Oct 12, 2012 at 10:44 AM, Wesley Manning >wrote: > > > Hi, have some questions about wixstba: > > > > (1) Wix 3.7 bundle self update feature: Is it possible (or any > > plans to make it possible) to run from the command line? You would > > need to run the bundle exe (thus have to know where its located). > > There is already -uninstall, -repair, etc. > > (2) Since Windows installer is part of the operating system it is > > possible to install/uninstall/repair by running msiexec /x > > ProductCode. You don't need to have the MSi file or know where it > > is on the computer. Is there something similar for bundles? This > > question is really about burn in general. > > (3) Similar to (2) above but for the wix 3.7 self update feature: > > give an upgrade code and URL and have it download and upgrade the bundle. > > Is this possible? > > > > I was hoping to have our software update itself / show its own > > install progress UI so the user doesn't have to use the bundle for > > that (they may not have the bundle anymore). The bundle would only > > be used to install our software on a clean computer or if user goes > > to ARP they can interact with the bundle. I see in > > Wix37\src\burn\Samples there is an example on how to get progress from burn. > > > > I could write code to download the burn exe myself but burn can > > already download updates so... > > > > Wes > > > > -Original Message- > > From: James Johnston [mailto:johnst...@inn-soft.com] > > Sent: October-12-12 1:15 PM > > To: wix-users@lists.sourceforge.net > > Subject: [WiX-users] Broken links on WiX web site > > > > Hi, > > > > The page at: > > http://wix.sourceforge.net/manual-wix3/WixUI_dialog_library.htm > > contains some broken links. Specifically, WixUI_Mondo and > > WixUI_Minimal are broken (404 Not Found). > > > > Not sure who maintains the web site so I'm writing to this list... > > > > Best regards, > > > > James Johnston > > > > > > > > > > -- > > Don't let slow site performance ruin your business. Deploy > > New Relic APM Deploy New Relic app performance management and know
Re: [WiX-users] Some in burn wixstba similar to msiexec /x ProductCode
Having the update URL come from outside the Bundle would be a very large security gap. Essentially, any Bundle could be used to launch any other random Bundle. That's not right. There is certainly work that could be done in the wixstdba to support "bundle self-update" but I don't think passing the update URL via the command-line is the right way to do that. On Sun, Oct 14, 2012 at 5:56 PM, Wesley Manning wrote: > Sorry, for (1) I meant I don't want to do it from a custom BA. I want to > do it by calling the bundle from the application software that my bundle > installs. I know for wixstba you provide /uninstall and /repair commands. > I use wixstba for my bundle so it would be nice if there was an "/upgrade" > command line option in wixstba where I pass the URL of the update and the > bundle downloads and installs it. Is this something that you guys can do > for version 3.7? > > Thanks for the info on UninstallKey in the registry. I actually forgot > about that. I see it has a BundleCachePath value so I can use that to > call my bundle. All I need is for the wixstba to have a command line > argument to do an upgrade. Questions 2 and 3 are moot now. > > Wes > > -Original Message- > From: Rob Mensching [mailto:r...@robmensching.com] > Sent: October 14, 2012 12:37 AM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Some in burn wixstba similar to msiexec /x > ProductCode > > 1. I don't quite understand the question. The bundle self-update feature > allows a BA to check the internet and tell the engine that there is a newer > version of itself and to download then launch that instead. It is not clear > to me what the command-line has to do with it. > > 2. Bundles are registered in ARP (aka: Program and Features, aka: the > UninstallKey). That's how you can click on the "Uninstall" button in ARP > and Burn launches to remove the bundle. You can search for it that way if > you want. > > 3. Again, the self-update happens inside a Burn bundle. It isn't driven > from a command-line argument. I may just be confused by not understanding > your first question. > > You always have the Bundle. It's cached. That's how ARP works. > > On Fri, Oct 12, 2012 at 10:44 AM, Wesley Manning >wrote: > > > Hi, have some questions about wixstba: > > > > (1) Wix 3.7 bundle self update feature: Is it possible (or any plans > > to make it possible) to run from the command line? You would need to > > run the bundle exe (thus have to know where its located). There is > > already -uninstall, -repair, etc. > > (2) Since Windows installer is part of the operating system it is > > possible to install/uninstall/repair by running msiexec /x > > ProductCode. You don't need to have the MSi file or know where it is > > on the computer. Is there something similar for bundles? This > > question is really about burn in general. > > (3) Similar to (2) above but for the wix 3.7 self update feature: give > > an upgrade code and URL and have it download and upgrade the bundle. > > Is this possible? > > > > I was hoping to have our software update itself / show its own install > > progress UI so the user doesn't have to use the bundle for that (they > > may not have the bundle anymore). The bundle would only be used to > > install our software on a clean computer or if user goes to ARP they > > can interact with the bundle. I see in Wix37\src\burn\Samples there > > is an example on how to get progress from burn. > > > > I could write code to download the burn exe myself but burn can > > already download updates so... > > > > Wes > > > > -Original Message- > > From: James Johnston [mailto:johnst...@inn-soft.com] > > Sent: October-12-12 1:15 PM > > To: wix-users@lists.sourceforge.net > > Subject: [WiX-users] Broken links on WiX web site > > > > Hi, > > > > The page at: > > http://wix.sourceforge.net/manual-wix3/WixUI_dialog_library.htm > > contains some broken links. Specifically, WixUI_Mondo and > > WixUI_Minimal are broken (404 Not Found). > > > > Not sure who maintains the web site so I'm writing to this list... > > > > Best regards, > > > > James Johnston > > > > > > > > -- > > Don't let slow site performance ruin your business. Deploy > > New Relic APM Deploy New Relic app performance management and know > > exactly what is happening inside your Ruby, Python, PHP, Java, and > > .NET app Try New Relic at no cost today and get our sweet Data Nerd > > shirt too! > > http://p.sf.net/sfu/newrelic-dev2dev > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > > > > -- > > Don't let slow site performance ruin your business. Deploy > > New Relic APM Deploy New Relic app performance management and know
Re: [WiX-users] VS2008 issue after update to v3.7
Hello, Thanks Rob, does the wix reference need to be in the Wix toolset directory? I tried adding it there and I was able to reference it. Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, October 15, 2012 1:13 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue after update to v3.7 Sounds like the registration didn't finish correctly for VS2008. I'll try to put together a repro machine and see if it is a one off or if WiX's setup is missing something. For the second issue, are you trying to add a Reference to your Custom BA from a .wixproj? If so, it is possible that the reference is added as an Extension reference and is trying to load your Custom BA as a toolset extension, which it is not, of course. Take a look at your failing project and see if the references look fishy. On Mon, Oct 15, 2012 at 5:32 AM, Michael Ogilvie < michael.ogil...@pixelink.com> wrote: > Don’t know why but after I ran this " start /wait devenv.exe /setup > /log "%TEMP%vssetup.log" devenv.exe /log "%TEMP%vsrun.log" " to try > and capture a log file I was able to open wixproj again in Visual > studio but I cannot add my custom BA anymore :( > > It states it's not a valid wix extension but it has not changed since > it was working before this issue. > > > Thank you, > Michael Ogilvie > Application Support Specialist | PixeLINK > > 1900 City Park Drive, Suite 410. > Ottawa, Ontario K1J 1A3 > > tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | > skype: pixelink.mogilvie > www.pixelink.com > > > -Original Message- > From: Rob Mensching [mailto:r...@robmensching.com] > Sent: Saturday, October 13, 2012 11:39 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] VS2008 issue after update to v3.7 > > Does v3.6 work? If so, then this is a bug in v3.7. Definitely possible > since the build system was radically improved in v3.7. If so, then > please file a bug with as much information as possible. > > On Thu, Oct 11, 2012 at 12:06 PM, Steven Ogilvie > wrote: > > > Ya sorry my bad > > > > If you have tried uninstalling WIX 3.x and VS2008 then re installing > > VS2008 and then WIX 3.x > > > > Don't forget 3.7 is not a released product it is beta... > > > > STeve > > > > -Original Message- > > From: keith.doug...@statcan.gc.ca > > [mailto:keith.doug...@statcan.gc.ca] > > Sent: October-11-12 2:56 PM > > To: wix-users@lists.sourceforge.net > > Subject: Re: [WiX-users] VS2008 issue after update to v3.7 > > > > Doesn't one need VS2010 to support .NET 4 anyway? > > > > > > 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 > > > > > > -Original Message- > > From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] > > Sent: October-11-12 2:54 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] VS2008 issue after update to v3.7 > > > > Hello, > > > > I don't have an option for 4 only 3.51, 3.0 and 2.0 > > > > > > Thank you, > > Michael Ogilvie > > Application Support Specialist | PixeLINK > > > > 1900 City Park Drive, Suite 410. > > Ottawa, Ontario K1J 1A3 > > > > tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 > > | > > skype: pixelink.mogilvie www.pixelink.com > > > > > > -Original Message- > > From: Steven Ogilvie [mailto:steven.ogil...@titus.com] > > Sent: Thursday, October 11, 2012 2:44 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] VS2008 issue after update to v3.7 > > > > In New Project dialog choose .NET Framework 4 instead of 3.51 > > > > See if that helps > > > > Steve > > > > -Original Message- > > From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] > > Sent: October-11-12 2:25 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] VS2008 issue after update to v3.7 > > > > Hello, > > > > In VS2008 I go to create a new Project and choose the Windows > > Installer XML types and if I try to create a new project from any of > > the templates I get that error. > > > > Images: > > > > http://www.files.pixelink.com/temp/error.bmp > > http://www.files.pixelink.com/temp/VS2008.bmp > > > > > > > > Thank you, > > Michael Ogilvie > > Application Support Specialist | PixeLINK > > > > 1900 City Park Drive, Suite 410. > > Ottawa, Ontario K1J 1A3 > > > > tel: 613.247.1211 Ex
Re: [WiX-users] WixManagedBootstrapperApplicationHost and .NET 2.0
What does your BootstrapperCore.config file look like? Does it correctly indicate the v2 NETFX should be used? On Mon, Oct 15, 2012 at 2:18 AM, Igor Brejc wrote: > Hi, > > I have a simple problem: I've written a managed bootstrapper (WiX v3.6) > written in .NET 2.0. On my developer machine (I have .NET 2.0 up to 4.0 > installed), everything works fine - my bootstrapper runs and installs. > Now I'm testing in on an Win XP (with only .NET 2.0 installed), I always > get the "Microsoft .NET Framework Required..." screen. I've tried different > things, like: > >- Using RegistrySearch to find the .NET 2.0 key and then using this as a >condition in ExePackage. The key is there in the registry. >- Using standard properties like NETFRAMEWORK20 as conditions. >- Playing with .exe.config file, setting thinks >like supportedRuntime, supportedFramework, runtimeVersion etc. > > I've been really struggling with this, read through all of the docs, > googled for it, tried a million things, and none of them seem to work - > .NET 2.0 doesn't seem to get detected. All the samples I found on the web > use .NET 3.5 or 4.0 as an example and I cannot get it work with 2.0. > > So my questions are: > >1. What is the right procedure for setting .NET 2.0 as a minimum >requirement? The minimum bare essentials in the .WXS, .config etc? >2. Alternatively: is there a way to turn off the whole .NET detection >thing in the bootstrapper? > > Any help would be _greatly_ appreciated! > Thanks, > Igor Brejc > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- virtually, Rob Mensching http://RobMensching.com LLC -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn ARP reports wrong size
If one either applies a bundle and then in an external process releases a MSP to patch the component. I thought I saw this happen on XP if I installed the RTM bundle, and then released an updated bundle with the original content and a MSP. Applying a MSP without the bundle I can see causing some issues, but applying the bundle one would think should work. When I went to try this, it seems that Windows XP is just wrong. Installing the base bundle reports a grossly undersized install (4.8 MB) instead of the ~884MB that would be expected. Windows 7 reports the correct values on initial install, but I don't have time to try the RTM install + Patch. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Monday, October 15, 2012 11:45 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Burn ARP reports wrong size What do you mean "patch the bundle"? Burn uses the sizes of the packages contained inside it to calculate the sizes in ARP. On Mon, Oct 15, 2012 at 7:16 AM, Hoover, Jacob wrote: > This is true up until you patch the bundle. I know externally > applying the MSP causes the size to be incorrect. I would have to test > it again to see if putting a bundle with a MSP on top of a bundle also caused > the issue. > > -Original Message- > From: Rob Mensching [mailto:r...@robmensching.com] > Sent: Saturday, October 13, 2012 10:23 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Burn ARP reports wrong size > > Burn currently shows the size of your chain (including the cached > packages). > > On Fri, Oct 12, 2012 at 2:52 AM, rowbot wrote: > > > I have the same issue... anyone any ideas? > > > > > > > > -- > > View this message in context: > > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-A > > RP -reports-wrong-size-tp6964175p7581303.html > > Sent from the wix-users mailing list archive at Nabble.com. > > > > > > > > -- > > Don't let slow site performance ruin your business. Deploy > > New Relic APM Deploy New Relic app performance management and know > > exactly what is happening inside your Ruby, Python, PHP, Java, and > > .NET app Try New Relic at no cost today and get our sweet Data Nerd > > shirt too! > > http://p.sf.net/sfu/newrelic-dev2dev > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > -- > virtually, > >Rob Mensching >http://RobMensching.com LLC > > -- > Don't let slow site performance ruin your business. Deploy > New Relic APM Deploy New Relic app performance management and know > exactly what is happening inside your Ruby, Python, PHP, Java, and > .NET app Try New Relic at no cost today and get our sweet Data Nerd > shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > -- > Don't let slow site performance ruin your business. Deploy > New Relic APM Deploy New Relic app performance management and know > exactly what is happening inside your Ruby, Python, PHP, Java, and > .NET app Try New Relic at no cost today and get our sweet Data Nerd > shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- virtually, Rob Mensching http://RobMensching.com LLC -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Elevation of Bootstrapper Application
It remembers them for a specific Bundle. There is not currently a mechanism to get to the state of another Bundle (I think there is a feature request open to enable that). On Mon, Oct 15, 2012 at 10:10 AM, Neil Sleightholm wrote: > >> you can set Variables and mark them Persist='yes' and Burn will > remember them for you. > > Am I correct that it remembers them for Uninstall/Repair but there is no > way to recall them if you do an upgrade? > > Neil > > -Original Message- > From: Rob Mensching [mailto:r...@robmensching.com] > Sent: 15 October 2012 17:50 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Elevation of Bootstrapper Application > > Neil is correct. The BA is not elevated because it does not rollback but > the package installs do. > > If you just want to store settings for your BA, you can set Variables and > mark them Persist='yes' and Burn will remember them for you. That sounds > like it might be more applicable for you anyway. > > > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- virtually, Rob Mensching http://RobMensching.com LLC -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] VS2008 issue after update to v3.7
Sounds like the registration didn't finish correctly for VS2008. I'll try to put together a repro machine and see if it is a one off or if WiX's setup is missing something. For the second issue, are you trying to add a Reference to your Custom BA from a .wixproj? If so, it is possible that the reference is added as an Extension reference and is trying to load your Custom BA as a toolset extension, which it is not, of course. Take a look at your failing project and see if the references look fishy. On Mon, Oct 15, 2012 at 5:32 AM, Michael Ogilvie < michael.ogil...@pixelink.com> wrote: > Don’t know why but after I ran this " start /wait devenv.exe /setup /log > "%TEMP%vssetup.log" devenv.exe /log "%TEMP%vsrun.log" " to try and capture > a log file I was able to open wixproj again in Visual studio but I cannot > add my custom BA anymore :( > > It states it's not a valid wix extension but it has not changed since it > was working before this issue. > > > Thank you, > Michael Ogilvie > Application Support Specialist | PixeLINK > > 1900 City Park Drive, Suite 410. > Ottawa, Ontario K1J 1A3 > > tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | > skype: pixelink.mogilvie > www.pixelink.com > > > -Original Message- > From: Rob Mensching [mailto:r...@robmensching.com] > Sent: Saturday, October 13, 2012 11:39 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] VS2008 issue after update to v3.7 > > Does v3.6 work? If so, then this is a bug in v3.7. Definitely possible > since the build system was radically improved in v3.7. If so, then please > file a bug with as much information as possible. > > On Thu, Oct 11, 2012 at 12:06 PM, Steven Ogilvie > wrote: > > > Ya sorry my bad > > > > If you have tried uninstalling WIX 3.x and VS2008 then re installing > > VS2008 and then WIX 3.x > > > > Don't forget 3.7 is not a released product it is beta... > > > > STeve > > > > -Original Message- > > From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] > > Sent: October-11-12 2:56 PM > > To: wix-users@lists.sourceforge.net > > Subject: Re: [WiX-users] VS2008 issue after update to v3.7 > > > > Doesn't one need VS2010 to support .NET 4 anyway? > > > > > > 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 > > > > > > -Original Message- > > From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] > > Sent: October-11-12 2:54 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] VS2008 issue after update to v3.7 > > > > Hello, > > > > I don't have an option for 4 only 3.51, 3.0 and 2.0 > > > > > > Thank you, > > Michael Ogilvie > > Application Support Specialist | PixeLINK > > > > 1900 City Park Drive, Suite 410. > > Ottawa, Ontario K1J 1A3 > > > > tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | > > skype: pixelink.mogilvie www.pixelink.com > > > > > > -Original Message- > > From: Steven Ogilvie [mailto:steven.ogil...@titus.com] > > Sent: Thursday, October 11, 2012 2:44 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] VS2008 issue after update to v3.7 > > > > In New Project dialog choose .NET Framework 4 instead of 3.51 > > > > See if that helps > > > > Steve > > > > -Original Message- > > From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] > > Sent: October-11-12 2:25 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] VS2008 issue after update to v3.7 > > > > Hello, > > > > In VS2008 I go to create a new Project and choose the Windows > > Installer XML types and if I try to create a new project from any of > > the templates I get that error. > > > > Images: > > > > http://www.files.pixelink.com/temp/error.bmp > > http://www.files.pixelink.com/temp/VS2008.bmp > > > > > > > > Thank you, > > Michael Ogilvie > > Application Support Specialist | PixeLINK > > > > 1900 City Park Drive, Suite 410. > > Ottawa, Ontario K1J 1A3 > > > > tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | > > skype: pixelink.mogilvie www.pixelink.com > > > > > > -Original Message- > > From: Steven Ogilvie [mailto:steven.ogil...@titus.com] > > Sent: Thursday, October 11, 2012 2:16 PM > > To: General discussion for Windows Installer XML toolset. > > Subject: Re: [WiX-users] VS2008 issue after update to v3.7 > > > > Hey Michael, > > > > I presume you mean your product.wxs file? > > > > Create a new WIX setup project, does the first two lines look like > > your "bundle" file? > > > > I.e. > > > xmlns="http://schemas.microsoft.com/wix/2006/wi"; > > > > Steve Ogilvie > > > > > > > > -Ori
Re: [WiX-users] Elevation of Bootstrapper Application
>> you can set Variables and mark them Persist='yes' and Burn will remember >> them for you. Am I correct that it remembers them for Uninstall/Repair but there is no way to recall them if you do an upgrade? Neil -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: 15 October 2012 17:50 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Elevation of Bootstrapper Application Neil is correct. The BA is not elevated because it does not rollback but the package installs do. If you just want to store settings for your BA, you can set Variables and mark them Persist='yes' and Burn will remember them for you. That sounds like it might be more applicable for you anyway. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Possible performance issues
The Burn log file has timestamps for just about every action. Can you share the log file? On Mon, Oct 15, 2012 at 7:00 AM, Jansson wrote: > Hi all, > > We are developing a burn bootstrapper application and have encountered > performance issues on some machines. On those machines, the setup takes > about seven seconds before the UI is even requested, but it should be noted > that the worst scenarios were produced after a reboot. We have tried to > pinpoint what the reason is. Also a greatly simplified package (containing > a > 2.5 mb msi with only Run() with detect() and plan() followed by a > messagebox > that when pressed triggers apply()) suffers from these problems. > > Has anyone suffered from similar problems? Has anyone any clue on which > parameters that can affect performance or what tools that can be useful for > our troubleshooting (so far, we have used logging, process monitor, testing > on different computers and removal of dependencies)? > > Best Regards, > Mattias > > > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Possible-performance-issues-tp7581346.html > Sent from the wix-users mailing list archive at Nabble.com. > > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- virtually, Rob Mensching http://RobMensching.com LLC -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Elevation of Bootstrapper Application
Neil is correct. The BA is not elevated because it does not rollback but the package installs do. If you just want to store settings for your BA, you can set Variables and mark them Persist='yes' and Burn will remember them for you. That sounds like it might be more applicable for you anyway. On Mon, Oct 15, 2012 at 6:45 AM, Neil Sleightholm wrote: > I looked at doing something similar and decided it was easier to write the > values in an MSI. My logic was that I didn't want to write until the > install had actually started and by that time the installer was already > running elevated. I am not familiar with the managed BA to know if you can > write your values after the install has started. > > Neil > > > >The values are set by our custom Managed Bootstrapper Application via the > >standard .NET Registry API, and not by any of the included packages. > >Since the information to be stored is on the bundle-level (which packages > >are selected for installation), it can't be moved into an MSI. > > > >I have attempted using IBurnEngine->Elevate(), but as far as I can see > >(and as I expect from it being a method of the engine), that does not > >give the managed bootstrapper application process elevated privileges. > > > >Daniel E. Bruce > >Software Developer, +47 91918893 > >Prediktor AS > >Habornveien 48B, N-1630 Gamle Fredrikstad, Norway > > > > > >> -Original Message- > >> From: Neil Sleightholm [mailto:n...@x2systems.com] > >> Sent: 15. oktober 2012 14:28 > >> To: General discussion for Windows Installer XML toolset. > >> Subject: Re: [WiX-users] Elevation of Bootstrapper Application > >> > >> How are you setting the values? Burn automatically prompts to elevate if > >> it detects an MSI that is set to all users but you can also set this > >>with > >> MsiPackage/@ForcePerMachine. > >> > >> Neil > >> > >> > >> >Hi. > >> > > >> >We are trying to keep some state alongside our bundle about which > >> >packages have been chosen for installation. The solution we envisioned > >> >was to put some registry entries within HKLM, but this fails on Windows > >> >7 (and probably Vista) due to HKLM requiring admin privileges. We > >> could > >> >work around this issue by writing to HKCU, but that would cause issues > >> >if another user ran the uninstallation (for instance) later. > >> > > >> >Is it possible to elevate the bootstrapper application in some way, so > >> >that we can write to HKLM? As a sideline question, does Burn store any > >> >information about what packages has been installed for later retrieval > >> >or persist any of the variables set during the installation on its own > >> >(if using a custom BA)? > >> > > >> >Daniel E. Bruce > >> >Software Developer, +47 91918893 > >> >Prediktor AS > >> >Habornveien 48B, N-1630 Gamle Fredrikstad, Norway > >> > > >> > > >> > > >> >--- > >> >--- > >> > > >> >Don't let slow site performance ruin your business. Deploy New Relic > >> >APM Deploy New Relic app performance management and know > >> exactly what > >> >is happening inside your Ruby, Python, PHP, Java, and .NET app Try > >> New > >> >Relic at no cost today and get our sweet Data Nerd shirt too! > >> >http://p.sf.net/sfu/newrelic-dev2dev > >> >___ > >> >WiX-users mailing list > >> >WiX-users@lists.sourceforge.net > >> >https://lists.sourceforge.net/lists/listinfo/wix-users > >> > >> > >> > >>- > >>- > >> Don't let slow site performance ruin your business. Deploy New Relic > >> APM Deploy New Relic app performance management and know exactly > >> what is happening inside your Ruby, Python, PHP, Java, and .NET app Try > >> New Relic at no cost today and get our sweet Data Nerd shirt too! > >> http://p.sf.net/sfu/newrelic-dev2dev > >> ___ > >> WiX-users mailing list > >> WiX-users@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/wix-users > >> > >> ___ > >> ___ > >> This email has been scanned by the Symantec Email Security.cloud > >> service. > >> For more information please visit http://www.symanteccloud.com > >> ___ > >> ___ > > > >-- > > > >Don't let slow site performance ruin your business. Deploy New Relic APM > >Deploy New Relic app performance management and know exactly > >what is happening inside your Ruby, Python, PHP, Java, and .NET app > >Try New Relic at no cost today and get our sweet Data Nerd shirt too! > >http://p.sf.net/sfu/newrelic-dev2dev > >___ > >WiX-users mailing list > >WiX-users@lists.sourceforge.net > >https://lists.sourceforge.net/lists/listinfo/wix-users > > > > -
Re: [WiX-users] WiX 3.6 MergeModule creation regression?
Awesome, can you create a bug with that information in it? We tend to lose issues only reported via email. On Sun, Oct 14, 2012 at 11:09 PM, Dirk Ziegelmeier wrote: > Hello Rob, > > here is a minimal mergemodule showing the error: > > > http://schemas.microsoft.com/wix/2006/wi";> > > /> > > > > > > > > > > Source="ComSTAHelper.dll" KeyPath="yes" Checksum="yes" /> > > > > > > > > W:\tmp\CommonFiles.wxs(14) : error LGHT0231 : The component > 'cComSTAHelper.63744358_CA08_4563_B039_4BE7181B668E' has a key file with > path 'TARGETDIR\acme\comsta > helper\comstahelper.dll'. Since this path is not rooted in one of the > standard directories (like ProgramFilesFolder), this component does not fit > the criteria > for having an automatically generated guid. (This error may also occur if > a path contains a likely standard directory such as nesting a directory > with name "Co > mmon Files" under ProgramFilesFolder.) > > Kind regards > Dirk > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- virtually, Rob Mensching http://RobMensching.com LLC -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn ARP reports wrong size
What do you mean "patch the bundle"? Burn uses the sizes of the packages contained inside it to calculate the sizes in ARP. On Mon, Oct 15, 2012 at 7:16 AM, Hoover, Jacob wrote: > This is true up until you patch the bundle. I know externally applying > the MSP causes the size to be incorrect. I would have to test it again to > see if putting a bundle with a MSP on top of a bundle also caused the issue. > > -Original Message- > From: Rob Mensching [mailto:r...@robmensching.com] > Sent: Saturday, October 13, 2012 10:23 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Burn ARP reports wrong size > > Burn currently shows the size of your chain (including the cached > packages). > > On Fri, Oct 12, 2012 at 2:52 AM, rowbot wrote: > > > I have the same issue... anyone any ideas? > > > > > > > > -- > > View this message in context: > > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-ARP > > -reports-wrong-size-tp6964175p7581303.html > > Sent from the wix-users mailing list archive at Nabble.com. > > > > > > -- > > Don't let slow site performance ruin your business. Deploy > > New Relic APM Deploy New Relic app performance management and know > > exactly what is happening inside your Ruby, Python, PHP, Java, and > > .NET app Try New Relic at no cost today and get our sweet Data Nerd > > shirt too! > > http://p.sf.net/sfu/newrelic-dev2dev > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > -- > virtually, > >Rob Mensching >http://RobMensching.com LLC > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly what is > happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic > at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- virtually, Rob Mensching http://RobMensching.com LLC -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn ARP reports wrong size
This is true up until you patch the bundle. I know externally applying the MSP causes the size to be incorrect. I would have to test it again to see if putting a bundle with a MSP on top of a bundle also caused the issue. -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Saturday, October 13, 2012 10:23 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Burn ARP reports wrong size Burn currently shows the size of your chain (including the cached packages). On Fri, Oct 12, 2012 at 2:52 AM, rowbot wrote: > I have the same issue... anyone any ideas? > > > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-ARP > -reports-wrong-size-tp6964175p7581303.html > Sent from the wix-users mailing list archive at Nabble.com. > > > -- > Don't let slow site performance ruin your business. Deploy > New Relic APM Deploy New Relic app performance management and know > exactly what is happening inside your Ruby, Python, PHP, Java, and > .NET app Try New Relic at no cost today and get our sweet Data Nerd > shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- virtually, Rob Mensching http://RobMensching.com LLC -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Broken links on WiX web site
Ah - sorry I didn't realize the Sourceforge bug database covered the web site, too. Ticket filed. > -Original Message- > From: Rob Mensching [mailto:r...@robmensching.com] > Sent: Sunday, October 14, 2012 03:27 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Broken links on WiX web site > > We do, can you please file a bug? > > On Fri, Oct 12, 2012 at 9:15 AM, James Johnston soft.com>wrote: > > > Hi, > > > > The page at: > > http://wix.sourceforge.net/manual-wix3/WixUI_dialog_library.htm > > contains some broken links. Specifically, WixUI_Mondo and > > WixUI_Minimal are broken (404 Not Found). > > > > Not sure who maintains the web site so I'm writing to this list... > > -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Elevation of Bootstrapper Application
I looked at doing something similar and decided it was easier to write the values in an MSI. My logic was that I didn't want to write until the install had actually started and by that time the installer was already running elevated. I am not familiar with the managed BA to know if you can write your values after the install has started. Neil >The values are set by our custom Managed Bootstrapper Application via the >standard .NET Registry API, and not by any of the included packages. >Since the information to be stored is on the bundle-level (which packages >are selected for installation), it can't be moved into an MSI. > >I have attempted using IBurnEngine->Elevate(), but as far as I can see >(and as I expect from it being a method of the engine), that does not >give the managed bootstrapper application process elevated privileges. > >Daniel E. Bruce >Software Developer, +47 91918893 >Prediktor AS >Habornveien 48B, N-1630 Gamle Fredrikstad, Norway > > >> -Original Message- >> From: Neil Sleightholm [mailto:n...@x2systems.com] >> Sent: 15. oktober 2012 14:28 >> To: General discussion for Windows Installer XML toolset. >> Subject: Re: [WiX-users] Elevation of Bootstrapper Application >> >> How are you setting the values? Burn automatically prompts to elevate if >> it detects an MSI that is set to all users but you can also set this >>with >> MsiPackage/@ForcePerMachine. >> >> Neil >> >> >> >Hi. >> > >> >We are trying to keep some state alongside our bundle about which >> >packages have been chosen for installation. The solution we envisioned >> >was to put some registry entries within HKLM, but this fails on Windows >> >7 (and probably Vista) due to HKLM requiring admin privileges. We >> could >> >work around this issue by writing to HKCU, but that would cause issues >> >if another user ran the uninstallation (for instance) later. >> > >> >Is it possible to elevate the bootstrapper application in some way, so >> >that we can write to HKLM? As a sideline question, does Burn store any >> >information about what packages has been installed for later retrieval >> >or persist any of the variables set during the installation on its own >> >(if using a custom BA)? >> > >> >Daniel E. Bruce >> >Software Developer, +47 91918893 >> >Prediktor AS >> >Habornveien 48B, N-1630 Gamle Fredrikstad, Norway >> > >> > >> > >> >--- >> >--- >> > >> >Don't let slow site performance ruin your business. Deploy New Relic >> >APM Deploy New Relic app performance management and know >> exactly what >> >is happening inside your Ruby, Python, PHP, Java, and .NET app Try >> New >> >Relic at no cost today and get our sweet Data Nerd shirt too! >> >http://p.sf.net/sfu/newrelic-dev2dev >> >___ >> >WiX-users mailing list >> >WiX-users@lists.sourceforge.net >> >https://lists.sourceforge.net/lists/listinfo/wix-users >> >> >> >>- >>- >> Don't let slow site performance ruin your business. Deploy New Relic >> APM Deploy New Relic app performance management and know exactly >> what is happening inside your Ruby, Python, PHP, Java, and .NET app Try >> New Relic at no cost today and get our sweet Data Nerd shirt too! >> http://p.sf.net/sfu/newrelic-dev2dev >> ___ >> WiX-users mailing list >> WiX-users@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/wix-users >> >> ___ >> ___ >> This email has been scanned by the Symantec Email Security.cloud >> service. >> For more information please visit http://www.symanteccloud.com >> ___ >> ___ > >-- > >Don't let slow site performance ruin your business. Deploy New Relic APM >Deploy New Relic app performance management and know exactly >what is happening inside your Ruby, Python, PHP, Java, and .NET app >Try New Relic at no cost today and get our sweet Data Nerd shirt too! >http://p.sf.net/sfu/newrelic-dev2dev >___ >WiX-users mailing list >WiX-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Elevation of Bootstrapper Application
The values are set by our custom Managed Bootstrapper Application via the standard .NET Registry API, and not by any of the included packages. Since the information to be stored is on the bundle-level (which packages are selected for installation), it can't be moved into an MSI. I have attempted using IBurnEngine->Elevate(), but as far as I can see (and as I expect from it being a method of the engine), that does not give the managed bootstrapper application process elevated privileges. Daniel E. Bruce Software Developer, +47 91918893 Prediktor AS Habornveien 48B, N-1630 Gamle Fredrikstad, Norway > -Original Message- > From: Neil Sleightholm [mailto:n...@x2systems.com] > Sent: 15. oktober 2012 14:28 > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Elevation of Bootstrapper Application > > How are you setting the values? Burn automatically prompts to elevate if > it detects an MSI that is set to all users but you can also set this with > MsiPackage/@ForcePerMachine. > > Neil > > > >Hi. > > > >We are trying to keep some state alongside our bundle about which > >packages have been chosen for installation. The solution we envisioned > >was to put some registry entries within HKLM, but this fails on Windows > >7 (and probably Vista) due to HKLM requiring admin privileges. We > could > >work around this issue by writing to HKCU, but that would cause issues > >if another user ran the uninstallation (for instance) later. > > > >Is it possible to elevate the bootstrapper application in some way, so > >that we can write to HKLM? As a sideline question, does Burn store any > >information about what packages has been installed for later retrieval > >or persist any of the variables set during the installation on its own > >(if using a custom BA)? > > > >Daniel E. Bruce > >Software Developer, +47 91918893 > >Prediktor AS > >Habornveien 48B, N-1630 Gamle Fredrikstad, Norway > > > > > > > >--- > >--- > > > >Don't let slow site performance ruin your business. Deploy New Relic > >APM Deploy New Relic app performance management and know > exactly what > >is happening inside your Ruby, Python, PHP, Java, and .NET app Try > New > >Relic at no cost today and get our sweet Data Nerd shirt too! > >http://p.sf.net/sfu/newrelic-dev2dev > >___ > >WiX-users mailing list > >WiX-users@lists.sourceforge.net > >https://lists.sourceforge.net/lists/listinfo/wix-users > > > -- > Don't let slow site performance ruin your business. Deploy New Relic > APM Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app Try > New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > ___ > ___ > This email has been scanned by the Symantec Email Security.cloud > service. > For more information please visit http://www.symanteccloud.com > ___ > ___ -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch issue
Hi Matt The edited msi that the msp targets does the correct 10.1.1 version. But the msp is still not patching it. I will try the companion file idea that Kajal explained. Thanks! On Oct 15, 2012, at 5:32 AM, "Matt O'Connell" wrote: > Use the version lying technique: Change the version of this FileId to > 10.1.1 in your patch upgrade image by editing the msi in orca. Then > re-build the patch pointing to your edited MSI. > > When the patch installs on top of the localised version it won't matter > that the transform has removed this attribute in the actual local MSI > being upgraded. Patching only looks at the file table version changes at > the time the patch was created. I.E. the patch 'thinks': this FileId was > version incremented when I was built so i'll happily apply the transform > to it. (Make sure your actual file verison matches your edits otherwise > you'll get request for source issues on repair). > > > On 15/10/2012 13:03, Uma Harano wrote: >> Unfortunately the mst has already been released to our customers. We are now >> trying to release the msp patch and it is not patching the file. So we are >> trying to see how we can now fix the problem (so that the msp updates the >> file correctly) caused by the released mst. > > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch issue
Thanks! I will try this. On Oct 15, 2012, at 5:46 AM, "Kajal Kumar Biswas" wrote: > You could try making it a companion file in your patch. > So, the installation state of a companion file depends not on its own file > version, but on the version of its companion parent. > Hence the mst removing the version no. will become ineffective. > > -Original Message- > From: Uma Harano [mailto:uhar...@esri.com] > Sent: Monday, October 15, 2012 5:33 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Patch issue > > Hi Kajal > Thank you for your email. > Unfortunately the mst has already been released to our customers. We are now > trying to release the msp patch and it is not patching the file. So we are > trying to see how we can now fix the problem (so that the msp updates the > file correctly) caused by the released mst. > > Thanks > Uma- > > -Original Message- > From: Kajal Kumar Biswas [mailto:kbis...@adobe.com] > Sent: Sunday, October 14, 2012 10:33 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] Patch issue > > When the mst is applied, the msi cache is not updated with the file version > at the end of the installation and hence during patching the file is not > updated. > What you can do this try creating the mst correctly, such that it does not > update the file version in the file table. > Can you let me know how exactly you are trying to create the mst file? > > -Original Message- > From: Uma Harano [mailto:uhar...@esri.com] > Sent: Sunday, October 14, 2012 3:52 AM > To: General discussion for Windows Installer XML toolset. > Subject: [WiX-users] Patch issue > > Hi > I have a patching issue I need help with. Version 10.1 of my msi installs a > dll with version 10.1.0. This is the also the version listed in the File > table of the msi for this dll. This msi is the English setup. I have embedded > msts in this msi that localizes the dialogs for this msi. There was a problem > with this mst, so when this mst is applied over the setup msi, the version of > this dll in the File table is removed. (The dll installed on the machine is > OK, it is just the File table of the msi that has the version removed when > you apply the mst). > > I now have an msp for this Version 10.1 that increments the dll to 10.1.1. I > am finding that when the localized msi is installed (with the mst that > removes the file version in the file table), and when the msp is applied over > this, the dll is not patched. > > How can I fix the msp so that the file is successfully patched in this > scenario? > > Thanks! > Uma Harano > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly what is > happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at > no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly what is > happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at > no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- > Don't let slow site performance ruin your business. Deploy New Relic APM > Deploy New Relic app performance management and know exactly > what is happening inside your Ruby, Python, PHP, Java, and .NET app > Try New Relic at no cost today and get our sweet Data Nerd shirt too! > http://p.sf.net/sfu/newrelic-dev2dev > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users >
Re: [WiX-users] Patch issue
You could try making it a companion file in your patch. So, the installation state of a companion file depends not on its own file version, but on the version of its companion parent. Hence the mst removing the version no. will become ineffective. -Original Message- From: Uma Harano [mailto:uhar...@esri.com] Sent: Monday, October 15, 2012 5:33 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch issue Hi Kajal Thank you for your email. Unfortunately the mst has already been released to our customers. We are now trying to release the msp patch and it is not patching the file. So we are trying to see how we can now fix the problem (so that the msp updates the file correctly) caused by the released mst. Thanks Uma- -Original Message- From: Kajal Kumar Biswas [mailto:kbis...@adobe.com] Sent: Sunday, October 14, 2012 10:33 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch issue When the mst is applied, the msi cache is not updated with the file version at the end of the installation and hence during patching the file is not updated. What you can do this try creating the mst correctly, such that it does not update the file version in the file table. Can you let me know how exactly you are trying to create the mst file? -Original Message- From: Uma Harano [mailto:uhar...@esri.com] Sent: Sunday, October 14, 2012 3:52 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Patch issue Hi I have a patching issue I need help with. Version 10.1 of my msi installs a dll with version 10.1.0. This is the also the version listed in the File table of the msi for this dll. This msi is the English setup. I have embedded msts in this msi that localizes the dialogs for this msi. There was a problem with this mst, so when this mst is applied over the setup msi, the version of this dll in the File table is removed. (The dll installed on the machine is OK, it is just the File table of the msi that has the version removed when you apply the mst). I now have an msp for this Version 10.1 that increments the dll to 10.1.1. I am finding that when the localized msi is installed (with the mst that removes the file version in the file table), and when the msp is applied over this, the dll is not patched. How can I fix the msp so that the file is successfully patched in this scenario? Thanks! Uma Harano -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] VS2008 issue after update to v3.7
Don’t know why but after I ran this " start /wait devenv.exe /setup /log "%TEMP%vssetup.log" devenv.exe /log "%TEMP%vsrun.log" " to try and capture a log file I was able to open wixproj again in Visual studio but I cannot add my custom BA anymore :( It states it's not a valid wix extension but it has not changed since it was working before this issue. Thank you, Michael Ogilvie Application Support Specialist | PixeLINK 1900 City Park Drive, Suite 410. Ottawa, Ontario K1J 1A3 tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | skype: pixelink.mogilvie www.pixelink.com -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Saturday, October 13, 2012 11:39 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] VS2008 issue after update to v3.7 Does v3.6 work? If so, then this is a bug in v3.7. Definitely possible since the build system was radically improved in v3.7. If so, then please file a bug with as much information as possible. On Thu, Oct 11, 2012 at 12:06 PM, Steven Ogilvie wrote: > Ya sorry my bad > > If you have tried uninstalling WIX 3.x and VS2008 then re installing > VS2008 and then WIX 3.x > > Don't forget 3.7 is not a released product it is beta... > > STeve > > -Original Message- > From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] > Sent: October-11-12 2:56 PM > To: wix-users@lists.sourceforge.net > Subject: Re: [WiX-users] VS2008 issue after update to v3.7 > > Doesn't one need VS2010 to support .NET 4 anyway? > > > 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 > > > -Original Message- > From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] > Sent: October-11-12 2:54 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] VS2008 issue after update to v3.7 > > Hello, > > I don't have an option for 4 only 3.51, 3.0 and 2.0 > > > Thank you, > Michael Ogilvie > Application Support Specialist | PixeLINK > > 1900 City Park Drive, Suite 410. > Ottawa, Ontario K1J 1A3 > > tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | > skype: pixelink.mogilvie www.pixelink.com > > > -Original Message- > From: Steven Ogilvie [mailto:steven.ogil...@titus.com] > Sent: Thursday, October 11, 2012 2:44 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] VS2008 issue after update to v3.7 > > In New Project dialog choose .NET Framework 4 instead of 3.51 > > See if that helps > > Steve > > -Original Message- > From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] > Sent: October-11-12 2:25 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] VS2008 issue after update to v3.7 > > Hello, > > In VS2008 I go to create a new Project and choose the Windows > Installer XML types and if I try to create a new project from any of > the templates I get that error. > > Images: > > http://www.files.pixelink.com/temp/error.bmp > http://www.files.pixelink.com/temp/VS2008.bmp > > > > Thank you, > Michael Ogilvie > Application Support Specialist | PixeLINK > > 1900 City Park Drive, Suite 410. > Ottawa, Ontario K1J 1A3 > > tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | > skype: pixelink.mogilvie www.pixelink.com > > > -Original Message- > From: Steven Ogilvie [mailto:steven.ogil...@titus.com] > Sent: Thursday, October 11, 2012 2:16 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] VS2008 issue after update to v3.7 > > Hey Michael, > > I presume you mean your product.wxs file? > > Create a new WIX setup project, does the first two lines look like > your "bundle" file? > > I.e. > xmlns="http://schemas.microsoft.com/wix/2006/wi"; > > Steve Ogilvie > > > > -Original Message- > From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] > Sent: October-11-12 2:03 PM > To: General discussion for Windows Installer XML toolset. > Subject: Re: [WiX-users] VS2008 issue after update to v3.7 > > I have tried to repair my VS2008 pro and I have also tried repairing > the > v3.7 install. > > Still does not work. > > I have even uninstalled v3.7 and installed 3.6 again and it still does > not work. V3.7 did something to my vs2008 > > > Thank you, > Michael Ogilvie > Application Support Specialist | PixeLINK > > 1900 City Park Drive, Suite 410. > Ottawa, Ontario K1J 1A3 > > tel: 613.247.1211 Ext. 242 | cell: 613.302.9844 | fax: 613.247.2001 | > skype: pixelink.mogilvie www.pixelink.com > > > -Original Message- > From: Michael Ogilvie [mailto:michael.ogil...@pixelink.com] > Sent: Thursday, October 11, 2012 1
Re: [WiX-users] Elevation of Bootstrapper Application
How are you setting the values? Burn automatically prompts to elevate if it detects an MSI that is set to all users but you can also set this with MsiPackage/@ForcePerMachine. Neil >Hi. > >We are trying to keep some state alongside our bundle about which >packages have been chosen for installation. The solution we envisioned >was to put some registry entries within HKLM, but this fails on Windows 7 >(and probably Vista) due to HKLM requiring admin privileges. We could >work around this issue by writing to HKCU, but that would cause issues if >another user ran the uninstallation (for instance) later. > >Is it possible to elevate the bootstrapper application in some way, so >that we can write to HKLM? As a sideline question, does Burn store any >information about what packages has been installed for later retrieval or >persist any of the variables set during the installation on its own (if >using a custom BA)? > >Daniel E. Bruce >Software Developer, +47 91918893 >Prediktor AS >Habornveien 48B, N-1630 Gamle Fredrikstad, Norway > > > >-- > >Don't let slow site performance ruin your business. Deploy New Relic APM >Deploy New Relic app performance management and know exactly >what is happening inside your Ruby, Python, PHP, Java, and .NET app >Try New Relic at no cost today and get our sweet Data Nerd shirt too! >http://p.sf.net/sfu/newrelic-dev2dev >___ >WiX-users mailing list >WiX-users@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch issue
Use the version lying technique: Change the version of this FileId to 10.1.1 in your patch upgrade image by editing the msi in orca. Then re-build the patch pointing to your edited MSI. When the patch installs on top of the localised version it won't matter that the transform has removed this attribute in the actual local MSI being upgraded. Patching only looks at the file table version changes at the time the patch was created. I.E. the patch 'thinks': this FileId was version incremented when I was built so i'll happily apply the transform to it. (Make sure your actual file verison matches your edits otherwise you'll get request for source issues on repair). On 15/10/2012 13:03, Uma Harano wrote: > Unfortunately the mst has already been released to our customers. We are now > trying to release the msp patch and it is not patching the file. So we are > trying to see how we can now fix the problem (so that the msp updates the > file correctly) caused by the released mst. -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Elevation of Bootstrapper Application
Hi. We are trying to keep some state alongside our bundle about which packages have been chosen for installation. The solution we envisioned was to put some registry entries within HKLM, but this fails on Windows 7 (and probably Vista) due to HKLM requiring admin privileges. We could work around this issue by writing to HKCU, but that would cause issues if another user ran the uninstallation (for instance) later. Is it possible to elevate the bootstrapper application in some way, so that we can write to HKLM? As a sideline question, does Burn store any information about what packages has been installed for later retrieval or persist any of the variables set during the installation on its own (if using a custom BA)? Daniel E. Bruce Software Developer, +47 91918893 Prediktor AS Habornveien 48B, N-1630 Gamle Fredrikstad, Norway -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Patch issue
Hi Kajal Thank you for your email. Unfortunately the mst has already been released to our customers. We are now trying to release the msp patch and it is not patching the file. So we are trying to see how we can now fix the problem (so that the msp updates the file correctly) caused by the released mst. Thanks Uma- -Original Message- From: Kajal Kumar Biswas [mailto:kbis...@adobe.com] Sent: Sunday, October 14, 2012 10:33 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch issue When the mst is applied, the msi cache is not updated with the file version at the end of the installation and hence during patching the file is not updated. What you can do this try creating the mst correctly, such that it does not update the file version in the file table. Can you let me know how exactly you are trying to create the mst file? -Original Message- From: Uma Harano [mailto:uhar...@esri.com] Sent: Sunday, October 14, 2012 3:52 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Patch issue Hi I have a patching issue I need help with. Version 10.1 of my msi installs a dll with version 10.1.0. This is the also the version listed in the File table of the msi for this dll. This msi is the English setup. I have embedded msts in this msi that localizes the dialogs for this msi. There was a problem with this mst, so when this mst is applied over the setup msi, the version of this dll in the File table is removed. (The dll installed on the machine is OK, it is just the File table of the msi that has the version removed when you apply the mst). I now have an msp for this Version 10.1 that increments the dll to 10.1.1. I am finding that when the localized msi is installed (with the mst that removes the file version in the file table), and when the msp is applied over this, the dll is not patched. How can I fix the msp so that the file is successfully patched in this scenario? Thanks! Uma Harano -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Having trouble installing a native assembly in SxS
Hi all,
I am having trouble installing a native assembly in WinSxS. Here's what I
did:
I created a simple native code dll (just let VC2010 create one for me,
really)
I have self-signed a certificate, pktextract gives me this on it:
Microsoft (R) Side-By-Side Public Key Token Extractor 1.1.3.0
Copyright (C) Microsoft Corporation 2000-2002. All Rights Reserved
Certificate: "SxS Test Cert" - 2048 bits long
publicKeyToken="750e4397f64dcd89"
I used signtool to sign the dll. I did not timestamped it, and that shows
when I look at dll properties.
I created a manifest for my assembly using mt.exe:
http://www.w3.org/2000/09/xmldsig#";>
http://www.w3.org/2000/09/xmldsig#sha1
">
xrzo5LYc4y1QcGVGVbLPpWRKQLs=
Manifest creation gave me this *.cdf:
[CatalogHeader]
Name=TestDLL.dll.cat
ResultDir=.\Debug
[CatalogFiles]
TestDLL.dll.manifest=TestDLL.dll.manifest
TestDLL.dll.manifest=TestDLL.dll.manifest
Using makecat, I created a cat file from the *.cdf above, and I signed it
in the same way I signed the dll itself.
I have the following wix:
http://schemas.microsoft.com/wix/2006/wi";>
I can build an *.msi from there, but when I try to install, I get an error
(captured by running the msi install from WixEdit):
MSI (s) (C4:60) [13:31:42:678]: Executing op:
SourceListRegisterLastUsed(SourceProduct=4C725A4B-7E5A-4502-B2E9-F72B25CC8D51,LastUsedSource=\Test\WiX\)
MSI (s) (C4:60) [13:31:42:678]: Entering
CMsiConfigurationManager::SetLastUsedSource.
MSI (s) (C4:60) [13:31:42:680]: Specifed source is already in a list.
MSI (s) (C4:60) [13:31:42:681]: User policy value 'SearchOrder' is 'nmu'
MSI (s) (C4:60) [13:31:42:681]: Adding new sources is allowed.
MSI (s) (C4:60) [13:31:42:682]: Set LastUsedSource to:
...\Test\WiX\.
MSI (s) (C4:60) [13:31:42:684]: Set LastUsedType to: n.
MSI (s) (C4:60) [13:31:42:685]: Set LastUsedIndex to: 1.
MSI (s) (C4:60) [13:31:42:686]: Executing op:
End(Checksum=0,ProgressTotalHDWord=0,ProgressTotalLDWord=296896)
MSI (s) (C4:60) [13:31:42:743]: Assembly Error:An HRESULT could not be
translated to a corresponding Win32 error code.
MSI (s) (C4:60) [13:31:42:745]: Note: 1: 1935 2:
6DC0F277-B9BF-4115-8B3A-CEDB2323FD5D 3: 0x800736FD 4: IAssemblyCacheItem
5: Commit 6:
TestDLL,version="1.0.0.1",type="win32",processorArchitecture="x86",publicKeyToken="750e4397f64dcd89"
MSI (s) (C4:60) [13:31:42:746]: Assembly Error (sxs): Please look into
Component Based Servicing Log located at -253369224ndir\logs\cbs\cbs.log
to get more diagnostic information.
MSI (s) (C4:60) [13:31:42:747]: Note: 1: 2205 2: 3: Error
MSI (s) (C4:60) [13:31:42:749]: Note: 1: 2228 2: 3: Error 4: SELECT
`Message` FROM `Error` WHERE `Error` = 1935
When I look at CBS log, I see:
2012-10-15 13:41:34, Info CSI003b Performing 3
operations; 3 are not lock/unlock and follow:
Stage (1): flags: 8 app: [TestDLL, Version = 1.0.0.1, pA =
PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope neutral,
PublicKeyToken = {l:8 b:750e4397f64dcd89}, Type = [l:10{5}]"win32",
TypeName neutral, PublicKey neutral]) comp: TestDLL, Version = 1.0.0.1, pA
= PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope neutral,
PublicKeyToken = {l:8 b:750e4397f64dcd89}, Type = [l:10{5}]"win32",
TypeName neutral, PublicKey neutral man: @0x1b0178
StageFile (2): flags: 8 app: [TestDLL, Version = 1.0.0.1, pA =
PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope neutral,
PublicKeyToken = {l:8 b:750e4397f64dcd89}, Type = [l:10{5}]"win32",
TypeName neutral, PublicKey neutral]) comp: TestDLL, Version = 1.0.0.1, pA
= PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope neutral,
PublicKeyToken = {l:8 b:750e4397f64dcd89}, Type = [l:10{5}]"win32",
TypeName neutral, PublicKey neutral file:
[ml:24{12},l:22{11}]"TestDll.dll" srcfile: @0x1ae9d8
AddCat (14): flags: 0 catfile: @0x1b0208
2012-10-15 13:41:34, Info CSI003c Creating NT
transaction (seq 10), objectname [6]"(null)"
2012-10-15 13:41:34, Info CSI003d Created NT
transaction (seq 10) result 0x, handle @0x288
2012-10-15 13:41:34, Info CSI
003e@2012/10/15:11:41:34.817 CSI perf trace:
CSIPERF:TXCOMMIT;12619
2012-10-15 13:41:34, Info SXSSubmitting install
transaction
2012-10-15 13:41:34, Info CSI003f Performing 1
operations; 1 are not lock/unlock and follow:
Install (5): flags: 0 tlc: [TestDLL, Version = 1.0.0.1, pA =
PROCESSOR_ARCHITECTURE_INTEL (0), Culture neutral, VersionScope neutral,
PublicKeyToken = {l:8 b:750e4397f64dcd89}, Type = [l:10{5}]"win32",
TypeName neutral, PublicKey neutral]) ref: ( flgs: guid:
{27dec61e-b43c-4ac8-88db-e209a8242d90} name: [l:0]"" ncdata:
[l:62{31}]"C:
