When I build the Visual Studio add-in for Help Builder, somewhere along the line just before releasing the final version of Help Builder 4.0 I decided to bump the assembly version number to 4.0 from 1.0. I didn’t really think much of this at the time.
Today however I was testing the auto-update process on one of my test machines. This machine still had an older version of the Add-In running and when I updated the add-in DLL VS.NET puked on the new version of the DLL even though the interface has remained constant.
So, my first thought was that the registration didn’t grab the right version, so re-registering the add-in and the .NET COM object should take care of this issue. It didn’t.
Ultimately I had to dig into the registry to see what’s going. The ProgId for the add-in is:
HelpBuilder.vsAddin
However, internally the .NET class is mapped to HelpBuilderAutomation.HelpBuidlerVsAddin which is how this COM object actually registers in the registry. This is courtesy of the quirky behavior of Codebase type registration of a .NET assembly for COM interop.
From here I grabbed the ClassId and searched back to the actual ClassId entry in the registry. To do this grab the ClassID and do a find on this ClassID string.
Looking at the ClassId entry I could see the problem in the InprocServer32 section. The component had registered itself twice with the two different version numbers. Both version 1.0.1 and version 4.0.0 showed up here. Worse Version 1.0 pointed at a file in an old location where I had originally installed Help Builder for testing.
Even though the component got re-registered it was using the 1.0 version instead of the current and last registered 4.0 version. For some reason VS.NET is picking the first item in the list and so loaded V 1.0 of the component. To fix the problem I removed the version 1.0 entry and all started working immediately.
So the question here is what does the .NET runtime do to resolve the version number when invoking a COM object? Actually the real question is why does .NET even allow anything version related in the COM accessible entries in the registry? A COM object can only instantiate one version so there’s no chance that a COM client can get a different version anyway.
Part of the problem here is that I didn’t unregister the old component before installing the new one which caused this problem. Things would have even been OK if there were two versions as long as the versions were pointing at the same directory, but in this case the old version was in a different directory altogether which caused VS to choke.
Moral: Be real careful when you register your .NET COM components and either always un-register them before re-registering a new version, or at the very least make sure that it doesn’t go into a different directory.
I'm still not 100% sure what this will do to client installs, which is why I'm posting this here to at least have a goto link that explains the fix. Eeek... This should only be a problem for beta testers however and then only if the install directories changed.