Re: [WiX-users] Multiple Instance installations from wix BA application
1 Probably not only for transforms but also for other cases in general. For example, run bundle with multiple(with different product codes) msi's more than once to remove selected msi's from machine. Can we do it now and keep a link in PF? 2 Yeah. I just wanted to ask, why we don't have this model in BA? I think it is an easy feature and people won't need to write some classes to parse and store these values. 3 Ok. 01.08.2014, 08:49, Rob Mensching r...@firegiant.com: 1. Sounds like you want support instance transforms. There is a feature request for that. 2. The BA is provided the BootstrapperApplicationData.xml with lots of information. If more information is required, we could probably add it. 3. You should be able to affect the requested state for the packages from your BA via the PlanPackageBegin. That is the design. If it isn't working it'd be considered a bug. -Original Message- From: serkbugs [mailto:serkb...@yandex.ru] Sent: Thursday, July 31, 2014 16:01 To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Multiple Instance installations from wix BA application I'm newbie in installers and I can't say that all things I wanted to have, could be also helpful for other people. For now I can remember only a few things: For instance, a way to say to the bundle to stay in Programs and Features( PF) (probably it is possible now but I didnt find any info about it). I wanted to have possibility to run uninstall from PF for standard installation and for installations with TRANSFORMS=:Ixx. I mean I wanted to have a way to manage this process by myself. I can have a counter for installed instances and remove a bundle link from PF with the last uninstalled instance . Also, it would be great to have a little bit more info about bundle and which packages/features it contains.To get such info I used approach from this blog http://bit.ly/1s7VPPZ (Part 3). Sometimes I wanted to configure install/update/remove process by myself throught setting RequstedState in OnPlanPackageBegin event but it didn't affect Execute(parameter from logs) and it didn't run my msi. I want some methods in Engine/BA to force some things to happen. 01.08.2014, 02:13, Rob Mensching r...@firegiant.com: What kind of control? -Original Message- From: serkbugs [mailto:serkb...@yandex.ru] Sent: Thursday, July 31, 2014 14:49 To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Multiple Instance installations from wix BA application Thanx for quick answer. I will try to do multiinstances in a different way(not through installer). One comment from my side after a few days trying to start it work. I think we need a little bit more control of installing process in BA application. If I had more control over package detect/apply/etc. proces, I could fix all problems I had. 31.07.2014, 21:28, Rob Mensching r...@firegiant.com: There is a feature request open for Burn to support multiple instances. -Original Message- From: serkbugs [mailto:serkb...@yandex.ru] Sent: Thursday, July 31, 2014 01:51 To: wix-users@lists.sourceforge.net Cc: Sergey Kozhemyachenko Subject: [WiX-users] Multiple Instance installations from wix BA application Hi, Our customer wants to install multiple instances of windows service per each service(like SQL server installation with multiple instances). I was trying to build a prototype using custom BA application(Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperApplication). I've read a lot of topics around InstanceTransforms in msi and it looks like I can start it work from msi with msiexec /i MultiInstance.msi MSINEWINSTANCE=1 TRANSFORMS=:I01 but I cannot understand how to run it properly from BA. Here is some pieces from my prototype. Msi(please don't pay attention to extra actions and properties): Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util=http://schemas.microsoft.com/wix/UtilExtension; Product Id=$(var.I00) Name=$(var.ProductName32) Language=1033 Version=$(var.CurrentVersion) Manufacturer=Me inc UpgradeCode=$(var.UpgradeGuid) Package InstallerVersion=200 Compressed=yes InstallScope=perMachine / MajorUpgrade AllowDowngrades=no AllowSameVersionUpgrades=yes DowngradeErrorMessage=You can't downgrade this application Schedule=afterInstallExecute MigrateFeatures=yes/ MediaTemplate EmbedCab=yes / Feature Id=ProductFeature Title=SetupProjectTest Level=1 ComponentGroupRef Id=ProductComponents / /Feature Property Id=PATHTOCOPY Secure=yes/Property Property Id=PATHTOCOPYTO Secure=yes/Property Binary Id='CustomAction' SourceFile=$(var.TestCustomAction.TargetDir)TestCustomAction.CA.dll / Property
[WiX-users] Undefined preprocessor variable '$(var.SolutionName)'.
Hi * My build does not find the preprocessor variable var.SolutionName Mobility.Platform.Windows.msm\Common\Module.wxi (4): Undefined preprocessor variable '$(var.SolutionName)'. Is it obsolete? Which solution-based variables are working? Thank you very much and regards Ferdi This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] MinorUpdateTargetRTM and Uninstall
I am experimenting with doing incremental minor patches followed by a rollup minor patch. I am seeing an interesting behavior that I have a feeling is expected but I would like to confirm. So for example given the following patch sequence: 1.0.0 --1.0.1 1.0.2 ---1.0.3 --1.0.4 Patch 1.0.4 is a rollup and built against RTM. The Patch element has the 'MinorUpdateTargetRTM' attribute set. Now as a test I install all the patches up to 1.0.3 and then install 1.0.4. This all works fine as expected. However if I uninstall 1.0.4 instead of reverting to 1.0.0 I end up at 1.0.3. I have tried both with and without 'Supersede' set on the PatchFamily and the end result is the same. I expected when the MinorUpdateTargetRTM patch was installed it would forget about all the previous patches that had been installed. However this seems to not be the case. Is what I'm seeing the expected behavior? Thanks, Thomas -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Please remove me from the list
Hi Please remove me from the list -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn/bundle EXE - setting property?
Hi Phil, I am trying to set a variable from a registry key within burn to be used in a exepackage but can't seem to be able to do it, will what you mentioned work for me? and if possible could you explain exactly on how to do that? thank you -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-bundle-EXE-setting-property-tp7595178p7596174.html Sent from the wix-users mailing list archive at Nabble.com. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installer size doubles up if signed
The checksum of the cabs before signing are the same but after signing they become different. Could this be because we are including the timestamps in the signature using a timestamp server and as they get signed at slightly different times(in the build process) the timestamps and as a result signatures differ? On Aug 1, 2014 10:23 AM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: If you build your 32 bit and 64 bit MSI's, and then compare the checksums of the cabs, are they different? -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: Thursday, July 31, 2014 11:13 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Installer size doubles up if signed I sign all of my MSI's and Burn bundles. I only see a few K difference, so something is seriously wrong. How do these MSI's look in Orca? -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.(r) Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com From: Ashish Agarwal [ash...@mangoapps.com] Sent: Thursday, July 31, 2014 10:14 PM To: General discussion about the WiX toolset. Subject: [WiX-users] Installer size doubles up if signed Hi, We are in the process of migrating to Wix from the old Visual Studio installer and are hitting an issue. We use a single setup project that runs once in 32 bit mode and once in 64 bit to generate two MSI files. These are then packaged together using Burn. When the external cab files are not signed (but the MSIs and final setup exe is) the final exe generated by the bootstrapper is ~50MB. However, if we decide to sign the external cabs as well before creating the bundle the final setup size becomes 100MB. We would ideally like to sign the Cab files. Any pointers on what can be done? -- -- At MangoApps http://www.mangoapps.com we specialize in social collaboration platforms for mid-size companies (100-5,000 users). You can find more information, including 5 case studies and lots of current customer reviews here: MangoApps Dossier http://download.mangoapps.com/documents/MangoAppsDossier_Hires.pdf -- -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -- At MangoApps http://www.mangoapps.com we specialize in social collaboration platforms for mid-size companies (100-5,000 users). You can find more information, including 5 case studies and lots of current customer reviews here: MangoApps Dossier http://download.mangoapps.com/documents/MangoAppsDossier_Hires.pdf -- -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the
Re: [WiX-users] Installer size doubles up if signed
Yes, and because of this burn is including the appropriate CABS. Are you using the existing WiX build events to sign the MSI and CABS? I do believe the events are timed such that MSBuild isn't going to trigger a rebuild if CAB caching is enabled for the project. -Original Message- From: Ashish Agarwal [mailto:ash...@mangoapps.com] Sent: Friday, August 01, 2014 10:07 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Installer size doubles up if signed The checksum of the cabs before signing are the same but after signing they become different. Could this be because we are including the timestamps in the signature using a timestamp server and as they get signed at slightly different times(in the build process) the timestamps and as a result signatures differ? On Aug 1, 2014 10:23 AM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: If you build your 32 bit and 64 bit MSI's, and then compare the checksums of the cabs, are they different? -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: Thursday, July 31, 2014 11:13 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Installer size doubles up if signed I sign all of my MSI's and Burn bundles. I only see a few K difference, so something is seriously wrong. How do these MSI's look in Orca? -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.(r) Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com From: Ashish Agarwal [ash...@mangoapps.com] Sent: Thursday, July 31, 2014 10:14 PM To: General discussion about the WiX toolset. Subject: [WiX-users] Installer size doubles up if signed Hi, We are in the process of migrating to Wix from the old Visual Studio installer and are hitting an issue. We use a single setup project that runs once in 32 bit mode and once in 64 bit to generate two MSI files. These are then packaged together using Burn. When the external cab files are not signed (but the MSIs and final setup exe is) the final exe generated by the bootstrapper is ~50MB. However, if we decide to sign the external cabs as well before creating the bundle the final setup size becomes 100MB. We would ideally like to sign the Cab files. Any pointers on what can be done? -- -- At MangoApps http://www.mangoapps.com we specialize in social collaboration platforms for mid-size companies (100-5,000 users). You can find more information, including 5 case studies and lots of current customer reviews here: MangoApps Dossier http://download.mangoapps.com/documents/MangoAppsDossier_Hires.pdf -- -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- -- At MangoApps http://www.mangoapps.com we specialize in
Re: [WiX-users] Undefined preprocessor variable '$(var.SolutionName)'.
Are you building a solution? Solution variables are only available when building a .sln. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: ferdi.oeztu...@accenture.com [mailto:ferdi.oeztu...@accenture.com] Sent: Friday, August 1, 2014 3:54 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Undefined preprocessor variable '$(var.SolutionName)'. Hi * My build does not find the preprocessor variable var.SolutionName Mobility.Platform.Windows.msm\Common\Module.wxi (4): Undefined preprocessor variable '$(var.SolutionName)'. Is it obsolete? Which solution-based variables are working? Thank you very much and regards Ferdi This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installer size doubles up if signed
I use the following in the setup project (this ofcourse happens once for x64 and after that for x86) Target Name=SignCabs Exec Command='Signtool.exe sign /i digi /t http://timestamp.digicert.com; %(SignCabs.FullPath)' / /Target Target Name=SignMsi Exec Command=quot;signtool.exequot; sign /i quot;digiquot; /t quot;http://timestamp.digicert.comquot; quot;%(SignMsi.FullPath)quot; / /Target and the following in the bootstrapper project Target Name=SignBundleEngine Exec Command=quot;signtool.exequot; sign /i quot;digiquot; /t quot;http://timestamp.digicert.comquot; quot;@(SignBundleEngine)quot; / /Target Target Name=SignBundle Exec Command=quot;signtool.exequot; sign /i quot;digiquot; /t quot;http://timestamp.digicert.comquot; quot;@(SignBundle)quot; / /Target Perhaps I would need to find a way to sign all the cab files together with a single signtool command. That would take care of the timestamp issue? On Fri, Aug 1, 2014 at 9:12 PM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: Yes, and because of this burn is including the appropriate CABS. Are you using the existing WiX build events to sign the MSI and CABS? I do believe the events are timed such that MSBuild isn't going to trigger a rebuild if CAB caching is enabled for the project. -Original Message- From: Ashish Agarwal [mailto:ash...@mangoapps.com] Sent: Friday, August 01, 2014 10:07 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Installer size doubles up if signed The checksum of the cabs before signing are the same but after signing they become different. Could this be because we are including the timestamps in the signature using a timestamp server and as they get signed at slightly different times(in the build process) the timestamps and as a result signatures differ? On Aug 1, 2014 10:23 AM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: If you build your 32 bit and 64 bit MSI's, and then compare the checksums of the cabs, are they different? -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: Thursday, July 31, 2014 11:13 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Installer size doubles up if signed I sign all of my MSI's and Burn bundles. I only see a few K difference, so something is seriously wrong. How do these MSI's look in Orca? -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.(r) Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com From: Ashish Agarwal [ash...@mangoapps.com] Sent: Thursday, July 31, 2014 10:14 PM To: General discussion about the WiX toolset. Subject: [WiX-users] Installer size doubles up if signed Hi, We are in the process of migrating to Wix from the old Visual Studio installer and are hitting an issue. We use a single setup project that runs once in 32 bit mode and once in 64 bit to generate two MSI files. These are then packaged together using Burn. When the external cab files are not signed (but the MSIs and final setup exe is) the final exe generated by the bootstrapper is ~50MB. However, if we decide to sign the external cabs as well before creating the bundle the final setup size becomes 100MB. We would ideally like to sign the Cab files. Any pointers on what can be done? -- -- At MangoApps http://www.mangoapps.com we specialize in social collaboration platforms for mid-size companies (100-5,000 users). You can find more information, including 5 case studies and lots of current customer reviews here: MangoApps Dossier http://download.mangoapps.com/documents/MangoAppsDossier_Hires.pdf -- -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies.
Re: [WiX-users] Installer size doubles up if signed
Are you including different files between the two builds? I would ensure the common files are in one CAB and anything that is unique to x86 vs x64 in their own CABS. -Original Message- From: Ashish Agarwal [mailto:ash...@mangoapps.com] Sent: Friday, August 01, 2014 10:58 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Installer size doubles up if signed I use the following in the setup project (this ofcourse happens once for x64 and after that for x86) Target Name=SignCabs Exec Command='Signtool.exe sign /i digi /t http://timestamp.digicert.com; %(SignCabs.FullPath)' / /Target Target Name=SignMsi Exec Command=quot;signtool.exequot; sign /i quot;digiquot; /t quot;http://timestamp.digicert.comquot; quot;%(SignMsi.FullPath)quot; / /Target and the following in the bootstrapper project Target Name=SignBundleEngine Exec Command=quot;signtool.exequot; sign /i quot;digiquot; /t quot;http://timestamp.digicert.comquot; quot;@(SignBundleEngine)quot; / /Target Target Name=SignBundle Exec Command=quot;signtool.exequot; sign /i quot;digiquot; /t quot;http://timestamp.digicert.comquot; quot;@(SignBundle)quot; / /Target Perhaps I would need to find a way to sign all the cab files together with a single signtool command. That would take care of the timestamp issue? On Fri, Aug 1, 2014 at 9:12 PM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: Yes, and because of this burn is including the appropriate CABS. Are you using the existing WiX build events to sign the MSI and CABS? I do believe the events are timed such that MSBuild isn't going to trigger a rebuild if CAB caching is enabled for the project. -Original Message- From: Ashish Agarwal [mailto:ash...@mangoapps.com] Sent: Friday, August 01, 2014 10:07 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Installer size doubles up if signed The checksum of the cabs before signing are the same but after signing they become different. Could this be because we are including the timestamps in the signature using a timestamp server and as they get signed at slightly different times(in the build process) the timestamps and as a result signatures differ? On Aug 1, 2014 10:23 AM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: If you build your 32 bit and 64 bit MSI's, and then compare the checksums of the cabs, are they different? -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: Thursday, July 31, 2014 11:13 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Installer size doubles up if signed I sign all of my MSI's and Burn bundles. I only see a few K difference, so something is seriously wrong. How do these MSI's look in Orca? -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.(r) Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com From: Ashish Agarwal [ash...@mangoapps.com] Sent: Thursday, July 31, 2014 10:14 PM To: General discussion about the WiX toolset. Subject: [WiX-users] Installer size doubles up if signed Hi, We are in the process of migrating to Wix from the old Visual Studio installer and are hitting an issue. We use a single setup project that runs once in 32 bit mode and once in 64 bit to generate two MSI files. These are then packaged together using Burn. When the external cab files are not signed (but the MSIs and final setup exe is) the final exe generated by the bootstrapper is ~50MB. However, if we decide to sign the external cabs as well before creating the bundle the final setup size becomes 100MB. We would ideally like to sign the Cab files. Any pointers on what can be done? -- -- At MangoApps http://www.mangoapps.com we specialize in social collaboration platforms for mid-size companies (100-5,000 users). You can find more information, including 5 case studies and lots of current customer reviews here: MangoApps Dossier http://download.mangoapps.com/documents/MangoAppsDossier_Hires.pdf -- -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it
Re: [WiX-users] Multiple Instance installations from wix BA application
1. The packages a bundle manages must be listed in the Chain of the Bundle element. A bundle is an identity that manages a collection of packages. It's not an arbitrary scripting engine to add and remove packages it doesn't know anything about from the machine. But if you are asking if bundle can change the state of packages in its Chain and stay in Programs/Features? Yes. 2. Because no one has enhanced the BA classes to read the file and proffer nice classes for it? ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: serkbugs [mailto:serkb...@yandex.ru] Sent: Friday, August 1, 2014 1:52 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Multiple Instance installations from wix BA application 1 Probably not only for transforms but also for other cases in general. For example, run bundle with multiple(with different product codes) msi's more than once to remove selected msi's from machine. Can we do it now and keep a link in PF? 2 Yeah. I just wanted to ask, why we don't have this model in BA? I think it is an easy feature and people won't need to write some classes to parse and store these values. 3 Ok. 01.08.2014, 08:49, Rob Mensching r...@firegiant.com: 1. Sounds like you want support instance transforms. There is a feature request for that. 2. The BA is provided the BootstrapperApplicationData.xml with lots of information. If more information is required, we could probably add it. 3. You should be able to affect the requested state for the packages from your BA via the PlanPackageBegin. That is the design. If it isn't working it'd be considered a bug. -Original Message- From: serkbugs [mailto:serkb...@yandex.ru] Sent: Thursday, July 31, 2014 16:01 To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Multiple Instance installations from wix BA application I'm newbie in installers and I can't say that all things I wanted to have, could be also helpful for other people. For now I can remember only a few things: For instance, a way to say to the bundle to stay in Programs and Features( PF) (probably it is possible now but I didnt find any info about it). I wanted to have possibility to run uninstall from PF for standard installation and for installations with TRANSFORMS=:Ixx. I mean I wanted to have a way to manage this process by myself. I can have a counter for installed instances and remove a bundle link from PF with the last uninstalled instance . Also, it would be great to have a little bit more info about bundle and which packages/features it contains.To get such info I used approach from this blog http://bit.ly/1s7VPPZ (Part 3). Sometimes I wanted to configure install/update/remove process by myself throught setting RequstedState in OnPlanPackageBegin event but it didn't affect Execute(parameter from logs) and it didn't run my msi. I want some methods in Engine/BA to force some things to happen. 01.08.2014, 02:13, Rob Mensching r...@firegiant.com: What kind of control? -Original Message- From: serkbugs [mailto:serkb...@yandex.ru] Sent: Thursday, July 31, 2014 14:49 To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Multiple Instance installations from wix BA application Thanx for quick answer. I will try to do multiinstances in a different way(not through installer). One comment from my side after a few days trying to start it work. I think we need a little bit more control of installing process in BA application. If I had more control over package detect/apply/etc. proces, I could fix all problems I had. 31.07.2014, 21:28, Rob Mensching r...@firegiant.com: There is a feature request open for Burn to support multiple instances. -Original Message- From: serkbugs [mailto:serkb...@yandex.ru] Sent: Thursday, July 31, 2014 01:51 To: wix-users@lists.sourceforge.net Cc: Sergey Kozhemyachenko Subject: [WiX-users] Multiple Instance installations from wix BA application Hi, Our customer wants to install multiple instances of windows service per each service(like SQL server installation with multiple instances). I was trying to build a prototype using custom BA application(Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperApplication). I've read a lot of topics around InstanceTransforms in msi and it looks like I can start it work from msi with msiexec /i MultiInstance.msi MSINEWINSTANCE=1 TRANSFORMS=:I01 but I cannot understand how to run it properly from BA. Here is some pieces from my prototype. Msi(please don't pay attention to extra actions and properties): Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util=http://schemas.microsoft.com/wix/UtilExtension; Product Id=$(var.I00)
Re: [WiX-users] Multiple Instance installations from wix BA application
Thanx Jacob for the hint about multiple msi's with only one cab. I tried this approach today and it works fine. After a few days of googling the solution I understand that it wasn't good idea to use transformations :( 31.07.2014, 22:43, Hoover, Jacob jacob.hoo...@greenheck.com: Instances are ugly... And to do them right would be very difficult. There aren't many restrictions to what a transform can do, so all the assumptions that are made at compile time of the bundle would have to be re-evaluated. My preference would be to have multiple predefined MSI's, and use a single external CAB that's common among all of them. -Original Message- From: Wesley Manning [mailto:wmann...@dynagen.ca] Sent: Thursday, July 31, 2014 12:50 PM To: 'General discussion about the WiX toolset.' Cc: 'Sergey Kozhemyachenko' Subject: Re: [WiX-users] Multiple Instance installations from wix BA application I think you're the third or fourth person to ask on this mailing list in the last year. It's not supported. There was a discussion on this mailing list some time ago if I recall. -Original Message- From: serkbugs [mailto:serkb...@yandex.ru] Sent: July-31-14 5:51 AM To: wix-users@lists.sourceforge.net Cc: Sergey Kozhemyachenko Subject: [WiX-users] Multiple Instance installations from wix BA application Hi, Our customer wants to install multiple instances of windows service per each service(like SQL server installation with multiple instances). I was trying to build a prototype using custom BA application(Microsoft.Tools.WindowsInstallerXml.Bootstrapper.BootstrapperApp lication). I've read a lot of topics around InstanceTransforms in msi and it looks like I can start it work from msi with msiexec /i MultiInstance.msi MSINEWINSTANCE=1 TRANSFORMS=:I01 but I cannot understand how to run it properly from BA. Here is some pieces from my prototype. Msi(please don't pay attention to extra actions and properties): Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util=http://schemas.microsoft.com/wix/UtilExtension; Product Id=$(var.I00) Name=$(var.ProductName32) Language=1033 Version=$(var.CurrentVersion) Manufacturer=Me inc UpgradeCode=$(var.UpgradeGuid) Package InstallerVersion=200 Compressed=yes InstallScope=perMachine / MajorUpgrade AllowDowngrades=no AllowSameVersionUpgrades=yes DowngradeErrorMessage=You can't downgrade this application Schedule=afterInstallExecute MigrateFeatures=yes/ MediaTemplate EmbedCab=yes / Feature Id=ProductFeature Title=SetupProjectTest Level=1 ComponentGroupRef Id=ProductComponents / /Feature Property Id=PATHTOCOPY Secure=yes/Property Property Id=PATHTOCOPYTO Secure=yes/Property Binary Id='CustomAction' SourceFile=$(var.TestCustomAction.TargetDir)TestCustomAction.CA.dll / Property Id=PREVIOUSVERSIONSINSTALLED Secure=yes / Property Id='REINSTALLMODE' Value='amus'/ Property Id='ServiceName' Value='Test Service Name 2'/ Property Id='INSTANCEID' Value='I01' RegistrySearch Id=InstanceIdSearch Root=HKLM Key=Software\[Manufacturer]\[ProductCode]\$(var.ProductName32) Name=InstanceId Type=raw / /Property InstanceTransforms Property='INSTANCEID' Instance Id='I01' ProductCode='$(var.I01)' ProductName='I01'/ Instance Id='I02' ProductCode='$(var.I02)' ProductName='I02'/ Instance Id='I03' ProductCode='$(var.I03)' ProductName='I03'/ /InstanceTransforms /Product Bundle: Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util=http://schemas.microsoft.com/wix/UtilExtension; xmlns:bal=http://schemas.microsoft.com/wix/BalExtension; Bundle Name=$(var.ProductName) Version=$(var.CurrentVersion) Manufacturer=$(var.Manufacturer) UpgradeCode=$(var.UpgradeGuid) BootstrapperApplicationRef Id=ManagedBootstrapperApplicationHost Payload SourceFile=$(var.TestBootstrapperApplication.TargetDir)BootstrapperCore.con fig/ Payload SourceFile=$(var.TestBootstrapperApplication.TargetDir)TestBootstrapperAppl ication.dll/ Payload SourceFile=$(var.TestBootstrapperApplication.TargetDir)GalaSoft.MvvmLight.W PF4.dll/ Payload SourceFile=c:\Program Files (x86)\WiX Toolset v3.7\SDK\Microsoft.Deployment.WindowsInstaller.dll/ /BootstrapperApplicationRef Variable Name=DIR_EXISTS Value=NO Persisted=yes Type=string / Variable Name=PATHTOAPP Value=c:\program files (x86)\SetupProjectTest\ Persisted=yes Type=string / Chain PackageGroupRef Id=NetFx40Web / PackageGroupRef Id=pkgMsi/ /Chain /Bundle /Wix another bundle file: Fragment .. Variable Name='TRANSFORMS' bal:Overridable=yes/ Variable Name='MSINEWINSTANCE' bal:Overridable=yes/ .. PackageGroup
Re: [WiX-users] Burn/bundle EXE - setting property?
Did you try to use util:RegistrySearch for that issue? -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-bundle-EXE-setting-property-tp7595178p7596182.html Sent from the wix-users mailing list archive at Nabble.com. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Passing Variables from C# custom BA to WIX
Ok, I ran the debugger and to my surprise, this executes after U click the InstallA button. I was thought this would run before any buttons were clicked. So, in trying to better understand how passing parameters work, what command can I use to pass variables from my wpf application to my WIX script? Is there an example of syntax structure between C# and WIX? I would like add to my MsiPackage (in WIX) the element InstallCondition and pass a parameter to it that will either install or not install the package. Thanks Again. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Passing-Variables-from-C-custom-BA-to-WIX-tp7596113p7596183.html Sent from the wix-users mailing list archive at Nabble.com. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Burn/bundle EXE - setting property?
A search of the wix source gives this example: util:RegistrySearch Root='HKLM' Key='SOFTWARE\Microsoft\VisualStudio\12.0' Value='InstallDir' Variable='VS2013InstallFolder' / . InstallCondition='VS2013InstallFolder OR VS2013WDExpressInstalled' If for some reason the above approach is not useful,then: In the Bindle declare a variable: (also from the wix source, but make it 'Overrideable='yes') Variable Name='InstallFolder' Type='string' Value='[ProgramFilesFolder]WiX Toolset v$(var.WixMajorMinor)' / In your BA's OnDetectComplete handler, or at some later point, read the registry key and use the Engine function to set the value to your variable. If using C++ look at src\burn\Samples\bafunctions. If doing managed code look at src\Setup\WixBA. (I am not sure if it specifically does this but you can see how to call engine functions. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-bundle-EXE-setting-property-tp7595178p7596184.html Sent from the wix-users mailing list archive at Nabble.com. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Unbinder.Unbind error
A while ago I built some stuff to investigate properties of a burn bundle (EXE) just in case they got lost when we built them, and also to harvest from others (in case we have some bundles not built by us). As per the list's recommendations, I added a reference to wix.dll and kept winterop.dll near by. The POC code looks like (fileName as a parameter from elsewhere) Dim b As New Microsoft.Tools.WindowsInstallerXml.Unbinder Dim out As Microsoft.Tools.WindowsInstallerXml.Output = b.Unbind(fileName, Microsoft.Tools.WindowsInstallerXml.OutputType.Bundle, c:\scratch\) For a while, this worked; some directories of XML and such were created I was able to read from. Now something (not this part of the code, since I haven't touched it) has changed and I get : An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B) Stack trace: at Microsoft.Tools.WindowsInstallerXml.Cab.Interop.NativeMethods.ExtractCabBegin() at Microsoft.Tools.WindowsInstallerXml.Cab.WixExtractCab..ctor() at Microsoft.Tools.WindowsInstallerXml.BurnReader.ExtractUXContainer(String outputDirectory, String tempDirectory) at Microsoft.Tools.WindowsInstallerXml.Unbinder.UnbindBundle(String bundleFile, String exportBasePath) at Microsoft.Tools.WindowsInstallerXml.Unbinder.Unbind(String file, OutputType outputType, String exportBasePath) at InstallerBuilder.PackageRepresentation..ctor(String fileName, String notesText, String whoBy) in C:\Users\dougkei\Downloads\DEV\ToolBox3\InstallerBuilder-branch\DeploymentManagement\Business Classes\PackageRepresentation.vb:line 169 C:\Users\dougkei\Downloads\DEV\ToolBox3\InstallerBuilder-branch\DeploymentManagement\Business Classes\PackageRepresentation.vb:line 169 This exception occurs with every bundle I've tried, including one that I just built to make sure it wasn't somehow wrong previously. Any idea what could be going wrong here? I have moved recently to Windows 7 x64, if that matters somehow. Keith Douglas Programmer Analyst | Programmeur analyste Questionnaire Development Services - CAI Social | Services de développement de questionnaires - IAO Social Jean Talon Building | Immeuble Jean-Talon / Floor | Étage 4 A-3 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-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Installer size doubles up if signed
Yeah. I have two cab files. Majority of the components are common so the first cab file is a big one (48mb) where as the unique components are all in cab 2. This is the reason why when the cabs are not signed the bundled package correctly detects and treats it as a common cab between two MSIs. I will be trying to see if writing pre build events in the bootstrapper project to sign the cabs (together in a single signtool command) and the MSI before the bundle gets created solves my issue. Will post my findings here. On Aug 1, 2014 9:36 PM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: Are you including different files between the two builds? I would ensure the common files are in one CAB and anything that is unique to x86 vs x64 in their own CABS. -Original Message- From: Ashish Agarwal [mailto:ash...@mangoapps.com] Sent: Friday, August 01, 2014 10:58 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Installer size doubles up if signed I use the following in the setup project (this ofcourse happens once for x64 and after that for x86) Target Name=SignCabs Exec Command='Signtool.exe sign /i digi /t http://timestamp.digicert.com; %(SignCabs.FullPath)' / /Target Target Name=SignMsi Exec Command=quot;signtool.exequot; sign /i quot;digiquot; /t quot;http://timestamp.digicert.comquot; quot;%(SignMsi.FullPath)quot; / /Target and the following in the bootstrapper project Target Name=SignBundleEngine Exec Command=quot;signtool.exequot; sign /i quot;digiquot; /t quot;http://timestamp.digicert.comquot; quot;@(SignBundleEngine)quot; / /Target Target Name=SignBundle Exec Command=quot;signtool.exequot; sign /i quot;digiquot; /t quot;http://timestamp.digicert.comquot; quot;@(SignBundle)quot; / /Target Perhaps I would need to find a way to sign all the cab files together with a single signtool command. That would take care of the timestamp issue? On Fri, Aug 1, 2014 at 9:12 PM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: Yes, and because of this burn is including the appropriate CABS. Are you using the existing WiX build events to sign the MSI and CABS? I do believe the events are timed such that MSBuild isn't going to trigger a rebuild if CAB caching is enabled for the project. -Original Message- From: Ashish Agarwal [mailto:ash...@mangoapps.com] Sent: Friday, August 01, 2014 10:07 AM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Installer size doubles up if signed The checksum of the cabs before signing are the same but after signing they become different. Could this be because we are including the timestamps in the signature using a timestamp server and as they get signed at slightly different times(in the build process) the timestamps and as a result signatures differ? On Aug 1, 2014 10:23 AM, Hoover, Jacob jacob.hoo...@greenheck.com wrote: If you build your 32 bit and 64 bit MSI's, and then compare the checksums of the cabs, are they different? -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: Thursday, July 31, 2014 11:13 PM To: General discussion about the WiX toolset. Subject: Re: [WiX-users] Installer size doubles up if signed I sign all of my MSI's and Burn bundles. I only see a few K difference, so something is seriously wrong. How do these MSI's look in Orca? -- John Merryweather Cooper Build Install Engineer - ESA Jack Henry Associates, Inc.(r) Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com From: Ashish Agarwal [ash...@mangoapps.com] Sent: Thursday, July 31, 2014 10:14 PM To: General discussion about the WiX toolset. Subject: [WiX-users] Installer size doubles up if signed Hi, We are in the process of migrating to Wix from the old Visual Studio installer and are hitting an issue. We use a single setup project that runs once in 32 bit mode and once in 64 bit to generate two MSI files. These are then packaged together using Burn. When the external cab files are not signed (but the MSIs and final setup exe is) the final exe generated by the bootstrapper is ~50MB. However, if we decide to sign the external cabs as well before creating the bundle the final setup size becomes 100MB. We would ideally like to sign the Cab files. Any pointers on what can be done? -- -- At MangoApps http://www.mangoapps.com we specialize in social collaboration platforms for mid-size companies (100-5,000 users). You can find more information, including 5 case studies and lots of current customer reviews here: MangoApps Dossier http://download.mangoapps.com/documents/MangoAppsDossier_Hires.pdf --
Re: [WiX-users] Passing Variables from C# custom BA to WIX
In the Bundle element, or a referenced fragment, use a Variable element and
use Override='yes'
Variable Name='VariableName' Value='*' Type='string'
bal:Overridable='yes'/
or
Variable Name='VariableName' Value='*' Type='numeric'
bal:Overridable='yes'/
For control logic in InstallCondition I prefer numeric, but if the variable
is to be passed to MsiProperty use a string.
In the mba, in OnDetectComplete (or wherever you want after Burn initializes
the variables)
if (myapp.Model.Engine.StringVariables.Contains(VariableName)
e.PackageId.Equals(myapp.Model.Engine.StringVariables[VariableName],
StringComparison.Ordinal))
{
myapp.Model.Engine.StringVariables[VariableName] = some
string;
}
(or use Engine.NumericVariables
In installCondition'= VariableName = 1 (if numeric or use quotes around
a string).
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Passing-Variables-from-C-custom-BA-to-WIX-tp7596113p7596187.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unbinder.Unbind error
Update: this seems to happen because I was suddenly running a x64 version of things - I had the project set to build as AnyCPU. This is very strange - I understand the library is 32 bit, but why should it fail with the exception mentioned? That's pretty obscure. (If it is clearer in WiX 3.7, ok ...) 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-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada -Original Message- From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: August-01-14 1:21 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Unbinder.Unbind error A while ago I built some stuff to investigate properties of a burn bundle (EXE) just in case they got lost when we built them, and also to harvest from others (in case we have some bundles not built by us). As per the list's recommendations, I added a reference to wix.dll and kept winterop.dll near by. The POC code looks like (fileName as a parameter from elsewhere) Dim b As New Microsoft.Tools.WindowsInstallerXml.Unbinder Dim out As Microsoft.Tools.WindowsInstallerXml.Output = b.Unbind(fileName, Microsoft.Tools.WindowsInstallerXml.OutputType.Bundle, c:\scratch\) For a while, this worked; some directories of XML and such were created I was able to read from. Now something (not this part of the code, since I haven't touched it) has changed and I get : An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B) Stack trace: at Microsoft.Tools.WindowsInstallerXml.Cab.Interop.NativeMethods.ExtractCabBegin() at Microsoft.Tools.WindowsInstallerXml.Cab.WixExtractCab..ctor() at Microsoft.Tools.WindowsInstallerXml.BurnReader.ExtractUXContainer(String outputDirectory, String tempDirectory) at Microsoft.Tools.WindowsInstallerXml.Unbinder.UnbindBundle(String bundleFile, String exportBasePath) at Microsoft.Tools.WindowsInstallerXml.Unbinder.Unbind(String file, OutputType outputType, String exportBasePath) at InstallerBuilder.PackageRepresentation..ctor(String fileName, String notesText, String whoBy) in C:\Users\dougkei\Downloads\DEV\ToolBox3\InstallerBuilder-branch\DeploymentManagement\Business Classes\PackageRepresentation.vb:line 169 C:\Users\dougkei\Downloads\DEV\ToolBox3\InstallerBuilder-branch\DeploymentManagement\Business Classes\PackageRepresentation.vb:line 169 This exception occurs with every bundle I've tried, including one that I just built to make sure it wasn't somehow wrong previously. Any idea what could be going wrong here? I have moved recently to Windows 7 x64, if that matters somehow. Keith Douglas Programmer Analyst | Programmeur analyste Questionnaire Development Services - CAI Social | Services de développement de questionnaires - IAO Social Jean Talon Building | Immeuble Jean-Talon / Floor | Étage 4 A-3 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-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Passing Variables from C# custom BA to WIX
In regard to the above discussion about your mba code, I was recently looking
at similar code in the wix src\Setup\WixBA\InstallViewModel.cs which has the
following code:
private void PlanPackageBegin(object sender,
PlanPackageBeginEventArgs e)
{
if
(WixBA.Model.Engine.StringVariables.Contains(MbaNetfxPackageId)
e.PackageId.Equals(WixBA.Model.Engine.StringVariables[MbaNetfxPackageId],
StringComparison.Ordinal))
{
e.State = RequestState.None;
}
}
So if you had code like this in your mba, I then:
1) Added as the first item in my Chain.
PackageGroupRef Id=NetFx40ClientWeb /
I did not author the PackageGroupRef but used what is in the wixNetExtension
2) Added a MbaNetfxPackageId WixVariable, and did not author the following
WixVariable Id=WixMbaPrereqPackageId Value=Netfx4Full /
WixVariable Id=WixMbaPrereqLicenseUrl Value=NetfxLicense.rtf /
When I had the above in the wix file I got a duplicate Id error. So I have:
WixVariable Id=MbaPrereqPackageId Value=NetFx40ClientWeb /
This seems to be working for me. I had been meaning to sort out this issue
as QA raised questions about it yesterday. Thanks to your post I was able
to get it working. I still have some testing to do so maybe I am
overlooking something.
--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Passing-Variables-from-C-custom-BA-to-WIX-tp7596113p7596192.html
Sent from the wix-users mailing list archive at Nabble.com.
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Passing Variables from C# custom BA to WIX
When I say that it 'worked' I mean on a Windows 8 x64, with build in netfx4x support, the mba runs and NetFx40 setup is not launched. On Windows 7 x6x with no NetFx support installed, the mba prereq dialog prompts the user to allow NetFx to be installed, then it is installed and my mba is then launched. Thanks again for the info that helped me get this working in my mba. I was always confused by examples that initialized: WixVariable Id=WixMbaPrereqPackageId Value=Netfx4Full / WixVariable Id=WixMbaPrereqLicenseUrl Value=NetfxLicense.rtf / but, when I do not do that and use the following it seems to work. More testing is needed. WixVariable Id=MbaPrereqPackageId Value=NetFx40ClientWeb / -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Passing-Variables-from-C-custom-BA-to-WIX-tp7596113p7596193.html Sent from the wix-users mailing list archive at Nabble.com. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Passing Variables from C# custom BA to WIX
I also removed: WixVariable Id=MbaPrereqPackageId Value=NetFx40ClientWeb / And it seems to work without running NetFx on a system that has Fx support. But I need to test this more next week. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Passing-Variables-from-C-custom-BA-to-WIX-tp7596113p7596194.html Sent from the wix-users mailing list archive at Nabble.com. -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Unbinder.Unbind error
Winterop.dll is a 32-bit so your calling assemblies need to stay 32-bit not get JIT'd to 64-bit. ___ FireGiant | Dedicated support for the WiX toolset | http://www.firegiant.com/ -Original Message- From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: Friday, August 1, 2014 10:51 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Unbinder.Unbind error Update: this seems to happen because I was suddenly running a x64 version of things - I had the project set to build as AnyCPU. This is very strange - I understand the library is 32 bit, but why should it fail with the exception mentioned? That's pretty obscure. (If it is clearer in WiX 3.7, ok ...) 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-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada -Original Message- From: keith.doug...@statcan.gc.ca [mailto:keith.doug...@statcan.gc.ca] Sent: August-01-14 1:21 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Unbinder.Unbind error A while ago I built some stuff to investigate properties of a burn bundle (EXE) just in case they got lost when we built them, and also to harvest from others (in case we have some bundles not built by us). As per the list's recommendations, I added a reference to wix.dll and kept winterop.dll near by. The POC code looks like (fileName as a parameter from elsewhere) Dim b As New Microsoft.Tools.WindowsInstallerXml.Unbinder Dim out As Microsoft.Tools.WindowsInstallerXml.Output = b.Unbind(fileName, Microsoft.Tools.WindowsInstallerXml.OutputType.Bundle, c:\scratch\) For a while, this worked; some directories of XML and such were created I was able to read from. Now something (not this part of the code, since I haven't touched it) has changed and I get : An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B) Stack trace: at Microsoft.Tools.WindowsInstallerXml.Cab.Interop.NativeMethods.ExtractCabBegin() at Microsoft.Tools.WindowsInstallerXml.Cab.WixExtractCab..ctor() at Microsoft.Tools.WindowsInstallerXml.BurnReader.ExtractUXContainer(String outputDirectory, String tempDirectory) at Microsoft.Tools.WindowsInstallerXml.Unbinder.UnbindBundle(String bundleFile, String exportBasePath) at Microsoft.Tools.WindowsInstallerXml.Unbinder.Unbind(String file, OutputType outputType, String exportBasePath) at InstallerBuilder.PackageRepresentation..ctor(String fileName, String notesText, String whoBy) in C:\Users\dougkei\Downloads\DEV\ToolBox3\InstallerBuilder-branch\DeploymentManagement\Business Classes\PackageRepresentation.vb:line 169 C:\Users\dougkei\Downloads\DEV\ToolBox3\InstallerBuilder-branch\DeploymentManagement\Business Classes\PackageRepresentation.vb:line 169 This exception occurs with every bundle I've tried, including one that I just built to make sure it wasn't somehow wrong previously. Any idea what could be going wrong here? I have moved recently to Windows 7 x64, if that matters somehow. Keith Douglas Programmer Analyst | Programmeur analyste Questionnaire Development Services - CAI Social | Services de développement de questionnaires - IAO Social Jean Talon Building | Immeuble Jean-Talon / Floor | Étage 4 A-3 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-854-5589 Facsimile | Télécopieur 613-951-4674 Government of Canada | Gouvernement du Canada -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Want fast
