How to use registration-free COM with TestStand

[Russell1]

We create several different test programs run by TestStand. The sequence typically calls a function in a .NET dll that in turn calls functions in COM objects. We would like to use registration free COM to isolate the programs from each other but I'm having difficulty making it work. I know that in principle the manifest file and COM objects could be put in the same directory as SeqEdit.exe but this is unacceptable. I was thinking that using the activation context might be a way to do it. For example in C#: ActivationContext.CreatePartialActivationContext(ApplicationIdentity, string[]). ApplicationIdentity is the application identity of SeqEdit and the string [] parameter contains paths and names of manifest files that describe the needed COM objects. The idea would be to load an activation context with the .NET dll called by the sequence so SeqEdit could find the COM dlls in the same directory as the sequence. I haven't gotten it to work yet. Any ideas?

[Josh_W]

Russell1,

I'm going to try to give as thorough description as I can, since many other users may not understand what you're asking about.

Normally, a COM server (ActiveX servers are COM servers) is registered with Windows via the registry.  Unfortunately, you can only have one version of the server registered at a time.  This is one of the reasons why TestStand (which is a COM server) needs a version switcher to change between engine versions.

There is a technology called "Registration-free COM" that allows an application to use a COM server without having it registered in the windows registry.  It involves creating manifest files for the COM server and for the application that is calling the com server.  These manifest files are used by the operating system when the application tries to call the COM server to find the server.  Usually the OS would go to the registry, but it will check the manifest files first.

The best reference on registration-free COM is an article on MSDN: Registration-Free Activation of COM Components: A Walkthrough.

A year or so ago, there was a TestStand customer who was interested in forcing some of their applications to use a certain version of a COM server; I was able to get this working for them. 

I tested the .NET and MFC TestStand user interfaces, and found that I could get registration-free COM working with both.  I found that two .manifest files needed to be created.

1. The first is a .manifest file for the COM server.  This was a straightforward process following exactly the instructions in the above walkthrough (Step 7).
2. The second is a .manifest file for the UI.  Since the TestStand UIs have their manifest files embedded in the application, I had to modify the .manifest file before building the UI, or use the .NET SDK tool mt.exe.

After creating both manifest files, I found that adding them was enough to make .NET calls to the COM server work correctly if the application and server were in the same directory. 

Unfortunately, I did not do any testing with having the COM server in a different directory.

---

Now, on to your question:

I just did some poking around on MSDN, and I have found the following information.

Note that after you have configured a .manifest file for your COM server, it is then referred to as an "assembly".  I am making an assumption here (but I think it's a reasonable assumption) that after this, the COM server can be used just like any other assembly.  Specifically, it will be searched for in the same way an assembly is searched for.

MSDN documents How the Runtime Locates Assemblies.  Note near the bottom of that page, if the assembly has not been bound to before, and it is not in the Global Assembly Cache (GAC), it will probe for the assembly.  From this I think the following are possible solutions.  Please note that I haven't tested any of them.

1. MSDN documents the Probing behavior.  Note that it will only probe in sub-folders of the current application root directory ([application base]).  Note that there is also some information at the bottom of the page about COM interop scenarios.  I think what it is saying is that if you already are in an assembly, and call a COM server, it will look in the same folder as that assembly for the COM server.  This might be a possible solution for you.
2. There is also an AssemblyResolve event that is fired if the CLR is unable to locate the assembly.  I don't know if this event is fired in the case that the COM server cannot be found, but if it is, you could then define your own way to search for the server.  I found this information in a blog post by Microsoft developer: https://blogs.msdn.com/junfeng/archive/2006/03/27/561775.aspx
3. One last possibility is to use an Application Configuration file; which is similar to a manifest file.  According to that page, there is an element called 'probing' that you can use with Windows 7 or Windows Server 2008 R2 when defining assembly binding to specify relative paths to probe for the assembly.

I honestly don't know if any of these possibilities will work.  Please let me know if you get it working or if you need some more help, and I'll do my best to assist you.

Message Edited by Josh W. on 02-04-2010 03:23 PM