Some days ago I received an angry complaint from a prospect of the trial version of my MZ-Tools add-in, who uninstalled it because, somehow, he didn’t want the add-in loaded at startup during the evaluation period but he wanted to load it manually from time to time… Anyway, it happens that my MZ-Tools add-in still uses COM-registration because it shares code and setup with the versions for VS.NET 2002/2003, and therefore is subject to the couple of bugs of the Add-In Managers of VS 2008 and 2005. Of course the blame ended on the Microsoft side but too late, I’m afraid. It is unfortunate to lose sales because of these little problems… so today I started to investigate the migration from COM-registration to XML-registration for the versions of MZ-Tools for VS 2005 and 2008. And after some hours of internal refactoring needed, the .AddIn file created, I was ready to debug the add-in, when I got:
“No such interface supported” (80004002)”
How could that be? I have spent years creating add-ins for samples and I never got that error. A search in Google returned no useful information. At first I thought that it was related to the fact that I didn’t want my add-in, which is written in VB.NET, to have a root namespace (for those of you using C#, in VB.NET you can set a project-level property with the root namespace and avoid writing it in each code file), because I don’t want my commands to be of the form “MZTools.Connect.MyCommand” but of the form “MZTools.MyCommand”, which is possible as I explained in this article.
After some minutes investigating, I discovered that my AssemblyInfo.vb file has the ComVisible attribute set to False, instead of the default True that the add-in wizard creates:
<Assembly: ComVisible(False)>
because it doesn’t make sense to expose to COM the classes of an add-in, except the Connect class. And here was the problem: while I had the <ComVisible(True)> attribute attached to the Connect class, when I removed the <Guid(…)> and <ProgId(…)> attributes, which are not required for XML-registration, I removed too the <ComVisible(…)> attribute, because I thought that it was not required for XML-registration, but it happens that it IS required, go figure! I think we’ll never get rid of COM in Visual Studio extensibility in a million of years, no matter how hard Microsoft tries to disguise it…
Oh man – thanks very much for writing this, it probably would’ve been several days until I realized about ComVisible. Thanks!!!
I rarely comment on these sorts of posts, but you just saved me a whole lot of time. Thanks.
Thanks Dude, I had exactly the same problem after I replaced my AssemblyInfo with a linked SolutionInfo. Without your help, I’d still be banging my mouse! er, well, you get the picture.
Thanks a lot, got the same error (I am writing my plug in using C#), but same thing. Just needed to check the “Make Assembly COM-Visible” in the “Assemby Information” window in the project properties.
Strangely, I am getting this error while loading Macros IDE. The Add-ins work just fine.