views:

398

answers:

3

We are using a COM Object automation model to make our application available to our customers.

They are using for the most part python to access our applicaton interface.

As we want to be able to install (not yet run, that's another issue) different versions of the application, we are changing our COM components to be regfree.

But that conflicts with the access from scripting languages through IDispatch automation since they need the entries in the registry.

Our approach is to create an application which manages the active version of our actual application. It lets the user decide which version he wants to have and it takes care of the registry entries.

What are the alternatives to our approach?

A: 

Well the answer is suggested by yourself. You can write an application which has complete list of all versions of COM components. Once a version is selected by user, you can call regsvr32 application to register that particular version.

Hemant
+1  A: 

There is a protocol within COM for doing this. If you version the Interfaces (and change the GUIDS for each version) you can install multiple versions. Microsoft does this with WORD etc.

It is possible to create a Word.Document.5 class which is specific to version 5 of the library, or just word.Document which will create an instance of the highest present on the machine. I'm not sure if this functionality is build into COM or needs to be impemented but it's worth looking into.

Toby Allen
The versioning solution is of course nice, but we decided that we don't want to change the identities for each version. And it doesn't solve the issue of accessing an older version of the application from a script.
PsiX
+1  A: 

Regfree COM objects can be accessed through the Microsoft.Windows.ActCtx object.

As for IDispatch automation requiring entries in the registry -- that's not strictly correct. I presume you're using the default ATL implementation, IDispatchImpl. We solved this solution by providing our own implementation, IRegFreeDispatchImpl, which used the activation context manipulation APIs in the manner suggested here to wrap all entry points into the DLL with an activation context activation/deactivation.

Eugene Talagrand