Ok, here's one to dust off the everything-you-wish-you-didn't-know-about-COM-interop cobwebs.
We're integrating some .NET code into our legacy COM-based system, and we're having trouble with side-by-side support - that is, having multiple versions of the application installed on the same machine. The .NET components are used by an out-of-process COM client. These components expose COM-visible interfaces exported and registered with regasm. The cross-process calls are marshalled using the universal marshaller. Our problem arises when we try to get the side-by-side support. The components themselves don't have a problem, but the type libraries do, and the universal marshaler seems to require that type libraries be present (why is that? can't it just call IDispatch.GetTypeInfo?). Anyway, here's what didn't work for us: * If the type library is registered with an absolute path, then we need to roll the version number of the assembly each release, as the type library version is derived from the assembly version. No problem, except...the registry entries for the interfaces point a *single* version of the type library. We'd have to roll the GUIDs on all the interfaces each release. * The COM side-by-side ".local" strategy doesn't seem to apply to type libraries. * If the type library is registered with a relative path, when the universal marshaller reads the type library, the registry entry for the type library gets 'corrected' to an absolute path. I'm guessing this comes from the LoadTypeLib API call. Ugh! So how are you supposed to get side-by-side support for .NET components in interop scenarios? Any ideas? Any amount of custom registration work will be tolerated! Thanks, kevin =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
