No doubt there are entire teams of people dedicated to understanding the Microsoft Windows installer system (.msi files) but for me it is just a means to an end. I didn’t find it a particularly accessible technology so from the point of view of someone interested in deploying the output from a Visual Studio 2008 project onto end user systems, here are a couple of the gotchas I came across.

First, there is a registry key on the end user system which should record the location into which the installer deployed the output of your project (maybe the end user choose this through an install wizard). I mistakenly assumed that Microsoft’s Visual Studio installer project would automatically handle the basics like this, but no. The answer was in this recent blog post: Using a Post-Build Script to set the InstallLocation property in VS Setup Projects – the author includes a handy script which you can just drop into your project to fix this problem.

The second problem was an error message I received when installing my project:

Error 1001. Unable to get installer types in the […] assembly. Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.

Although missing DLL dependencies and pre-requisites are already published known causes for this problem, that didn’t quite reveal the true cause in my case. The reason I experienced this error is because:

1) I had set up a custom install action in my main project assembly (to add the install folder to the system path)
2) I had redirected the primary project output to an alternative folder (rather than the default “Application folder”)

So the quick fix was to add a second project output to the installer so it now puts the DLL into my alternative folder as well as the main output folder (along with all its other DLL dependencies). Hopefully there is a neater way to do this which doesn’t clutter the end user’s system with two copies of the same file but I’m in no rush to find it because I just want to get on with some real development work rather than trying to understand VS2008 installer project limitations.