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.

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.