Re: [WiX-users] Bootstrapper manifest

Hi Rob, we do also have the need of an elevated BA. Our BA collects all the information required for the installation in a kind of setup wizard. robmen wrote Your BootstrapperApplication should not be modifying machine state at all. The elevation is needed, because we want to check for the

Re: [WiX-users] [WIX-users] Patch in Wix 3.6 is empty. warning PYRO1079: The cabinet '***.cab' does not contain any files

Hello Bob, Bob Arnson-6 wrote Then please file a bug with sufficient detail to reproduce the problem. There is already a bug filed: https://sourceforge.net/p/wix/bugs/3244/ Unfortunately it was marked as expected behavior although this scenario was working in v3.5 and is not working any more

Re: [WiX-users] [WIX-users] Patch in Wix 3.6 is empty. warning PYRO1079: The cabinet '***.cab' does not contain any files

Hi Guys, we are using the way of building patches as described in WiX help Patch Building Using Purely WiX, meaning that we are building the delta from the wixpdb's using torch. The only difference to the sample is that the files for the different versions are always in the same location during

[WiX-users] Managed CustomActions not compiling with latest WiX 3.6 version

Hello, today I upgraded from WiX 3.6 Beta to version 3.6.2603.0. Now none of my managed custom actions is compileable any more. There are two problems: 1) the reference to Microsoft.Deployment.WindowsInstaller seems to be ok on the first glimpse but none of it's types is available and in the

Re: [WiX-users] Burn - Moving payload to Cache Directory

I faced the same problem with the .Net 4.0 prerequisite. It seems that the package is actually downloaded, even though it is not uninstalled. Here is my package declaration: ExePackage Id=Netfx4Full Cache=no Compressed=no PerMachine=yes

[WiX-users] Burn: package ref-counting not working

Hi folks, as I read in the WiX 3.6 Beta release notes, burn does support package ref-counting now, which according to my understanding should guarantee, that shared packages are uninstalled only if all bundles sharing the packages were removed. Here is a little example: - install

Re: [WiX-users] Burn: check for MSI existence and validity

Rob Mensching-7 wrote The BootstrapperApplication.xml should list all the payloads, so if you really want to do this upfront, your BA should be able to it (plus using the WixBundleOriginalPath variable). In the temporary folder I found a file BootstrapperApplicationData.xml. I guess this

Re: [WiX-users] Burn: check for MSI existence and validity

In our MBA we implemented a setup wizard with a feature selection on the first step. My intention was to give a hint to the user in case of missing or invalid packages *before* he entered the necessary information and the installation actually begins. Rob Mensching-7 wrote 1. If a package

[WiX-users] Burn: check for MSI existence and validity

relative to the bootstrapper. But in events like BootstrapperApplication.DetectPackageComplete there is no such information. 2) Here it would be useful to know what burn does to check if the MSI file is the one which was used during build. Is it a CRC check? Best regards Kryschan -- View

Re: [WiX-users] Hidden Bundle Variables

make a statement when this bug will be solved. I contacted the assigned developer but got no reply. Best regards Kryschan -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Hidden-Bundle-Variables-tp6605759p6903702.html Sent from the wix-users mailing

Re: [WiX-users] Manifest for Burn Bootstrapper

Hi Rob, Rob Mensching-7 wrote: You're supposed to display UI and only elevate when the user does an action that requires it. I agree with that and I was searching for a while to find a programmatic way to reqest elevation from .Net so that I can force the BA to elevate right before it is

[WiX-users] Hidden Bundle Variables

text (in arguments list). Is there something else to do besides setting the hidden attribute to yes on those variables? Best regards Kryschan -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Hidden-Bundle-Variables-tp6605759p6605759.html Sent from

[WiX-users] Manifest for Burn Bootstrapper

Hi! My bootstrapper application needs to gather some information from IIS and therefore needs to be elevated. Is it possible to embed a manifest requesting the level requireAdministrator into the bootstrapper? If yes how would this be done? Best regards Kryschan -- View this message in context

[WiX-users] Unknown WiX variables in Bundle with WiX 3.6.1908.0

) is unknown. ... When using WixStandardBootstrapperApplication.RtfLicense instead, the project builds. It was working in version 3.6.1817.0. Do I have to change something in my bundle or is this a bug. Best regards, Kryschan -- View this message in context: http://windows-installer-xml-wix

Re: [WiX-users] Unknown WiX variables in Bundle with WiX 3.6.1908.0

Sorry but I still don't know what to do now to make my bootstrapper build again. Can you please give me a hint on that or do I have to wait for the documentation update? Best regards Kryschan Rob Mensching-7 wrote: Ug, sorry, I forgot to update the documentation about the breaking change

Re: [WiX-users] Burn bootstrapper as x64 exe

Kryschan wrote: I'm trying create a bootstrapper containing some 64bit MSI packages, which (of course) shall be installed on a x64 system. As the MSIs are installed in silent mode, my bootstrapper should gather the required information from the user, which also includes reading values from