Jason Ginchereau's Blog : Votive

Votive project platform configurations

jasongin — Wed, 09 Jul 2008 20:42:00 GMT

There are some problems using older .wixproj files with newer builds of Votive. When accessing project properties you may receive the error message:

An error occurred trying to load the page.
Value does not fall within the expected range.

Update: As another symptom of the same issue, you may also experience problems with source control check-out with any projects in the solution.

The breaking changes were introduced in WiX builds 3.0.4109 - 3.0.4220, so a .wixproj created with a build <4109 will have problems when used with a build >=4220. I'll explain the changes here and show you how to update older project files to work with newer WiX builds.

The changes are all about the default and available platform configurations of WiX projects. Previously, WiX projects always had a platform of "Any CPU", and there was no way to change it. But actually MSI packages are somewhat platform-specific: a package is marked as either 32bit or 64bit, and cannot be both. While a 32bit MSI can install on a 64bit OS, it's a bit like a 32bit EXE running on WoW in that it can't easily interact with any of the 64bit parts of the system.

The WiX command-line toolset has long enabled building both 32bit and 64bit MSIs, and more developers are starting to build 64bit packages, so we thought it made a lot of sense to expose that capability in the natural Visual Studio representation: project platforms. With the latest builds, a new WiX project has its configuration set to "x86" by default, and you can use the VS Configuration Manager to add an additional "x64" platform if you need it. (IA64 support is not yet implemented... is there any demand?) Also "Any CPU" is no longer a valid platform for WiX projects -- it was only there because Votive builds on a VS project framework was originally designed for compiling .NET languages.

If you have WiX projects that were created with an older WiX build and you want to continue to use them with a newer build without recreating the projects, use the following steps:

Install the new build of WiX.
In VS, open the solution that includes one or more WiX projects.
For each WiX project node in the solution explorer, right-click and Unload Project, then right-click again and Edit the .wixproj.
Change the conditional expression on each configuration PropertyGroup to include an "x86" platform:

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">

...

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
Right-click on the project node and Reload the project.
From the Build menu, open the Configuration Manager tool. Ensure that each WiX project is selected to build (if desired) for each solution configuration.

Custom action project templates

jasongin — Fri, 23 May 2008 19:19:00 GMT

New in this week's WiX build 3.0.4123 are Visual Studio 2005 & 2008 templates for C++, C#, and VB custom action projects:

The C++ project sets you up with the WiX unmanaged CA utility library (wcautil), while the C# and VB projects use the DTF library for managed-code MSI custom actions. I assume you're here because you want to read more about the latter.

When DTF first released with WiX last week, it included some sparse documentation about how to create a post-build step to package up your managed CA assembly in a form callable by MSI. I apologize to anyone who jumped on it right away and had trouble hooking things up (which was only made more difficult by a missing binary that had to be built from source). I should have had these templates ready then.

When you create a C# custom action project from the new template, the project has the necessary post-build step hooked up already. For the curious, those build rules are in %ProgramFiles%\MSBuild\Microsoft\WiX\v3.0\wix.ca.targets. Building the custom action project will produce an additional DLL in the target directory with the name $(TargetName).CA.dll. That is the DLL to be streamed into your MSI Binary table. Since that DLL exports ordinary entrypoints callable directly by the MSI engine, you can use it with any MSI authoring tool as if it was an unmanaged CA DLL.

The custom action build process will automatically package up any non-GAC'd assemblies that your CA depends on. (Make sure the Copy Local property is set to 'true' on the reference node if you want it included.) Those dependencies will include at a minimum the Microsoft.Deployment.WindowsInstaller.dll assembly from DTF. Additionally, any items in the project with a Build Action of 'Content' will be included in the CA package. CustomAction.config is the sole Content file in the template; your CA may require additional resources or data files at runtime.

In Votive, a convenient way to consume the custom action DLL in your setup is via a project reference:

Create a solution with a WiX MSI or WiX Library project and a C# or VB custom action project.
Add a reference from the WiX project to the custom action project.
Author the custom action in your setup with WiX code similar to the fragment below. Note you may need to change some attributes in the XML, depending on your CA and how it executes.

<Binary Id="MyCustomAction.dll"

SourceFile="$(var.CAProjectName.TargetDir)$(var.CAProjectName.TargetName).CA.dll" />

<CustomAction Id="MyCustomAction" BinaryKey="MyCustomAction.dll"

DllEntry="CAMethodName" Execute="immediate" />

</Fragment>

I hope this helps interested developers get started with managed custom actions. Future posts here will hopefully get into some actual coding.