Re: [WiX-users] How to use PostBuild event code to include configuration in msi name (eg MyInstaller Test.msi)
Hello Rob, Thanks for the reply. We have our Wix project in the same solution as the application and just create the msi when the solution is built by Visual Studio. We are not doing anything in Wix with the command line, everything is done via Visual Studio. I do not think it is possible to set the TargetName from within a wxs file. Our solution also contains a web services project with different endpoints depending upon the configuration being compiled. So if a particular build is going to be released to testing, we build twice, once for Test and once for Lab and send both msi files to Test. Once it has passed Test, the Lab msi is sent to the Lab. This process ensures both msi files were created against the same application code base. Are we missing something obvious here? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-use-PostBuild-event-code-to-include-configuration-in-msi-name-eg-MyInstaller-Test-msi-tp7584890p7584912.html Sent from the wix-users mailing list archive at Nabble.com. -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to use PostBuild event code to include configuration in msi name (eg MyInstaller Test.msi)
Hello raj, Thanks for your response. We are just beginning to use Wix and do everything within Visual Studio. Our wix project is included within the application solution, so the msi is created when the solution is built. Can the code you were kind enough to share be used or adapted within the Visual Studio solution build process? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-use-PostBuild-event-code-to-include-configuration-in-msi-name-eg-MyInstaller-Test-msi-tp7584890p7584913.html Sent from the wix-users mailing list archive at Nabble.com. -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Util RegistrySearch Element and Win64 attribute
Util RegistrySearch has an attribute Winb64 that seems to be no by default. If this is set to Yes, Would it mean it would look in the 32bit registry on 32bit OS and 64bit registry on 64bit OS ? The reason I am seeking some clarification is become some other attributes like these seem to be have different default values for x64 vs x86 configurations. If you have a boostrapper project that has both x64 and x86 configurations, Does it have any effect on the final exe. I mean on attribute default values somewhere ? Thanks Raj -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to use PostBuild event code to include configuration in msi name (eg MyInstaller Test.msi)
Hi
I just tried this simple project. Basically I just manually edited the
wixproj and simply added OutputName override in the debug configuration.
Now when I open this project and build the debug configuration the output
is simplemsidebug.msi and in release the output is simplemsi.msi
-Raj
http://schemas.microsoft.com/developer/msbuild/2003";>
Debug
x86
3.7
{ed2999fa-e2e9-4ca9-81ae-cd6e3a9d98d1}
2.0
SimpleMsi
Package
$(MSBuildExtensionsPath32)\Microsoft\WiX\v3.x\Wix.targets
$(MSBuildExtensionsPath)\Microsoft\WiX\v3.x\Wix.targets
bin\$(Configuration)\
obj\$(Configuration)\
Debug
SimpleMsiDebug
bin\$(Configuration)\
obj\$(Configuration)\
On Fri, Apr 5, 2013 at 5:58 AM, j2associates wrote:
> Hello raj,
>
> Thanks for your response. We are just beginning to use Wix and do
> everything
> within Visual Studio. Our wix project is included within the application
> solution, so the msi is created when the solution is built.
>
> Can the code you were kind enough to share be used or adapted within the
> Visual Studio solution build process?
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-use-PostBuild-event-code-to-include-configuration-in-msi-name-eg-MyInstaller-Test-msi-tp7584890p7584913.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
>
> --
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Util RegistrySearch Element and Win64 attribute
The Win64 attribute defaults to 'yes' or 'no' based on the value you pass to the candle.exe -arch switch. If Win64 is 'no' it searches 32-bit. If it is 'yes' it will search 64-bit on 64-bit machine and 32-bit on a 32-bit machine (because there is no 64-bit). Bootstrapper is completely separate and is not affected by the MSI build. On Fri, Apr 5, 2013 at 5:09 AM, ptr wrote: > Util RegistrySearch has an attribute Winb64 that seems to be no by default. > If this is set to Yes, Would it mean it would look in the 32bit registry > on 32bit OS and 64bit registry on 64bit OS ? > > The reason I am seeking some clarification is become some other attributes > like these seem to be have different default values for x64 vs x86 > configurations. > > If you have a boostrapper project that has both x64 and x86 configurations, > Does it have any effect on the final exe. I mean on attribute default > values somewhere ? > > > Thanks > Raj > > -- > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to use PostBuild event code to include configuration in msi name (eg MyInstaller Test.msi)
Yeah, changing the TargetName should just be a matter of editing the .wixproj to include another MSBuild property. This is really about MSBuild though functionality, not the WiX toolset. On Fri, Apr 5, 2013 at 4:54 AM, j2associates wrote: > Hello Rob, > > Thanks for the reply. > > We have our Wix project in the same solution as the application and just > create the msi when the solution is built by Visual Studio. We are not > doing > anything in Wix with the command line, everything is done via Visual > Studio. > > I do not think it is possible to set the TargetName from within a wxs file. > > Our solution also contains a web services project with different endpoints > depending upon the configuration being compiled. So if a particular build > is > going to be released to testing, we build twice, once for Test and once for > Lab and send both msi files to Test. Once it has passed Test, the Lab msi > is > sent to the Lab. This process ensures both msi files were created against > the same application code base. > > Are we missing something obvious here? > > > > -- > View this message in context: > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-use-PostBuild-event-code-to-include-configuration-in-msi-name-eg-MyInstaller-Test-msi-tp7584890p7584912.html > Sent from the wix-users mailing list archive at Nabble.com. > > > -- > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Util RegistrySearch Element and Win64 attribute
Thanks Rob.. I just wanted to clarify it because the documentation seems out of date. *RegistrySearch documentation says* Instructs the search to look in the 64-bit registry when the value is 'yes'. When the value is 'no', the search looks in the 32-bit registry. The default value depends on the value of the Package/@Platform attribute: if the @Platform attribute value is 'x86', the default @Win64 attribute value is 'no'; otherwise, the default value is 'yes'. *Util Extension RegistrySearch documentation says* Instructs the search to look in the 64-bit registry when the value is 'yes'. When the value is 'no', the search looks in the 32-bit registry. The default value is 'no'. So it seems like even though the bootstrapper is always 32bit it matters what its build configuration. We have installers that only allow 32bit on 32bit OS and 64bit components on 64bit OS. I am making a boostrapper that has 32bit components as well as 64bit components as downloaded msis that have installcondition based on bitness of the OS. I was wondering if setting winb64 to yes is the right thing. It seems like it is. Thanks Raj On Fri, Apr 5, 2013 at 6:53 AM, Rob Mensching wrote: > The Win64 attribute defaults to 'yes' or 'no' based on the value you pass > to the candle.exe -arch switch. If Win64 is 'no' it searches 32-bit. If it > is 'yes' it will search 64-bit on 64-bit machine and 32-bit on a 32-bit > machine (because there is no 64-bit). > > Bootstrapper is completely separate and is not affected by the MSI build. > > > On Fri, Apr 5, 2013 at 5:09 AM, ptr wrote: > > > Util RegistrySearch has an attribute Winb64 that seems to be no by > default. > > If this is set to Yes, Would it mean it would look in the 32bit registry > > on 32bit OS and 64bit registry on 64bit OS ? > > > > The reason I am seeking some clarification is become some other > attributes > > like these seem to be have different default values for x64 vs x86 > > configurations. > > > > If you have a boostrapper project that has both x64 and x86 > configurations, > > Does it have any effect on the final exe. I mean on attribute default > > values somewhere ? > > > > > > Thanks > > Raj > > > > > -- > > Minimize network downtime and maximize team effectiveness. > > Reduce network management and security costs.Learn how to hire > > the most talented Cisco Certified professionals. Visit the > > Employer Resources Portal > > http://www.cisco.com/web/learning/employer_resources/index.html > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > -- > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Util RegistrySearch Element and Win64 attribute
Sorry, my bad. I didn't realize you were talking about the util:RegistrySearch. My answer was about the MSI based RegistrySearch. Using util:RegistrySearch is explicit. If you say Win64='yes' then the search is 64-bit and vice versa. You can ignore the fact that the Burn engine is 32-bit. It matters none. On Fri, Apr 5, 2013 at 6:59 AM, ptr wrote: > Thanks Rob.. I just wanted to clarify it because the documentation seems > out of date. > > *RegistrySearch documentation says* > > Instructs the search to look in the 64-bit registry when the value is > 'yes'. When the value is 'no', the search looks in the 32-bit registry. The > default value depends on the value of the Package/@Platform attribute: if > the @Platform attribute value is 'x86', the default @Win64 attribute value > is 'no'; otherwise, the default value is 'yes'. > > *Util Extension RegistrySearch documentation says* > Instructs the search to look in the 64-bit registry when the value is > 'yes'. When the value is 'no', the search looks in the 32-bit registry. The > default value is 'no'. > > So it seems like even though the bootstrapper is always 32bit it matters > what its build configuration. We have installers that only allow 32bit on > 32bit OS and 64bit components on 64bit OS. I am making a boostrapper that > has 32bit components as well as 64bit components as downloaded msis that > have installcondition based on bitness of the OS. I was wondering if > setting winb64 to yes is the right thing. It seems like it is. > > Thanks > Raj > > > > > > On Fri, Apr 5, 2013 at 6:53 AM, Rob Mensching > wrote: > > > The Win64 attribute defaults to 'yes' or 'no' based on the value you pass > > to the candle.exe -arch switch. If Win64 is 'no' it searches 32-bit. If > it > > is 'yes' it will search 64-bit on 64-bit machine and 32-bit on a 32-bit > > machine (because there is no 64-bit). > > > > Bootstrapper is completely separate and is not affected by the MSI build. > > > > > > On Fri, Apr 5, 2013 at 5:09 AM, ptr wrote: > > > > > Util RegistrySearch has an attribute Winb64 that seems to be no by > > default. > > > If this is set to Yes, Would it mean it would look in the 32bit > registry > > > on 32bit OS and 64bit registry on 64bit OS ? > > > > > > The reason I am seeking some clarification is become some other > > attributes > > > like these seem to be have different default values for x64 vs x86 > > > configurations. > > > > > > If you have a boostrapper project that has both x64 and x86 > > configurations, > > > Does it have any effect on the final exe. I mean on attribute default > > > values somewhere ? > > > > > > > > > Thanks > > > Raj > > > > > > > > > -- > > > Minimize network downtime and maximize team effectiveness. > > > Reduce network management and security costs.Learn how to hire > > > the most talented Cisco Certified professionals. Visit the > > > Employer Resources Portal > > > http://www.cisco.com/web/learning/employer_resources/index.html > > > ___ > > > WiX-users mailing list > > > WiX-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > > > > > -- > > Minimize network downtime and maximize team effectiveness. > > Reduce network management and security costs.Learn how to hire > > the most talented Cisco Certified professionals. Visit the > > Employer Resources Portal > > http://www.cisco.com/web/learning/employer_resources/index.html > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > -- > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Util RegistrySearch Element and Win64 attribute
But what you said about if I set Win64='yes' It will do 64bit search on 64bit OS and on 32bit OS it will do 32bit search and not fail. is still true for Util:RegistrySearch like it is for MSI RegistrySearch I suppose I could test this out myself but I just wanted to know if this is documented behavior and not likely to break in future. -Raj On Fri, Apr 5, 2013 at 8:28 AM, Rob Mensching wrote: > Sorry, my bad. I didn't realize you were talking about the > util:RegistrySearch. My answer was about the MSI based RegistrySearch. > Using util:RegistrySearch is explicit. If you say Win64='yes' then the > search is 64-bit and vice versa. You can ignore the fact that the Burn > engine is 32-bit. It matters none. > > > On Fri, Apr 5, 2013 at 6:59 AM, ptr wrote: > > > Thanks Rob.. I just wanted to clarify it because the documentation seems > > out of date. > > > > *RegistrySearch documentation says* > > > > Instructs the search to look in the 64-bit registry when the value is > > 'yes'. When the value is 'no', the search looks in the 32-bit registry. > The > > default value depends on the value of the Package/@Platform attribute: if > > the @Platform attribute value is 'x86', the default @Win64 attribute > value > > is 'no'; otherwise, the default value is 'yes'. > > > > *Util Extension RegistrySearch documentation says* > > Instructs the search to look in the 64-bit registry when the value is > > 'yes'. When the value is 'no', the search looks in the 32-bit registry. > The > > default value is 'no'. > > > > So it seems like even though the bootstrapper is always 32bit it matters > > what its build configuration. We have installers that only allow 32bit on > > 32bit OS and 64bit components on 64bit OS. I am making a boostrapper that > > has 32bit components as well as 64bit components as downloaded msis that > > have installcondition based on bitness of the OS. I was wondering if > > setting winb64 to yes is the right thing. It seems like it is. > > > > Thanks > > Raj > > > > > > > > > > > > On Fri, Apr 5, 2013 at 6:53 AM, Rob Mensching > > wrote: > > > > > The Win64 attribute defaults to 'yes' or 'no' based on the value you > pass > > > to the candle.exe -arch switch. If Win64 is 'no' it searches 32-bit. If > > it > > > is 'yes' it will search 64-bit on 64-bit machine and 32-bit on a 32-bit > > > machine (because there is no 64-bit). > > > > > > Bootstrapper is completely separate and is not affected by the MSI > build. > > > > > > > > > On Fri, Apr 5, 2013 at 5:09 AM, ptr wrote: > > > > > > > Util RegistrySearch has an attribute Winb64 that seems to be no by > > > default. > > > > If this is set to Yes, Would it mean it would look in the 32bit > > registry > > > > on 32bit OS and 64bit registry on 64bit OS ? > > > > > > > > The reason I am seeking some clarification is become some other > > > attributes > > > > like these seem to be have different default values for x64 vs x86 > > > > configurations. > > > > > > > > If you have a boostrapper project that has both x64 and x86 > > > configurations, > > > > Does it have any effect on the final exe. I mean on attribute default > > > > values somewhere ? > > > > > > > > > > > > Thanks > > > > Raj > > > > > > > > > > > > > > -- > > > > Minimize network downtime and maximize team effectiveness. > > > > Reduce network management and security costs.Learn how to hire > > > > the most talented Cisco Certified professionals. Visit the > > > > Employer Resources Portal > > > > http://www.cisco.com/web/learning/employer_resources/index.html > > > > ___ > > > > WiX-users mailing list > > > > WiX-users@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > > > > > > > > > > > -- > > > Minimize network downtime and maximize team effectiveness. > > > Reduce network management and security costs.Learn how to hire > > > the most talented Cisco Certified professionals. Visit the > > > Employer Resources Portal > > > http://www.cisco.com/web/learning/employer_resources/index.html > > > ___ > > > WiX-users mailing list > > > WiX-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > > -- > > Minimize network downtime and maximize team effectiveness. > > Reduce network management and security costs.Learn how to hire > > the most talented Cisco Certified professionals. Visit the > > Employer Resources Portal > > http://www.cisco.com/web/learning/employer_resources/index.html > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > -
Re: [WiX-users] Util RegistrySearch Element and Win64 attribute
I think that's reasonable. If you could test it out and file a bug saying, "This is what I discovered, it would be ideal if the documentation defined the expected behavior for util:RegistrySearch Win64." I'll get the right thing to happen on the other side. On Fri, Apr 5, 2013 at 7:40 AM, ptr wrote: > But what you said about > > if I set Win64='yes' > It will do 64bit search on 64bit OS > and on 32bit OS it will do 32bit search and not fail. > > is still true for Util:RegistrySearch like it is for MSI RegistrySearch > > I suppose I could test this out myself but I just wanted to know if this is > documented behavior and not likely to break in future. > > -Raj > > > > > > > > > On Fri, Apr 5, 2013 at 8:28 AM, Rob Mensching > wrote: > > > Sorry, my bad. I didn't realize you were talking about the > > util:RegistrySearch. My answer was about the MSI based RegistrySearch. > > Using util:RegistrySearch is explicit. If you say Win64='yes' then the > > search is 64-bit and vice versa. You can ignore the fact that the Burn > > engine is 32-bit. It matters none. > > > > > > On Fri, Apr 5, 2013 at 6:59 AM, ptr wrote: > > > > > Thanks Rob.. I just wanted to clarify it because the documentation > seems > > > out of date. > > > > > > *RegistrySearch documentation says* > > > > > > Instructs the search to look in the 64-bit registry when the value is > > > 'yes'. When the value is 'no', the search looks in the 32-bit registry. > > The > > > default value depends on the value of the Package/@Platform attribute: > if > > > the @Platform attribute value is 'x86', the default @Win64 attribute > > value > > > is 'no'; otherwise, the default value is 'yes'. > > > > > > *Util Extension RegistrySearch documentation says* > > > Instructs the search to look in the 64-bit registry when the value is > > > 'yes'. When the value is 'no', the search looks in the 32-bit registry. > > The > > > default value is 'no'. > > > > > > So it seems like even though the bootstrapper is always 32bit it > matters > > > what its build configuration. We have installers that only allow 32bit > on > > > 32bit OS and 64bit components on 64bit OS. I am making a boostrapper > that > > > has 32bit components as well as 64bit components as downloaded msis > that > > > have installcondition based on bitness of the OS. I was wondering if > > > setting winb64 to yes is the right thing. It seems like it is. > > > > > > Thanks > > > Raj > > > > > > > > > > > > > > > > > > On Fri, Apr 5, 2013 at 6:53 AM, Rob Mensching > > > wrote: > > > > > > > The Win64 attribute defaults to 'yes' or 'no' based on the value you > > pass > > > > to the candle.exe -arch switch. If Win64 is 'no' it searches 32-bit. > If > > > it > > > > is 'yes' it will search 64-bit on 64-bit machine and 32-bit on a > 32-bit > > > > machine (because there is no 64-bit). > > > > > > > > Bootstrapper is completely separate and is not affected by the MSI > > build. > > > > > > > > > > > > On Fri, Apr 5, 2013 at 5:09 AM, ptr wrote: > > > > > > > > > Util RegistrySearch has an attribute Winb64 that seems to be no by > > > > default. > > > > > If this is set to Yes, Would it mean it would look in the 32bit > > > registry > > > > > on 32bit OS and 64bit registry on 64bit OS ? > > > > > > > > > > The reason I am seeking some clarification is become some other > > > > attributes > > > > > like these seem to be have different default values for x64 vs x86 > > > > > configurations. > > > > > > > > > > If you have a boostrapper project that has both x64 and x86 > > > > configurations, > > > > > Does it have any effect on the final exe. I mean on attribute > default > > > > > values somewhere ? > > > > > > > > > > > > > > > Thanks > > > > > Raj > > > > > > > > > > > > > > > > > > > > -- > > > > > Minimize network downtime and maximize team effectiveness. > > > > > Reduce network management and security costs.Learn how to hire > > > > > the most talented Cisco Certified professionals. Visit the > > > > > Employer Resources Portal > > > > > http://www.cisco.com/web/learning/employer_resources/index.html > > > > > ___ > > > > > WiX-users mailing list > > > > > WiX-users@lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Minimize network downtime and maximize team effectiveness. > > > > Reduce network management and security costs.Learn how to hire > > > > the most talented Cisco Certified professionals. Visit the > > > > Employer Resources Portal > > > > http://www.cisco.com/web/learning/employer_resources/index.html > > > > ___ > > > > WiX-users mailing list > > > > WiX-users@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > >
Re: [WiX-users] How to use PostBuild event code to include configuration in msi name (eg MyInstaller Test.msi)
Also note that unless you change the default behavior, then '$(TargetName)' == '$(OutputName)' So, I would change the OutputName property to whatever name you need. -- Edwin On Fri, Apr 5, 2013 at 5:54 AM, Rob Mensching wrote: > Yeah, changing the TargetName should just be a matter of editing the > .wixproj to include another MSBuild property. This is really about MSBuild > though functionality, not the WiX toolset. > > > On Fri, Apr 5, 2013 at 4:54 AM, j2associates > wrote: > > > Hello Rob, > > > > Thanks for the reply. > > > > We have our Wix project in the same solution as the application and just > > create the msi when the solution is built by Visual Studio. We are not > > doing > > anything in Wix with the command line, everything is done via Visual > > Studio. > > > > I do not think it is possible to set the TargetName from within a wxs > file. > > > > Our solution also contains a web services project with different > endpoints > > depending upon the configuration being compiled. So if a particular build > > is > > going to be released to testing, we build twice, once for Test and once > for > > Lab and send both msi files to Test. Once it has passed Test, the Lab msi > > is > > sent to the Lab. This process ensures both msi files were created against > > the same application code base. > > > > Are we missing something obvious here? > > > > > > > > -- > > View this message in context: > > > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-use-PostBuild-event-code-to-include-configuration-in-msi-name-eg-MyInstaller-Test-msi-tp7584890p7584912.html > > Sent from the wix-users mailing list archive at Nabble.com. > > > > > > > -- > > Minimize network downtime and maximize team effectiveness. > > Reduce network management and security costs.Learn how to hire > > the most talented Cisco Certified professionals. Visit the > > Employer Resources Portal > > http://www.cisco.com/web/learning/employer_resources/index.html > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > -- > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > -- Edwin G. Castro -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to use PostBuild event code to include configuration in msi name (eg MyInstaller Test.msi)
Right, my bad. OutputName over TargetName not the other way around. On Fri, Apr 5, 2013 at 8:07 AM, Edwin Castro wrote: > Also note that unless you change the default behavior, then > > '$(TargetName)' == '$(OutputName)' > > So, I would change the OutputName property to whatever name you need. > > -- > Edwin > > > > On Fri, Apr 5, 2013 at 5:54 AM, Rob Mensching > wrote: > > > Yeah, changing the TargetName should just be a matter of editing the > > .wixproj to include another MSBuild property. This is really about > MSBuild > > though functionality, not the WiX toolset. > > > > > > On Fri, Apr 5, 2013 at 4:54 AM, j2associates > > wrote: > > > > > Hello Rob, > > > > > > Thanks for the reply. > > > > > > We have our Wix project in the same solution as the application and > just > > > create the msi when the solution is built by Visual Studio. We are not > > > doing > > > anything in Wix with the command line, everything is done via Visual > > > Studio. > > > > > > I do not think it is possible to set the TargetName from within a wxs > > file. > > > > > > Our solution also contains a web services project with different > > endpoints > > > depending upon the configuration being compiled. So if a particular > build > > > is > > > going to be released to testing, we build twice, once for Test and once > > for > > > Lab and send both msi files to Test. Once it has passed Test, the Lab > msi > > > is > > > sent to the Lab. This process ensures both msi files were created > against > > > the same application code base. > > > > > > Are we missing something obvious here? > > > > > > > > > > > > -- > > > View this message in context: > > > > > > http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/How-to-use-PostBuild-event-code-to-include-configuration-in-msi-name-eg-MyInstaller-Test-msi-tp7584890p7584912.html > > > Sent from the wix-users mailing list archive at Nabble.com. > > > > > > > > > > > > -- > > > Minimize network downtime and maximize team effectiveness. > > > Reduce network management and security costs.Learn how to hire > > > the most talented Cisco Certified professionals. Visit the > > > Employer Resources Portal > > > http://www.cisco.com/web/learning/employer_resources/index.html > > > ___ > > > WiX-users mailing list > > > WiX-users@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > > > > > > -- > > Minimize network downtime and maximize team effectiveness. > > Reduce network management and security costs.Learn how to hire > > the most talented Cisco Certified professionals. Visit the > > Employer Resources Portal > > http://www.cisco.com/web/learning/employer_resources/index.html > > ___ > > WiX-users mailing list > > WiX-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/wix-users > > > > > > -- > Edwin G. Castro > > -- > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/wix-users > > -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] msi complains about higher version when run through bootstrapper
hey all
I have a computer on which a msi installs and uninstall correctly. But
when done through the bootstrapper it complains that a higher version is
already installed.
The only thing is the bootstrapper is marked as version 4.1.95.8879 and the
msi is marked as version 4.1.8421. I am not sure if it matters.
This is the msi install log. Can somebody help me figure out why this fails
?
Thanks in advance
Raj
-
=== Verbose logging started: 4/5/2013 17:19:01 Build type: SHIP UNICODE
5.00.7601.00 Calling process:
D:\Anark\Core\WiX\CoreInstallers\bin\x64\Release\AnarkCoreWorkstationSetup_x64_4.1.95.8879.exe
===
MSI (c) (A4:60) [17:19:01:478]: Resetting cached policy values
MSI (c) (A4:60) [17:19:01:478]: Machine policy value 'Debug' is 0
MSI (c) (A4:60) [17:19:01:478]: *** RunEngine:
*** Product: C:\ProgramData\Package
Cache\{35699343-AFA4-7AB2-2995-A9D99B9D7DA8}v4.1.8421\ThirdPartyLibsx64.msi
*** Action:
*** CommandLine: **
MSI (c) (A4:60) [17:19:01:478]: Client-side and UI is none or basic:
Running entire install on the server.
MSI (c) (A4:60) [17:19:01:478]: Grabbed execution mutex.
MSI (c) (A4:60) [17:19:01:481]: Cloaking enabled.
MSI (c) (A4:60) [17:19:01:481]: Attempting to enable all disabled
privileges before calling Install on Server
MSI (c) (A4:60) [17:19:01:481]: Incrementing counter to disable shutdown.
Counter after increment: 0
MSI (s) (FC:30) [17:19:01:485]: Running installation inside multi-package
transaction C:\ProgramData\Package
Cache\{35699343-AFA4-7AB2-2995-A9D99B9D7DA8}v4.1.8421\ThirdPartyLibsx64.msi
MSI (s) (FC:30) [17:19:01:485]: Grabbed execution mutex.
MSI (s) (FC:F0) [17:19:01:486]: Resetting cached policy values
MSI (s) (FC:F0) [17:19:01:487]: Machine policy value 'Debug' is 0
MSI (s) (FC:F0) [17:19:01:487]: *** RunEngine:
*** Product: C:\ProgramData\Package
Cache\{35699343-AFA4-7AB2-2995-A9D99B9D7DA8}v4.1.8421\ThirdPartyLibsx64.msi
*** Action:
*** CommandLine: **
MSI (s) (FC:F0) [17:19:01:487]: Machine policy value 'DisableUserInstalls'
is 0
MSI (s) (FC:F0) [17:19:01:523]: SRSetRestorePoint skipped for this
transaction.
MSI (s) (FC:F0) [17:19:01:525]: File will have security applied from OpCode.
MSI (s) (FC:F0) [17:19:01:786]: SOFTWARE RESTRICTION POLICY: Verifying
package --> 'C:\ProgramData\Package
Cache\{35699343-AFA4-7AB2-2995-A9D99B9D7DA8}v4.1.8421\ThirdPartyLibsx64.msi'
against software restriction policy
MSI (s) (FC:F0) [17:19:01:786]: Note: 1: 2262 2: DigitalSignature 3:
-2147287038
MSI (s) (FC:F0) [17:19:01:786]: SOFTWARE RESTRICTION POLICY:
C:\ProgramData\Package
Cache\{35699343-AFA4-7AB2-2995-A9D99B9D7DA8}v4.1.8421\ThirdPartyLibsx64.msi
is not digitally signed
MSI (s) (FC:F0) [17:19:01:787]: SOFTWARE RESTRICTION POLICY:
C:\ProgramData\Package
Cache\{35699343-AFA4-7AB2-2995-A9D99B9D7DA8}v4.1.8421\ThirdPartyLibsx64.msi
is permitted to run at the 'unrestricted' authorization level.
MSI (s) (FC:F0) [17:19:01:787]: End dialog not enabled
MSI (s) (FC:F0) [17:19:01:787]: Original package ==> C:\ProgramData\Package
Cache\{35699343-AFA4-7AB2-2995-A9D99B9D7DA8}v4.1.8421\ThirdPartyLibsx64.msi
MSI (s) (FC:F0) [17:19:01:787]: Package we're running from ==>
C:\Windows\Installer\7ea385.msi
MSI (s) (FC:F0) [17:19:01:789]: APPCOMPAT: Compatibility mode property
overrides found.
MSI (s) (FC:F0) [17:19:01:790]: APPCOMPAT: looking for appcompat database
entry with ProductCode '{35699343-AFA4-7AB2-2995-A9D99B9D7DA8}'.
MSI (s) (FC:F0) [17:19:01:790]: APPCOMPAT: no matching ProductCode found in
database.
MSI (s) (FC:F0) [17:19:01:792]: MSCOREE not loaded loading copy from
system32
MSI (s) (FC:F0) [17:19:01:794]: Machine policy value 'TransformsSecure' is 0
MSI (s) (FC:F0) [17:19:01:794]: User policy value 'TransformsAtSource' is 0
MSI (s) (FC:F0) [17:19:01:795]: Machine policy value 'DisablePatch' is 0
MSI (s) (FC:F0) [17:19:01:795]: Machine policy value 'AllowLockdownPatch'
is 0
MSI (s) (FC:F0) [17:19:01:795]: Machine policy value 'DisableLUAPatching'
is 0
MSI (s) (FC:F0) [17:19:01:795]: Machine policy value
'DisableFlyWeightPatching' is 0
MSI (s) (FC:F0) [17:19:01:796]: APPCOMPAT: looking for appcompat database
entry with ProductCode '{35699343-AFA4-7AB2-2995-A9D99B9D7DA8}'.
MSI (s) (FC:F0) [17:19:01:796]: APPCOMPAT: no matching ProductCode found in
database.
MSI (s) (FC:F0) [17:19:01:796]: Transforms are not secure.
MSI (s) (FC:F0) [17:19:01:796]: PROPERTY CHANGE: Adding MsiLogFileLocation
property. Its value is
'C:\Users\RAJ~1.PAR\AppData\Local\Temp\Anark_Core_Workstation_4.1.95.8879_20130405171844_2_AnarkCommonThirdPartyPackageIdx64.log'.
MSI (s) (FC:F0) [17:19:01:796]: Command Line: ARPSYSTEMCOMPONENT=1
MSIFASTINSTALL=7 LIBSFOLDER=C:\Program Files\Anark\Libraries
REBOOT=ReallySuppress
CURRENTDIRECTORY=D:\Anark\Core\WiX\CoreInstallers\bin\x64\
[WiX-users] Please ignore Re: msi complains about higher version when run through bootstrapper
Please ignore this email. I somehow cut pasted the same upgrade code to two
different msi's in the bootstrapper
Thanks
Raj
On Fri, Apr 5, 2013 at 5:29 PM, ptr wrote:
> hey all
>
> I have a computer on which a msi installs and uninstall correctly. But
> when done through the bootstrapper it complains that a higher version is
> already installed.
>
> The only thing is the bootstrapper is marked as version 4.1.95.8879 and
> the msi is marked as version 4.1.8421. I am not sure if it matters.
>
> This is the msi install log. Can somebody help me figure out why this
> fails ?
>
> Thanks in advance
> Raj
>
>
>
> -
> === Verbose logging started: 4/5/2013 17:19:01 Build type: SHIP UNICODE
> 5.00.7601.00 Calling process:
> D:\Anark\Core\WiX\CoreInstallers\bin\x64\Release\AnarkCoreWorkstationSetup_x64_4.1.95.8879.exe
> ===
> MSI (c) (A4:60) [17:19:01:478]: Resetting cached policy values
> MSI (c) (A4:60) [17:19:01:478]: Machine policy value 'Debug' is 0
> MSI (c) (A4:60) [17:19:01:478]: *** RunEngine:
>*** Product: C:\ProgramData\Package
> Cache\{35699343-AFA4-7AB2-2995-A9D99B9D7DA8}v4.1.8421\ThirdPartyLibsx64.msi
>*** Action:
>*** CommandLine: **
> MSI (c) (A4:60) [17:19:01:478]: Client-side and UI is none or basic:
> Running entire install on the server.
> MSI (c) (A4:60) [17:19:01:478]: Grabbed execution mutex.
> MSI (c) (A4:60) [17:19:01:481]: Cloaking enabled.
> MSI (c) (A4:60) [17:19:01:481]: Attempting to enable all disabled
> privileges before calling Install on Server
> MSI (c) (A4:60) [17:19:01:481]: Incrementing counter to disable shutdown.
> Counter after increment: 0
> MSI (s) (FC:30) [17:19:01:485]: Running installation inside multi-package
> transaction C:\ProgramData\Package
> Cache\{35699343-AFA4-7AB2-2995-A9D99B9D7DA8}v4.1.8421\ThirdPartyLibsx64.msi
> MSI (s) (FC:30) [17:19:01:485]: Grabbed execution mutex.
> MSI (s) (FC:F0) [17:19:01:486]: Resetting cached policy values
> MSI (s) (FC:F0) [17:19:01:487]: Machine policy value 'Debug' is 0
> MSI (s) (FC:F0) [17:19:01:487]: *** RunEngine:
>*** Product: C:\ProgramData\Package
> Cache\{35699343-AFA4-7AB2-2995-A9D99B9D7DA8}v4.1.8421\ThirdPartyLibsx64.msi
>*** Action:
>*** CommandLine: **
> MSI (s) (FC:F0) [17:19:01:487]: Machine policy value 'DisableUserInstalls'
> is 0
> MSI (s) (FC:F0) [17:19:01:523]: SRSetRestorePoint skipped for this
> transaction.
> MSI (s) (FC:F0) [17:19:01:525]: File will have security applied from
> OpCode.
> MSI (s) (FC:F0) [17:19:01:786]: SOFTWARE RESTRICTION POLICY: Verifying
> package --> 'C:\ProgramData\Package
> Cache\{35699343-AFA4-7AB2-2995-A9D99B9D7DA8}v4.1.8421\ThirdPartyLibsx64.msi'
> against software restriction policy
> MSI (s) (FC:F0) [17:19:01:786]: Note: 1: 2262 2: DigitalSignature 3:
> -2147287038
> MSI (s) (FC:F0) [17:19:01:786]: SOFTWARE RESTRICTION POLICY:
> C:\ProgramData\Package
> Cache\{35699343-AFA4-7AB2-2995-A9D99B9D7DA8}v4.1.8421\ThirdPartyLibsx64.msi
> is not digitally signed
> MSI (s) (FC:F0) [17:19:01:787]: SOFTWARE RESTRICTION POLICY:
> C:\ProgramData\Package
> Cache\{35699343-AFA4-7AB2-2995-A9D99B9D7DA8}v4.1.8421\ThirdPartyLibsx64.msi
> is permitted to run at the 'unrestricted' authorization level.
> MSI (s) (FC:F0) [17:19:01:787]: End dialog not enabled
> MSI (s) (FC:F0) [17:19:01:787]: Original package ==>
> C:\ProgramData\Package
> Cache\{35699343-AFA4-7AB2-2995-A9D99B9D7DA8}v4.1.8421\ThirdPartyLibsx64.msi
> MSI (s) (FC:F0) [17:19:01:787]: Package we're running from ==>
> C:\Windows\Installer\7ea385.msi
> MSI (s) (FC:F0) [17:19:01:789]: APPCOMPAT: Compatibility mode property
> overrides found.
> MSI (s) (FC:F0) [17:19:01:790]: APPCOMPAT: looking for appcompat database
> entry with ProductCode '{35699343-AFA4-7AB2-2995-A9D99B9D7DA8}'.
> MSI (s) (FC:F0) [17:19:01:790]: APPCOMPAT: no matching ProductCode found
> in database.
> MSI (s) (FC:F0) [17:19:01:792]: MSCOREE not loaded loading copy from
> system32
> MSI (s) (FC:F0) [17:19:01:794]: Machine policy value 'TransformsSecure' is
> 0
> MSI (s) (FC:F0) [17:19:01:794]: User policy value 'TransformsAtSource' is 0
> MSI (s) (FC:F0) [17:19:01:795]: Machine policy value 'DisablePatch' is 0
> MSI (s) (FC:F0) [17:19:01:795]: Machine policy value 'AllowLockdownPatch'
> is 0
> MSI (s) (FC:F0) [17:19:01:795]: Machine policy value 'DisableLUAPatching'
> is 0
> MSI (s) (FC:F0) [17:19:01:795]: Machine policy value
> 'DisableFlyWeightPatching' is 0
> MSI (s) (FC:F0) [17:19:01:796]: APPCOMPAT: looking for appcompat database
> entry with ProductCode '{35699343-AFA4-7AB2-2995-A9D99B9D7DA8}'.
> MSI (s) (FC:F0) [17:19:01:796]: APPCOMPAT: no matching ProductCode found
> in database.
> MSI (s) (FC:F0) [17:19:01:796]: Transforms are not secure.
> MSI (s) (FC:F0) [17:19:01:796]: PROPERTY CHANGE: Adding MsiLogFileLocation
>
Re: [WiX-users] Bundle Version and patching
Hi Christian, I have run into exactly the same situation (the patching successfully completed, but the ARP entry not being updated). Did you ever find a solution to the problem? Best regards, Mattias -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Bundle-Version-and-patching-tp7579655p7584932.html Sent from the wix-users mailing list archive at Nabble.com. -- Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
