COM Shim Wizards for VS 2010

About a month ago I wrote a post  on compiling the COM shim for 64-bit where I was hoping to have a version of COM Shim Wizards working with Visual Studio 2010. Today I am announcing the coming out of COM Shim Wizards for VS 2010 … I am calling it "coming out" and not a binding word "release" simply because it is not a release. All I am going to do is attach an MSI package to this blog post and explain what you will get when you install this file on your machine. I am not promising any support - although I am not denying that, as long as I am interested in this area, I will try to fix issues if they are reported in the comments to this post. Again, this is not an official release from Microsoft but just something I have done in my spare time because long time ago I was fortunate enough to work with Andrew Whitechapel and Siew Moi Khor to start it all.

For the information on why it is important to isolate shared add-ins using COM shim please refer to this article. You can find here all the details why and how you need to digitally sign the shim and also how shim provides certain level of isolation for the managed add-in by placing it in a separate AppDomain.

There is a separate article explaining the architecture of the shimmed solution and also shows how to use the COM Shim Wizards to easily create shim around your existing managed add-in.

So, let's start enumerating the changes the COM Shim Wizards went through when compared to the one we had in the last release:

   * The MSI package attached to this post will install project templates for Visual Studio 2010 only. Notice that VS 2010 should be installed on the machine first. There is no option to install to VS 2008 / VS 2005.
   * Only the project template for AddIn Shim is now installed. Shims for RealTimeData and SmartTags were dropped – neither I or Andrew saw a lot of demand for these and we decided to not invest the required time into the required support.
   * When harvesting information from the assembly we have a new data field called "Image Version". This data is important. In particular if the image's version v2.0.50727 – the generated shim will use CLR 1.0 hosting interfaces, if the image's version is different – the generated shim will use CLR 4.0 hosting interfaces. I explain the nuances about hosting interfaces below.
   * Fixed the bugs in ManagedAggregator.cs and CLRLoader.cpp that could cause host application to not property shutdown (see the comment in the MSDN article regarding these bugs)
   * As in the last release, the created shim is a 32-bit native DLL. Please follow the steps outlined in the "Taking COM Shim Wizards to 64-bit" to compile a 64-bit version

CLR Hosting Interfaces

The way we host CLR is the only significant change in the code that is being generated by the AddIn Shim template. In the previous version of the shim we used what is called CLR 1.0 Hosting Interfaces – i.e. these are the hosting interfaces that were available in the initial release of .NET Framework 1.0

Read more: Misha Shneerson

Posted via email from jasper22's posterous