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.
Related
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.
Is it possible to use wix commands from the command window? I have the wix 3.6 toolset installed and although the Wix Project is available, it seems that the project template does almost nothing to help you create a project. From my understanding, all the helpful tools are command based and are not accessible from the command window (at least they aren't for me). Am I missing something? It would seem rather unhelpful to have a visual studio project where you have to type all the xml by hand and then leave the IDE to use any of the useful tools.
You can call executables from the command window. For example, to call Heat with the /? param:
Tools.Shell /o /c heat.exe "/?"
Note that I have the WiX Toolset bin directory set in my Path.
You can also create code snippets to speed up entering repetitive xml.
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.
I'm trying to find a solution for the following issue:
I have numerous programs (lets call them slaves) that all rely on a single program (master). I need to distribute an installer for each slave. This installer needs to install the master.
I want to be able to version both pieces, so multiple msi's appear to be the right solution, chained with a bootstrapper.
My problem is if a slave installer installs the same version of the master that is already installed, the .msi will run in repair/remove mode.
This is unacceptable from a user standpoint and will just cause confusion.
Is there any way to check for a version of the currently installed fiels before trying to run the msi?
I am currently using WIX's setupbld.exe as a bootstrapper.
Any other solutions greatly appreciated (I have also tried merge modules with no success, since the versioning is useless)
Instead of using setupbld.exe (which I don't really know as I can't find any documentation) you can use msbuild's generatebootstrapper task. The wix documentation already covers how to use this task to generate a bootstrapper that installs the .NET framework. See How To: Install the .NET Framework Using a Bootstrapper. This makes use of the pre-defined bootstrapper packages.
However, in this case you will also have to author your own bootstrapper packages. One way to do this is to study the existing bootstrapper packages in C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\ (or the ones in the Windows SDK) and read the documentation of the Bootstrapper Manifest XML format. The bootstrapper generator tool might also be helpful.
To determine whether the package needs to be installed, you can use one of the InstallChecks to set a property, and then check the property value in a InstallCondition under the Commands element.
If you're thinking that this is all harder than it should be — I agree, but it's what I've used so far. There are some alternatives which I have not tried yet:
the poorly named dotNetInstaller
which is actually a general purpose
bootstrapper generator.
the wix 3.5 burn bootstrapper which is not yet released. I'm not sure if it is in a usable state yet.
Background:
I always try to ensure the following tenet in my projects:
After a fresh checkout a developer should be able to do all project related tasks with solely the contents of the combined folders.
Obviously, this isn't always possible (e.g. Visual Studio for Windows development). However, I really dislike having to install any third-party libraries or tools that are specific a project like log4net, NHibernate, NUnit, etc. There are number of reasons for this including:
For a given development machine, you may work on several different projects, all which leverage different versions of the same third-party library or tool.
Minimizing the environment setup requirements makes setting up new developers or machines much easier
Facilitates easier maintenance of automated builds
Assumptions/Contraints
I am currently using WiX 3 beta, but if there is way for either 2.0 or 3.0 please respond
I am using Visual Studio 2005
The IDE syntax highlighting is not a requirement.
Question:
Is it possible to avoid local installation of the WiX toolset and use flat files instead? If so, please explain how.
See Also:
First, build your WiX installer:
Create a new WiX Installer Project in Visual Studio 2005.
Build your WiX XML accordingly.
Now, to integrate the WiX toolkit into your source tree:
Copy c:\Program Files\Windows Installer XML v3\bin to a sub-directory in your source tree. I used WiX\bin relative to my .wixproj file.
Copy c:\Program Files\MSBuild\WiX\v3.0\ to a subdirectory in your source tree. I used WiX\v3.0 relative to my .wixproj file.
Either add the following code or replace the line that follows:
<WixTargetsPath Condition=" '$(WixTargetsPath)' == ''>$(MSBuildExtensionsPath)\Microsoft\WiX\v3.0\Wix.targets</WixTargetsPath>
With the following lines:
<WixToolPath>$(MSBuildProjectDirectory)\WiX\bin\</WixToolPath>
<WixTasksPath>$(MSBuildProjectDirectory)\WiX\v3.0\WixTasks.dll</WixTasksPath>
<WixTargetsPath>$(MSBuildProjectDirectory)\WiX\v3.0\Wix.targets</WixTargetsPath>
As you can see, the WixToolPath, WixTasksPath and WixTargetsPath directives reflect the location of the folders I've instructed you to copy.
Rename your .wixproj to .csproj. This ensures that Visual Studio does not get confused by the .wixproj file but because the .wixproj is a valid MSBuild project, Visual Studio will be able to work with it.
Using this method, the WiX directory as described is about 9MB large.
I know with WiX 2, you can just download the executable files and the dll's to whatever directory your project is in. Then you create a .bat file to run candle.exe and light.exe with the parameters you need to build your installer.
That way, all your projects can have their own version of WiX with a disk drive hit of only about 4 megs each.
I'm not positive, but I think you can do the same with WiX 3.