When COM Registration fails in an MSI (vsdraCOM has no affect)

  • Article

 Summary

In this weeks’ installment of I hate COM, lets talk about a frustrating problem I’ve been having (turns out I had this problem when I wrote my Media Center Front Panel Display but found a different workaround I mention below). It would be nice if there were a KB article on this topic, but there isn’t and I don’t know why.

Say you are exposing a .NET component as a COM component. Not to uncommon. I already do this in my Outlook2OneNote add-in as well as my Media Center Front Panel Display. In both these cases I am implementing a COM Interface: Extensibility.IDTExtensibility2 for Outlook2OneNote and EHLib.IMediaStatusSink for my Media Center Sink.

In Outlook2OneNote the project structure looks like

  1. Project 1 – contains the guid and COM Inteface
  2. Project 2 – inherits from a class in Project 1 and is marked for COM registration
  3. Setup – Primary Output from Project 2’s Register value is vsdraCOM

In MediaCenterSink the project structure looks like

  1. Project 1 – contains the guid and COM Inteface and marked for COM registration
  2. Project 2 – contains the code for the Sink
  3. Setup – Primary Output from Project 1’s Register value is vsdraCOM

In both cases the MSI does not register the Primary Output for COM Interop. It’s not obvious why this fails, but I spent many hours trying various things (you know how trial and error is when you don’t have an understanding for what is going on or what is broken right?). So you can imagine how frustrating this is. Even more frustrating is when this happens to you twice in the course of a few months.

Approach 1: Custom Action

Well, google had no answers for me except a bunch of other people who were saying “COM Registration during install using MSI is broken…” or “vsdraCOM doesn’t do anything…” etc. The only solution that I found was to write some code in the Primary Output project like so (you need a similar Uninstall and Rollback override as well):

public override void Install(System.Collections.IDictionary stateSaver)
{
base.Install(stateSaver);

try
{
RegistrationServices regSrv;

// Register the assembly
regSrv = new System.Runtime.InteropServices.RegistrationServices();

if (!regSrv.RegisterAssembly(
this.GetType().Assembly, AssemblyRegistrationFlags.SetCodeBase))
{
throw new InstallException("Failed to register componenet for COM interop");
}
}
catch
{

}
}

And then create a Custom Action in your MSI that points to the Primary Output for Install, Uninstall and Rollback. This actually works pretty well, and I was happy with it.

Well when this problem happened for the second time just this week when I switched my Outlook2OneNote project structure from being a simple Project that had all the logic to one that inherited from another class in another project I started wondering and thinking this has to be a bug. Well using my super hero powers I tracked this problem down and found a better work around.

Additionally, I've been told that custom actions should be avoided for a number of reasons. One good reason is that if you ever use the MSI in the future to upgrade your assembly, it will fail.

Approach 2: Simple workaround for bug

Rather than adding the Primary Output of the project that needs to be registered for COM Interop, do the following:

  1. In your setup project remove the Primary output from <Project Name> .
  2. Select your setup project, right click, select Add->Assembly
  3. Navigate to the bin/Release directory of your Primary project and select your dll
  4. Select the Assembly in the setup project and set the Register value to vsdraCOM

Summary

By adding your assembly directly to the MSI and not relying on the Custom Action workaround mentioned above, you can rely on the MSI to register your component for COM Interop.

BTW – IMHO, developing .NET components and exposing them as COM components is a nasty business and one that I NO LONGER ENJOY!!! I am writing this because it’s a bit therapeutic and I hope it helps someone else who is having this problem (rather than hurl my laptop against the wall).

update: I made some corrections to this post based on some feedback from Rob Mensching.