MSI Setup projects in Visual Studio : 2005 != 2008

I’ve been working on a project that is a shared plugin to Office 2003. I was writing this in Visual Studio 2005, but for a variety of reasons (not least of which was having a tidier dev environment), I decided to move this onto a convenient VM which happened to have a lot of the things I needed (MOSS, a domain controller, AD, exchange).

Unfortunately, it also had Visual Studio 2008 too. I didn’t think this would be a problem, though, and so I when I opened the project on it for the first time and it asked me to upgrade the project to 2008, I was happy do. I didn’t think there’d be a problem.

Well, during development, there wasn’t. Whenever I went to test my MSI installer, though, I started to have problems. Installation kept failing and I kept getting the error:

Error 1937. An error occurred during the installation of assembly ‘Extensibility,Version=”7.0.3300.0″,Culture=”neutral”,PublicKeyToken=”B03F5F7F11D50A3A”,ProcessorArchitecture=”MSIL”‘. The signature or catalog could not be verified or is not valid. HRESULT: 0x80131045. assembly interface: IAssemblyCacheItem, function: Commit, component: {8C306A7E-AE8E-14F0-4168-C43060985CF4}

This was surprising. Extensibility.dll isn’t one of mine – it’s a Microsoft one that should’ve been in the Primary Interop Assemblies for Office. Anyway, it’s not one of mine, it hadn’t changed, and it was signed correctly. So what gives?

My first investigations using the error code ‘0x80131045’ suggested that the problem lay with the operating system, and offered some pretty terrifying solutions. I tried them anyway – they didn’t work.

Next, I wondered if the old version of the MSI installer (compiled on Visual Studio 2005) would work on my dev machine – it did. I began to wonder if I my new MSI installer would work on another machine – it didn’t. The old version still worked, and my new MSI wouldn’t work on either machine. I was comfortable with the conclusion that the problem wasn’t the OS.

Compiled with
VS2005 VS2008
Old Dev Machine OK Failed
New Dev Machine OK Failed
Random other Machine OK Failed

Well, after that I consided the Installer project in Visual Studio. This is the thing that makes the MSI with my DLL in it. Perhaps upgrading the project for Visual Studio 2008 had screwed something up? Well, it sure looked the same, and looking into the actual code showed only minor differences. In fact, other than declaring themselves to be for different versions of Visual Studio, the two projects were identical. So I don’t think that the upgrade screwed anything up.

This left me in an unenviable position. I couldn’t see anything wrong with the installer for the latest version of my code – but it didn’t work. The error being reported back was clearly wrong – the assembly I was installing was correctly signed.

The only conclusion that I could come to was that packaging the MSI in Visual Studio 2008 was producing a different result than Visual Studio 2005, and that my only option was to merge my code back into the old VS2005 version of the project.

Fortunately, WinMerge is great.

Anyway, I did this. I could now compile my new code on my old VS2005 Development system, and then try installing on my MSI on my VS2008 system. It worked perfectly! Sadly, I’ve now got a fair effort to go to to build a new stable development environment.

So the upshot of all this is that although they might look nearly identical, and in fact might be nearly identical, there are clearly other differences in the output MSI installers for Visual Studio 2005 and Visual Studio 2008. If you get the same sort of error as me, consider using Visual Studio 2005.

Advertisements
MSI Setup projects in Visual Studio : 2005 != 2008

2 thoughts on “MSI Setup projects in Visual Studio : 2005 != 2008

  1. Julien says:

    I’ve had trouble with MSI deployment projects in VS2008 as well. One key difference is that in VS2008 MSI’s don’t un-inlstall in the same way. Someone decided that the ‘RemovePreviousVersions’ flag aught to have an entirely different meaning in VS2008.

    I’ve been able to work around that problem, but another difference seems to be in the way custom actions are launched for 64 bit apps.

    I am almost at the point where I will need to roll back to VS2005 for my installer. Quite a disappointment.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s