I have a hand-crafted MSBuild script that build my WiX based installer. The installer contains a custom action DLL as a <Binary> element. MSBuild thinks the MSI is still up to date when this DLL changes, although it rebuilds correctly when I change other files that are part of components. Is there some way to tell the Light task to look at additional dependencies?
Thanks.
Create a ProjectReference from your .wixproj to your custom action project and MSBuild will correctly detect the dependency and should cause the installer project to build again. Additionally, WiX v3.6+ has improved the rebuild checks so ensure you are using a new version of the WiX toolset as well. If you still see problems it could be a bug in the WiX toolset that would be great to fix.
Related
We have a solution, there are about 100 hundred projects in it. And we have around 20 installers which we created with vdproj.
I need to create WiX projects, which would create .msi instead of vdproj. I used dark.exe to generate wxs file out of msi and got binaries out of it.
I successfully created an msi file and everything was good.
But then I started thinking about it. If some of these projects are changed, will those changes be applied to the application after rebuilding of wix project? Or wxs will be referencing the old version and to update it someone will have to rebuild vdproj project to create new msi, then use dark.exe again?
I am sorry for a stupid question, it's my first time using wix and working with installers in general.
Thank you in advance
You've started on the right track. The VDPROJ outputs are .msi files, so using dark to convert those to wxs files is the right thing to do. Now that you have your wxs files (the base source file to build wix deployments), you can do away with the VDPROJ projects in your solution and only update and use the wxs files (I believe WiX has a visual studio project template available as well).
You'll have to update you wxs files with new assemblies or deliverable files as your projects change.
It is better this way then doing a wildcard pickup (something you can't technically do with WiX, anyway) as having explicit control of what goes on the target machine is preferred. I've seen many cases where developers carelessly add a reference as build output that isn't needed, and sometimes that reference cannot be redistributed per the license agreement or other legalities.
My build system creates a MSI using Wix, it then uses WIX to bundle that into another EXE that acts as a bootstrapper. The bootstrapper makes sure all the dependencies are installed (.NET and so forth).
I would like to change some properties inside the MSI depending on who downloads it. I won't know the settings until long after the build is complete.
I am able to do that with the MSI by editing the properties DB. However when I try the same technique with the bundle, it (WIX interop libarary) says it can't open the file.
So, how can I do one of these things:
Edit a property inside the WIX bundle EXE (that I can then pass to the bundled package)
Extract and re-insert the bundled MSI
You can pass properties using commandline to wix bundle. The bundle then can pass the property to MSI.
WiX Bootstrapper: How do I set burn variables from the command line?
Pass parameters from bootstrapper to msi bundle package
The other solution I can think of: If you write your own custom bootstrapper, you'll have access to IBootstrapperEngine::SetVariable, and you can do whatever you want with that, including setting properties that MSI can read. https://wixwpf.codeplex.com/ should be pretty easy.
If you are asking if there is such tool like orca.exe for Wix burn, then I would say no.
Potential options:
Generate wix burn installer on the fly (including compilation)
Split up executable: set the Compressed attribute to "no". You'll have access to *.msi then.
I've got a .msi file produced by WiX which is working great, and now I want to wrap it in a bootstrapper. Previously I used setupbld, but as that is now deprecated I'm experimenting for the first time with burn from WiX 3.8.
However, every time I run burn from the command line nothing happens, regardless of parameters. I connected a debugger and got the following output if I run burn.exe with no parameters:
The program '[0x1380] burn.exe: Native' has exited with code -2147024883 (0x8007000d).
Does anybody know what is wrong here?
Note, I am literally running "C:\Program Files (x86)\WiX Toolset v3.8\bin\x86\burn.exe". I notice that burn.exe has an icon resembling an msi package (despite being an exe) so I'm not sure whether this is the installer for burn, or whether it is burn itself.
Tbh, I'm finding that although there is lots of documentation on writing the XML files needed by burn, there seems to be precious little on actually invoking it, and what to expect when one does.
Burn is the bootstrapper engine, not the builder. The error is ERROR_INVALID_DATA, which makes sense because burn.exe does have any data attached to it; The builder copies and modifies it to contain and/or point to containers for your bootstrapper's data.
To build a bootstrapper, you create a WiX document with a bundle element and then run candle.exe and light.exe on it.
Many people use a build system to run their tools and an IDE to manage their projects. WiX integrates with MSBuild and Visual Studio (non-free editions). There is a WiX Bootstrapper project template for Visual Studio provided, too. The SharpDevelop IDE has its own WiX templates (but currently not for the Bootstrapper.)
Note: All WiX projects are MSBuild projects so you can hand-write projects and/or build them with MSBuild instead of the IDE.
I've had some trouble getting WiX projects to build on build servers. One of the pain points has been that my WiX projects are referencing libraries in c:\program files... and the build process calls executables in the same path. This is a bummer because I have to install WiX toolkit in order to get my project to build.
What's the best way to eliminate this headache by having all build tools local to the project being built?
Is there a nuget package that does this? (At the time of writing it appears not, but I wanted to verify.) Package Restore capability would be nice because then I don't have to include the (many) WiX files in git.
If not, what do I need to download from WiX? What do I need to modify so that the compiler knows where to find the binaries to build WiX projects?
You can download just the WiX Binaries .zip from http://wixtoolset.org/releases/ then you can modify your wixproj file and update the <WixToolPath></WixToolPath> element to point to your WixBinaries
The WiX documentation has an article that explains how: Integrating Wix Projects into your Daily Builds
There is an unofficial nuget package at WiX.Toolset.
However, note that this seems to only be applicable to the setup project itself (i.e. it cannot be used to fetch wix binaries for e.g. a class library assembly).
I've adopted a Visual Studio solution that contains a number WiX projects. We build the solution from an MsBuild script to generate the product's installer msi.
The problem I'm experiencing is that if I build (and don't rebuild), even if exe's and dll's get updated that need to be put in the installer, the WiX build system doesn't seem to detect this and skips building the installer as it thinks it's already up to date.
How do I work out what the dependencies are that are needed to build a WiX project, and how do I tell the Wix build system to watch out for them changing so it knows to build instead of skip?
Thanks.
This facility was added to WiX 3.6 with little fanfare - in the WiX 3.6 release notes it simply says ".wixproj MSBuild projects support incremental build."
The WiX MSBuild targets don't currently support payloads as inputs into the build process, so nothing tells MSBuild that the WiX targets need to be called. Feel free to file a feature request at wix.sf.net; a couple of us have been talking about ways to do it.
If you can include the projects that create the exe's and dll's into the solution containing the wix projects, you can add project references from the wix projects to the appropriate application projects. Then wix should properly perform incremental builds.
I configure my wix projects to only be included in the release configuration so that the apps can be quickly built and run without creating the install in the debug configuration.