Today, in the "real" world, I was working on a mechanism to allow us to write VS.NET Automation model code in C# and then call it, through .NET's COM Interop mechanism, from ATL/C++ COM unmanaged components which contain a VSIP code. Let me explain. I have been doing some work integrating an environment with Visual Studio .NET. There are really two major choices: use the automation model of VS.NET or pay $30,000 and join the Visual Studio Integration Program (http://msdn.microsoft.com/vstudio/vsip/default.asp) and get the code and COM Interfaces of VS.NET. There are many reasons why you have to choose option 2. The automation model allows you to have what is known as an "add-in" and can only do certain things. An add-in is actually a COM Component that implements the IDTExtensibilty2 interface. Using VSIP code, however, allows you to do just about anything. You become an actual "part" of VS.NET, through the use of what are known as Packages, or VsPackages. VSIP allows you to add your own splash screen or your own editor, or heck, even implement your own language. Its quite powerful but amazingly complex. It is hundreds of thousands of lines of code and based on tons and tons of COM Interfaces. The base example to just put up a new project type takes 66 files!!
I am using VSIP to have a COM component that implements IDTWizard. It turns out that lots of things in VS.NET are actually Wizards. My wizard calls one of VS.NET's wizards to launch a C# project that suppplies a WinForm and populates it with a base implementation of code for something. And I add toolbar tabs with custom tools and I add menus. A lot of this is of course better done through the Automation model. So I have been going through this laborious process of using C# to work out all the automation code I want, tweaking it, and then "porting" it all to C++/ATL COM code for inclusion in the ATL COM component that implements VSIP and IDTWizard. Yikes! I had forgotten how hard and time consuming COM was! I haven't done anything but Managed code for 2 years and had gotten used to how much easier it all is.
So what I wanted was a way to do my automation stuff in C# and then call the managed code through COM Interop. So I put everything in a C# class and then signed it. I then ran regasm /tlb on it to generate the CCW, register COM gunk in the Registry and generate the Type Library. I then imported the TLB into the C++ code and proceeded on to party on. Or so I thought. It turns out that, by default, COM Interop, does not expose type library information and worse than that, generates only IDispatch late-bound interfaces! I'll post why later but it's wrong, wrong, wrong. Late bound IDispatch interfaces are a legacy of VB3 and have no place other than Scripting languages in a modern world. I had to decorate the class with an attribute to "force" it to generate type info and generate a dual interface. Yeck.
Then it got worse. The DTE object in VS.NET Automation is full of bugs, missing functionality, and incomplete documentation. And there was still getting the types right across the boundary...More tomorrow...
10:13:51 PM 
|
|
