Moving to WiX

NUnit has finally gotten rid of it’s Visual Studio Install projects in favor of WiX

VS projects support only a simple, single-feature install. What’s more, if you outgrow your install project, you can’t simply migrate it to another tool. You have to start over with the new tool. It would be cool if VS could use WiX syntax as it’s internal format, but I suspect that’s not likely to happen since it would tie future development of the two together in some ways that would probably discomfit both WiX and Visual Studio. But an open source converter from the vdproj format to WiX would definitely be a cool thing!

One side effect of this change is that users of C# Express can now load and build the entire NUnit solution. I’m hoping this will gain us a few volunteers.

Jamie Cansdale – of NUnit Addin and TD.Net fame – did the initial implementation of the WiX scripts and I made additional changes and figured out how to use the the NAnt tasks so it could be made part of our standard build.

It’s unfortunate that the WiX tasks for NAnt come without documentation. By reading the source, I was able to construct the commands I listed below, which I’m posting in the hope that they will be of help to somebody.

<candle out="${wix.work.dir}/" exedir="${wix.dir}">
  <defines>
    <define name="ProductVersion" value="${package.version}" />
  </defines>
  <sources basedir="${project.install.dir}">
    <nclude name="bin.wxs" />
    <include name="nunit-gui.wxs" />
    <include name="doc.wxs" />
    <include name="tests.wxs" />
    <include name="samples.wxs" />
    <include name="NUnit.wxs" />
  </sources>
</candle>

<light exedir="${wix.dir}"
  out="${project.package.dir}/${msi.file.name}" 
  locfile="${wix.dir}/WixUI_en-us.wxl">
  <sources>
    <include name="${wix.work.dir}/NUnit.wixobj" />
    <include name="${wix.work.dir}/bin.wixobj" />
    <include name="${wix.work.dir}/nunit-gui.wixobj" />
    <include name="${wix.work.dir}/doc.wixobj" />
    <include name="${wix.work.dir}/samples.wixobj" />
    <include name="${wix.work.dir}/tests.wixobj" />
    <include name="${wix.dir}/wixui.wixlib" />
  </sources>
</light>

You’ll find our WiX scripts in the latest version of the NUnit source on SourceForge.

Charlie

Comments

  1. Bob Arnson Says:

    Though your comments about missing tasks doc are fair, there are several build files in the WiX source that use the tasks. So code-spelunking isn’t strictly necessary. 🙂

  2. Charlie Says:

    I know it’s hard to find the time for docs and I’ve been guilty of the same thing myself, so you have my sympathy.

    Finding the build files that use the tasks appears to be harder than you think. At least, I can’t find them. 🙂 Are they in V3, perhaps?

  3. Rob Mensching Openly Uninstalled : Thursday Night &quot;Deployment Dinner Discussion&quot; with Charlie Poole. Says:

    […] Tonight I traveled to Anthony’s Beach Cafe in Edmonds, WA to have dinner with Charlie Poole.  Charlie is the active maintainer of the NUnit project.  He contacted me (via my blog, IIRC) and we set up tonight’s meeting.  I expected he wanted to meet because NUnit is now using the WiX toolset too. […]

  4. RLovelett Says:

    I like the fact that you can call <candle> and the same for light in NAnt. My question, kinda goes along with what your saying no documentation, how do I install those tasks? I’m using a nightly build of NAnt and the RC of NAntcontrib and I cannot seem to find that info anywhere? How did you install those tasks? Was there a how-to guide that you used?

  5. Charlie Says:

    I simply copied the task assembly to my nant bin\tasks\net directory. The assembly is Microsoft.Tools.WindowsInstallerXml.NantTasks.dll.

  6. edwardt_tril Says:

    I also tried created WiX under the toolds folder and unzip the bin into it; then add
    in the .build file

    but I get the following when calling nant create-msi ….. :
    r extensions.

    BUILD FAILED – 2 non-fatal error(s), 0 warning(s)

    C:\Automation\ThirdParty\Nunit\src\nunit.build(563
    Property evaluation failed.
    Expression: ${project.package.dir}/${msi.file.name
    ^^^^^^^^^^^^^
    Property ‘msi.file.name’ has not been set.

    what am I missing?

  7. Charlie Says:

    The target create-msi is no longer intended for direct use from the command line. Instead use package-msi, which builds nunit first, then calls create-msi.

    More info: I originally was creating the msi as a separate manual step, but I found that I continually forgot to rebuild nunit so I changed this. Create-msi is a vestige of the older approach. I’ll either make it work correctly or move it to the include file so it isn’t listed by -projecthelp.

    Charlie

Add a Comment

You must be logged in to post a comment.