In the last years I created Windows Installer packages (MSI files) using various tools. Now I’m working on the installer for NUnit 3 and we’re using Windows Installer XML (WiX) version 3. I’m writing this post to collect links to interesting resources for creating setups using WiX.

• Windows Installer SDK.aspx) in the MSDN library
• Windows Installer 4.5 SDK: contains tools like Orca or the Windows Installer documentation as CHM file.
• Windows Installer XML (WiX): a toolset that builds Windows Installer packages from XML source code.
• Understanding Microsoft Installer Logs
• Automated Install Testing - MSI Validation
• Conditional Statement Syntax.aspx)

For getting started with WiX:

• Authoring your first .wxs file
• Creating a simple setup (using Votive)
• WiX Tutorial (by Gábor DEÁK JAHN)
• From MSI to WiX (by Alex Shevchuk)
• MSI Validation in WiX (by Derek Cicerone)
• Adding and Customizing Dialogs in WiX 3

Since version 2.1, both the Console runner and the GUI runner of NUnit can load tests from multiple test assemblies. The NUnit documentation contains more information about this feature. Still there can be one or more obstacles when you use multiple test assemblies.

Adhoc projects

The Console runner accepts more than one test assemblies as command line arguments. If you use the GUI runner you can add test assemblies by using “Project => Add Assembly…”. But the test assembly must be in the same directory as the assembly which has already been loaded, otherwise NUnit can’t find the file and aborts with a FileNotFoundException.

Creating NUnit projects

You can create a new NUnit test project by clicking on “File => New Project…”. You can add assemblies to the project by clicking on “Project => Add Assembly…”. Using NUnit test projects the test assemblies can be in different directories.

One configuration file for all test assemblies

NUnit can load configuration files for test assemblies even for class libraries. With NUnit test projects you can use just one configuration file. You can change the name of this file in the NUnit project editor, but you can’t specify a file path, just the file name. The configuration file must be located in the same directory as the project file.

Last week I watched some videos about ASP.NET MVC. Rob Conery creates in episode 11 of the “ASP.NET MVC Storefront” series an ASP.NET MVC Component. Using components you can call an action method of a ComponentController and insert the rendered result into the view. Mike Bosch explains this concept in a blog post.

In ASP.NET MVC Preview 4 ComponentController has been removed and the method RenderComponent which called the ComponentController action from the view has been replaced by the method RenderAction which can call an action of a normal Controller. Since this concept conflicts with ”Separation of concerns”, Microsoft doesn’t intend to include this feature in the RTM version of ASP.NET MVC.

ASP.NET MVC Futures

Therefore the ASP.NET MVC team moved the RenderAction method to the ASP.NET MVC Futures which consist of the assembly Microsoft.Web.Mvc.dll. This assembly contains features and prototypes which haven’t been included in the RTM version yet. The release for ASP.NET MVC Beta 1 can be downloaded from Codeplex.

In order to use ASP.NET MVC Futures in your MVC project reference the assembly “Microsoft.Web.Mvc.dll” and insert the following line into the web.config to include the namespace “Microsoft.Web.Mvc” in all your views automatically:

SubControllers from MvcContrib

SubControllers can be used for similar purposes like RenderAction or Components. Matt Hinze presented this feature from the MvcContrib project in a blog post. SubController actions can be included in the view data as delegates. The views can then invoke these delegates and start the rendering of the SubController action view.

The host controller can pass objects to the SubController. Matt Hinze explains this feature in another blog post.

I released a new version of the RowTest Extension. I made following changes:

• The description of a Row attribute will be copied to the created test case.

You can download it from the RowTest Extension page.

Roy Osherove wrote a new tool, called Depender. It inspects the types within an assembly and tries to find possible testability problems and places where you can already use seams to inject your own implementation. If you’re not familiar with the concept of seams you might want to read Michael Feather’s book “Working Effectively with Legacy Code”. You can extend Depender by writing your own dependency rules.