COM Interface Collection Download Sequence

Question

There is a very strange problem with the assembly link and a download problem that I encounter with my Outlook add-on. Here is the detail (long story :)):

I have an old Outlook addin written and built using .Net 1.1. The addon is downloaded using unmanaged pads to its own application domain. It works fine with .Net 2.0, even if 1.1 is not present on the user machine.

Addin uses the custom Outlook interconnect build created by VS 2003 against Outlook 2000, and after that the rebuild will be heavily named (like my addon).

In the addin project, I refer only to this custom interop assembly, not referring to official MS interop assemblies.

When this addin is used in an environment with Outlook 2007 and .Net 2.0, where the official MS interop assemblies are installed in the GAC, for some reason I can see that addin downloads and uses them.

In the code for the Connect class, I have a using directive:

using Outlook; 

which is the namespace of my custom interop assembly.

In Connect ctor, I have these lines of code (added for testing purposes):

 Assembly.LoadFrom(PATHTOMYASSEMBLY + "Interop.Outlook.dll"); Type type = typeof(Outlook.ApplicationClass); logger.Debug("Outlook.Application full type is: {0}", type.AssemblyQualifiedName); 

It is output:

Full view of Outlook.Application: Outlook.ApplicationClass, Interop.Outlook, Version = 9.0.0.0, Culture = neutral, PublicKeyToken = 4cfbdc5349cf59d8

This is exactly what I expected.

The problem is that when OnConnection (object application, Extensibility.ext_ConnectMode connectMode, addInInst object, ref System.Array custom), I see in the log (I have a hook to the AssemblyLoad event of the current domain), which is also loaded by MS interop:

 private void app_domain_AssemblyLoad(object sender, AssemblyLoadEventArgs args) { Assembly loadedAssembly = args.LoadedAssembly; logger.Debug("Assembly {0} is loaded from: {1}", loadedAssembly.FullName, loadedAssembly.GlobalAssemblyCache ? "GAC" : loadedAssembly.Location); } 

Output:

Montage Microsoft.Office.Interop.Outlook, Version = 12.0.0.0, Culture = Neutral, PublicKeyToken = 71e9bce111e9429c - downloaded from: GAC

My OnConnection method starts as follows:

 public void OnConnection(object application, Extensibility.ext_ConnectMode connectMode, object addInInst, ref System.Array custom) { Type type = application.GetType(); logger.Debug("OnConnection application object full type is: {0}", type.AssemblyQualifiedName); Outlook.Application applicationObject = (Outlook.Application)application; 

It is output:

OnConnection application object type: Microsoft.Office.Interop.Outlook.ApplicationClass, Microsoft.Office.Interop.Outlook, Version = 12.0.0.0, Culture = neutral, PublicKeyToken = 71e9bce111e9429c

This is really strange, as you can see that on the next line I can successfully apply to Outlook.Application without any problems.

I checked with Reflector, and my assembly in no way refers to the Microsoft interop assembly. Same for my Interop.Outlook.dll.

So, does anyone know what is going on? What is the answer to these questions:

• Why does it download Microsoft assemblies at all?

• How can one distinguish between unrelated classes / interfaces defined in different assemblies?

NOTE. I created a new addin, very simple, which does nothing, just loads. I could reproduce the problem, so really, does anyone know how the CLR decides what to do and where it comes from. In addition, there is another place in the GAC (registry ???), where is the connection between the COM object and the required interaction?

Answer 1

I think I found the answer to your problem in Microsoft Primary Interop Assemblies . In Visual Studio, PIAs are handled differently:

When a user tries to add a reference to a type library with a registered PIA, Visual Studio will silently use the registered PIA instead of re-importing the type library using Tlbimp. This ensures that the PIA is used whenever possible.

This means that when you add a link to your own IA in the project, Visual Studio checks for the PIA for this COM object. Primary PIAs are registered under the following key:

 HKEY_CLASSES_ROOT\CLSID\{0006F023-0000-0000-C000-000000000046}\InprocServer32\12.0.0.0 Assembly="Microsoft.Office.Interop.Outlook, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C" 

From what I understand that unregistering a PIA using the regasm tool should remove the key and re-adding the link to your own IA should give the expected result.

However, Microsoft does not recommend the use of custom IAs if there is a PIA. I don’t understand the exact reason for this, but I suppose that this could be due to optimization of marshaling and unique type definitions.