Creating and deploying Managed COM add-ins with VB.NET 2005 – Part VI
This is the 6th post on the subject and You can find the earlier post at the following links:
Part I – Introduction
Part II – Connection
Part III – Notes Tool -Workbooks
Part IV – Notes Tool – Worksheets
Part V – Notes Tool – Main functions
Preparation of the managed COM add-in and some house cleaning
Before moving on to the next step we need to prepare the managed COM add-in and also do some ‘house cleaning’.
#1 Remove dependencies
Open the folder ‘Detected Dependencies’ and exclude all files except Microsoft .NET Framework. The easiest way is to right click on each file and select the option Exclude. By default shared add-ins refer to some namespaces which may or may not be used. However it’s beyond the scope of this post to discuss it in more detail. The unused references can be viewed through the property window and via the button ‘Unused references’.
#2 Uncheck the option ‘Register for COM Interop’
Right click on the project name in the Solution Explorer window and select ‘Properties’. On the Compile tab scroll down to the bottom and uncheck the option.
#3 Sign the assembly
Select the Signing tab in the properties window and apply or create a new strong name key file (I will cover Strong Names in the next post).
#4 Make sure that the final version of the add-in has been saved and compiled.
The following picture shows how the project looks in the Solution Explorer windows on my developing computer:
The mscoree.dll “hell”
Traditional COM add-ins, for instance developed with VB 6.0, are fully referenced in the Windows registry while managed COM add-ins are not. By default for all managed COM add-ins the InprocServer32 enter for each of them in the HKEY_CLASSES_ROOT points to one file – mscoree.dll. We don’t need to dig into the registry to get a confirmation of it. Via Excel’s UI it becomes clear as the following picture shows:
There are two important major issues that need to be resolved due to the mscoree.dll ‘hell’:
– All managed COM add-ins refer to the mscoree.dll and therefore if anyone of them does not work properly all managed COM add-ins will be ‘blacklisted’ and disabled by Excel.
– The mscoree.dll cannot be digital signed as it’s a systemfile which has a negative impact when it comes to the security.
The COM Shim Wizard
The following articles at MSDN are important for three reasons, they provide us with the Wizard tool itself, a technical detailed background information is given (especially in the first article) and how to use the tool:
Isolating Office Extensions with the COM Shim Wizard (For VS.NET 2003)
Isolating Microsoft Office Extensions with the COM Shim Wizard Version 2.0 (For VS.NET 2005)
The tool is a Microsoft Visual C++ Active Template Library (ATL) COM DLL and it creates a standard COM DLL (that is an unmanaged!) which acts as a ‘proxy’ to the managed COM add-in. The Wizard provides us with a user friendly interface which guides us through the steps in a simple way (we don’t need to know C++ to create and handle the output).
What the generated standard COM DLL actually does is to:
– Make sure that the CLR Loader load the CRL in the .NET Framework
– Create a new application domain in which the managed COM Add-in is loaded into.
– Create an instance of the managed COM add-ins class that implements the IDTExtensibility2 interface.
– Act as a ‘bridge’ between Excel and the managed COM add-in.
‘Shimmed’ managed COM add-ins are isolated from each other as they don’t share the application domain with any other ‘shimmed’ managed COM add-in. The value for the InprocServer32 for the ‘shimmed’ COM add-in in Windows registry is now the name of the generated standard COM DLL. With a standard COM DLL as a ‘bridge’ we are also able to digital sign the file.
If we want to add some additional information into the standard COM DLL file we can do it by locating the ‘*.rc’ file under the folder Resource Files in the Solution Explorer window. Make sure that the final version of the standard DLL file has been saved and compiled.
It should be noticed that the tool is not supported by MSFT.
Andrew Whitechapel et al at MSFT have made a great work with the COM Shim Wizard and also with the documentation for it.
However, I’m having difficulties to see any advantages with the above solution compared with developing a similar standard COM add-in with VB 6.0:
# 1 The necessary solution with a standard COM DLL put an extra ‘layer’ between Excel and the ‘shimmed’ managed COM add-in which has a negative impact on the performance (Excel call the standard COM DLL which in return call the underlying ‘shimmed’ managed COM add-in and reverse).
#2 Standard COM add-ins developed with VB 6.0 share the same memory area with Excel which improve the performance (so called In-Process communication). With a ‘shimmed’ managed COM add-in there will be an additional performance penalty due to the isolation by loading the ‘shimmed’ managed COM add-in in its own application domain. If I understand it right (please correct me if I’m wrong) ‘shimmed’ managed COM add-ins and Excel runs in different memory areas (so called Out-Of-Process communication).
I managed to find a good online source that describe the Application Domain:
Application Domain FAQ
In the next post I will discuss security in terms of using strong names and digital signing code with Microsoft Authenticode.