votive, wix, vsip, and all things microsoft : WiX

Changing the file extension of WiX extensions from .dll to .wixext (Revisited)

jrock — Mon, 03 Mar 2008 23:27:57 GMT

In one of my last blog posts I wrote about how we would be changing the file extension of WiX extensions from .dll to .wixext. Well, it turns out that we won't be doing it for technical reasons.

A WiX extension is really just a .NET assembly with an embedded XSD and wixlib. While it's technically possible to rename a managed assembly from .dll to .wixext, it will add a limitation that we didn't want to enforce. If WixExtensionA.wixext had a runtime reference to WixExtensionB.wixext, then the runtime cannot find the file if it doesn't end in a .dll. I personally think that's a limitation that the .NET Framework did not need to impose, but I also do not know all of the details. I'm sure there was a good reason to impose that limitation. We also had some problems with Visual Studio not letting us add project references to other WixExtensions that didn't end in a .dll.

As a result, we will not be doing this change and the current behavior will remain.

Changing the file extension of WiX extensions from .dll to .wixext

jrock — Wed, 13 Feb 2008 23:33:00 GMT

We will be doing a change that will probably affect most users of WiX v3, so I wanted to get this blog post out in the community to notify people of the upcoming change. Within the next few weeks we will be changing the file extension of WiX extensions from .dll to .wixext. There are several reasons why we think this is an important thing to do:

Wix-specifc file extensions
OS file handlers and icons
Votive UI

WiX-specific File Extensions

Although a WiX extension is really just a .NET assembly with an embedded XSD and wixlib, it really should be differentiated as a separate file type. This gives us the flexibility to change the format of the file in the future without affecting the semantics of how you work with the file.

Also, we have WiX-specific file extensions for all of our other types of files. For example, .wxs, .wxi, and .wxl are all XML files, but giving a separate file extension provides ease of use.

OS File Handlers and Icons

Typically a file extension is handy when viewing and working with files in Windows Explorer. For example, when you double-click a .wxs file (assuming you have installed Votive), then Visual Studio will be opened and will display the contents of that file. Users are also free to associate other tools with a given file extension. The problem with using the .dll extension in our WiX extensions is that it limits our flexibility in regards to open behavior in Windows Explorer. First of all, a DLL is a special type of entity in Windows, so mapping editors/viewers to the .DLL extension is not always possible or advisable. In the future, we may want to open WiX extensions in Votive in a special type of viewer or editor. By having a separate .wixext file extension, it gives us this flexibility.

One other advantage to using .wixext is that we can associate an icon with the extension. We can't do that if we use the .DLL extension (well we can but not without writing some code to open up the file and detect whether it is truly a WiX extension).

Votive UI

In Votive, when you want to add a reference to an extension the "Add Reference" dialog will be shown. Currently it filters on WiX Extension Files (*.dll) which shows all of the standard extensions, but it also will show things like wix.dll, which aren't WiX extensions. That's a little confusing to a new user I think. Granted, we do name our extensions things like WixIIsExtension.dll, so it's at least somewhat evident, but still it's confusing. If we can instead filter on *.wixext then only valid WiX extensions are shown in the Add Reference dialog.

Backwards Compatibility

Although the file extension will change from .dll to .wixext the tools will still support the old .dll extension. In fact, they really won't impose any restriction on the file extension since the contents of the file are what matter.

How Does this Affect You?

If you use any of the standard WiX custom action extensions, then you'll have to change your build scripts to reference the new names.

If you use MSBuild or Votive, then you'll have to change any references you have in your .wixproj files (<WixExtension> elements). You can do this manually by hand-editing the .wixproj file or you can do this by removing the old references (right mouse click and select "Remove") and then re-adding them.

<ItemGroup>  
  <WixExtension Include="$(ProgramFiles)\Windows Installer XML v3\bin\WixIIsExtension.wixext" />
</ItemGroup>

We will also try to put out a similar reference for NMake and NAnt when the feature gets checked in.

The bug tracking this feature is at http://sourceforge.net/tracker/?func=detail&atid=642714&aid=1868802&group_id=105970.

We expect to have the work done and checked in by the end of February. We will send out another notice to the wix-users@lists.sourceforge.net alias and I will also post another blog entry when this happens.

Complete list of Candle preprocessor variables

jrock — Wed, 30 Jan 2008 01:58:00 GMT

Some people have asked about this in the past on the wix-users mailing list, so I thought I'd just put it here so it's on the web searches. (We really need to do an overhaul on our WiX home page).

This is just copied verbatim from the Wix.chm file.

[Edit]: By the way, this list applies to Votive v3 and not Votive v2. Although similar, complete instructions on how to do this in Votive v2 are given in Rob's MSDN article here (http://msdn2.microsoft.com/en-us/aa302186.aspx#wixsetup_topic9).

Project References

Introduction

The WiX Visual Studio package supports adding project references to a WiX project. This ensures that build order dependencies are defined correctly within the solution. In addition, it generates a set of WiX preprocessor definitions which are set on the Candle command line and can be referenced in source files.

Adding Project References

To add a project reference to a WiX project:

Right-click on the References node of the project in the Solution Explorer and choose Add Reference...
In the Add WiX Library Reference dialog, click on the Projects tab.
Select the desired project(s) and click the Add button, then click OK to dismiss the dialog.

List of Supported Project References

The WiX Visual Studio package supports the following project reference variables:

Variable name	Example usage	Example value
var.<ProjectName>.Configuration	$(var.MyProject.Configuration)	Debug or Release
var.<ProjectName>.FullConfiguration	$(var.MyProject.FullConfiguration)	Debug \| AnyCPU
var.<ProjectName>.Platform	$(var.MyProject.Platform)	AnyCPU, Win32, x64 or ia64
var.<ProjectName>.ProjectDir	$(var.MyProject.ProjectDir)	C:\users\myusername\Documents\Visual Studio 2005\Projects\MyProject\
var.<ProjectName>.ProjectExt	$(var.MyProject.ProjectExt)	.csproj
var.<ProjectName>.ProjectFileName	$(var.MyProject.ProjectFileName)	MyProject.csproj
var.<ProjectName>.ProjectName	$(var.MyProject.ProjectName)	MyProject
var.<ProjectName>.ProjectPath	$(var.MyProject.ProjectPath)	C:\users\myusername\Documents\Visual Studio 2005\Projects\MyProject\MyApp.csproj
var.<ProjectName>.TargetDir	$(var.MyProject.TargetDir)	C:\users\myusername\Documents\Visual Studio 2005\Projects\MyProject\obj\Debug\
var.<ProjectName>.TargetExt	$(var.MyProject.TargetExt)	.exe
var.<ProjectName>.TargetFileName	$(var.MyProject.TargetFileName)	MyProject.exe
var.<ProjectName>.TargetName	$(var.MyProject.TargetName)	MyProject
var.<ProjectName>.TargetPath	$(var.MyProject.TargetPath)	C:\users\myusername\Documents\Visual Studio 2005\Projects\MyProject\obj\Debug\MyProject.exe
var.SolutionDir	$(var.SolutionDir)	C:\users\myusername\Documents\Visual Studio 2005\Projects\MySolution\
var.SolutionExt	$(var.SolutionExt)	.sln
var.SolutionFileName	$(var.SolutionFileName)	MySolution.sln
var.SolutionName	$(var.SolutionName)	MySolution
var.SolutionPath	$(var.SolutionPath)	C:\users\myusername\Documents\Visual Studio 2005\Projects\MySolution\MySolution.sln

Example

The following File element demonstrates how to use project references in WiX authoring:

<File Id="MyExecutable" Name="$(var.MyProject.TargetFileName)" Source="$(var.MyProject.TargetPath)" DiskId="1" />

How to use Extensions in Votive (IIS or UI extensions, for example)

jrock — Fri, 19 Oct 2007 21:02:00 GMT

It seems we have this question pop up a few times a week on the wix-users mailing list, so I thought I'd add something here as another reference when people are searching the web. Thanks to Aaron Stebner for writing this entry in our WiX.chm file, available as part of the WiX releases (>= 3.0.3419).

How to use WiX 3.0 extensions when building MSIs

To use a WiX 3.0 extension when calling the WiX tools directly, you need to use the -ext command line parameter available in the Candle, Light and Lit tools and pass in the extension DLL(s) needed for your project. Each extension DLL must be passed in via separate -ext parameters. For example:

light.exe MySetup.wixobj
-ext "C:\Program Files\Windows Installer XML v3\bin\WixUIExtension.dll"
-ext "C:\Program Files\Windows Installer XML v3\bin\WixUtilExtension.dll"
-out MySetup.msi

To use a WiX 3.0 extension when building in Visual Studio with the Votive add-in, you can use the following steps:

Right-click on the WiX project in the Visual Studio solution explorer and select Add Reference...
In the Add WiX Library Reference dialog, click on the Browse tab and browse to the WiX extension DLL that you want to include.
Click the Add button to add a reference to the chosen extension DLL.
Browse and add other extension DLLs as needed.

After you have added a reference to an extension DLL, Votive will automatically add the appropriate -ext command line switches when it calls Candle, Light or Lit when performing a build.

How to enable IntelliSense for WiX 3.0 extensions

To enable IntelliSense for a WiX extension in the Visual Studio IDE, you must also add an XMLNS declaration to the <WIX> element in your WXS file. For example, if you want to use the NativeImage functionality in the WixNetFxExtension, the element would look like the following:

<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"
     xmlns:netfx="http://schemas.microsoft.com/wix/NetFxExtension">

After adding this, you can add an element named <netfx:NativeImage/> and view IntelliSense for the attributes supported by the NativeImage element.

Handy little Visual Studio shortcut key for Wix/Votive developement

jrock — Fri, 17 Nov 2006 00:42:00 GMT

If you use Visual Studio to edit your Wix projects (either using Votive or just the plain XML editor), you may be interested in this handy little shortcut key. If you turn on pedantic checking for your WiX files, one of the warnings will be about having mixed-case GUIDs. The easy fix is to select the GUID and then go to Edit / Advanced / Make Uppercase (Ctrl+Shift+U). Voila, your GUID is now all uppercase.

Updated the Votive page on wix.sourceforge.net

jrock — Mon, 02 Oct 2006 23:18:00 GMT

We've been missing information about Votive on our official WiX web page, so I updated the web site. You can check it out at http://wix.sourceforge.net/votive.html. It also has some screen shots.

Robert Scoble visits our Wix night

jrock — Wed, 08 Mar 2006 20:54:00 GMT

The Scobleizer visited our weekly Wix night last night. He took a picture but both K and I got robbed. K's laptop is on the left side of the picture and I'm behind Robert taking the picture. :) Oh well, maybe we'll be in the video when it appears on Channel 9.

How to get IntelliSense for WiX in Visual Studio 2003 and 2005

jrock — Fri, 23 Dec 2005 12:50:00 GMT

There have been a couple people to blog about this already (one is here), but I wanted to point out that Visual Studio 2003 and Visual Studio 2005 are different in how you get IntelliSense working for WiX files. For both you have to copy the wix.xsd file to a specified directory.

Visual Studio 2003

Copy the wix.xsd and wixloc.xsd files to the following directory: C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\Packages\schemas\xml

Visual Studio 2005

Copy the wix.xsd and wixloc.xsd files to the following directory: C:\Program Files\Microsoft Visual Studio 8\Xml\Schemas

Now when you add <Wix xmlns="http://schemas.microsoft.com/wix/2003/01/wi"></Wix>, you should have IntelliSense. I don't recommend manually changing the registry key, as is mentioned in the other blogs, because the GUID is different for the XML editor between Visual Studio 2003 and 2005. You can achieve the same effect by opening a wxs, wxi, wxl, wixlib, or wixobj from within Visual Studio. Then on the Open dialog, click the drop down arrow on the Open button and select "Open With". It will then pop up a dialog with all of the various editors registered with Visual Studio. Select the XML Editor (HTML/XML Editor in Visual Studio 2003) and then click the "Set as Default" button. Now whenever you open a file with that extension Visual Studio will use the XML editor for it.

I'd also like to give a shameless plug for Votive, which is even easier. The votive.msi file available here will automatically copy the xsd files to the right places for you and will also give you WiX project support within Visual Studio: build support, editing, and many of the other nice Visual Studio stuff. It will also register all WiX file types under the XML editor, using the correct GUIDs. Note that Votive is still fairly young, so it does not have all of the features you'd expect. I'm always willing to have help, though, if you're interested in tackling some more features. [;)]

Moving the WiX toolset to NAnt builds

jrock — Fri, 09 Sep 2005 09:58:00 GMT

As many of you may know, we've had two different builds for the WiX toolset: one for the external world (i.e. SourceForge), and the other for the developers working on WiX inside of Microsoft. These two builds were different enough to mess things up from time to time, and at the very least was annoying trying to port from one to the other. Therefore, we've decided to start using a new build system. At first we thought we'd use the new and improved MSBuild system that comes with Whidbey. However, we found that it doesn't support VC++ builds out of the box. Strike 1. We also found that it wasn't overly intuitive on how to get started with it and maintain it. Strike 2. And to top it off, it doesn't support building to the 1.1 .NET Framework. Strike 3.

I must say that I think the Visual Studio team has made some great improvements by introducing MSBuild in Whidbey and it's great in a lot of circumstances, just not ours. I honestly can't believe that it doesn't support .NET 1.1 or build VC++ projects. Maybe next version.

Since Bob, John, and I all had previous experience with NAnt, we thought we'd try it out on WiX. So far so good. I only have a couple of the projects converted over, but the build times have greatly decreased (almost by a factor of 10), the build files are much, much more readable than our NMAKE sources/makefile.inc, and it's just a lot more fun to use NAnt. For one thing, you have the nice IntelliSense when editing .build files in Visual Studio. Also, it should be much easier for people to build the WiX toolset from the SourceForge drop. I'm hoping that we can roll out the NAnt version within a week or two.

Announcing a new WiX project: Sconce

jrock — Wed, 31 Aug 2005 11:12:00 GMT

Although I'm still planning at this point to use the new VS SDK 2005 MPF classes, I want to continue to support the current Votive VS 2003 version for a little while. I at least want to clean up some bugs and make it a little more robust before moving on.

To help me in this endeavor, I've created a new project called "Sconce". What is it? Well, it's basically all of the Visual Studio infrastructure code that took up 90% of the Votive project. Why did I move it to another project? For a couple of reasons. The main reason is because I always wanted to have this isolation, which up until now I accomplished via namespace separation (Microsoft.Tools.WindowsInstallerXml.VisualStudio.Infrastructure). However, I needed to have the infrastructure code be able to support IDispatch COM marshaling. This is a long story in and of itself, which I may write another blog entry on, but suffice it to say that I needed everything to be public instead of internal. This prompted me to finally make the move to a separate DLL. Additionally, this isolation makes it very easy for us (or anybody else for that matter) to create more Visual Studio project types. I can't think of any that we'd want to make other than WiX at this point, but it does provide this infrastructure if we need it in the future.

Why the name "Sconce"? Of course I had to choose another candle-related term to fit in the WiX style. I thought Sconce sounded cool and the definitions loosely fit in with the Votive theme as well. Sconce is defined by dictionary.com as:

sconce² ( P ) Pronunciation Key (skns)
n.

A decorative wall bracket for holding candles or lights.
A flattened candlestick that has a handle.
Slang. The human head or skull.

So, Sconce could be a holder for votive candles (although you usually don't hang votive candles on the wall, but I did say "loosely" fits). [:)]

When will Sconce be available? It's part of the WiX 3.0 toolset, which isn't available yet. Derek and Rob are getting ready to release it soon.