Another scenario where a managed add-in for VS 2005 or higher still requires the ComVisible(True) attribute (apart from the Connect class that I blogged about in the last post) is when creating toolwindows with the EnvDTE80.Windows2.CreateToolWindow2 method: if you move the ComVisible(True) attribute from the AssemblyInfo file to the Connect class (which is actually the class that needs it) then the usercontrol class passed to the CreateToolWindow2 is not visible to COM and in these circumstances the CreateToolWindow2 method doesn’t return the created usercontrol as last parameter, and EnvDTE.Window.Object (which should return the usercontrol) is also null.

I had heard reports from people that said that when the usercontrol resided in another assembly rather than in the own add-in assembly, the CreateToolWindow2 didn’t return the instance of the usercontrol. Now the explanation is clear:  usercontrols in Windows Control Library projects have the ComVisible attribute set to false in the assemblyinfo file, while usercontrols in the add-in project have it set to true in the assemblyinfo file. So, the problem is not where the usercontrol resides, but whether the usercontrol is visible to COM or not.

Since managed add-ins should get rid of COM semantics, I have filed another bug report to Microsoft:

EnvDTE80.Windows2.CreateToolWindow2 doesn’t return in the last
parameter the hosted usercontrol if ComVisible attribute not set to true
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=467084