Search code examples
.netcomregasm

How does one configure the COM version to use of a .NET assembly registered by RegAsm.exe?


regasam.exe registers a .NET assembly for use by COM by creating version-dependent registry keys:

HKEY_CLASSES_ROOT\CLSID\{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}
|- InprocServer
   |- 1.0.0.0
   |- 1.0.0.1
   |- ...

When there is more than one version registered, which version is the default version?

Since the registered dll is mscoree.dll I assume that the settings are read and interpreted by it, therefore the question could be rephrased as:

How are the keys interpreted by mscoree.dll and how can one select the default version to use?

Useful information


Solution

  • Pretty doubtful that this does what you hope it does. These are the version-dependent registry keys, covered by this MSDN article. Do note the topic that it is part of, it talks about side-by-side execution for [ComVisible] .NET assemblies. It solves a CLR versioning problem, not a COM server versioning problem.

    Prior to .NET v4, there was a problem with the RuntimeVersion registry key that's written by Regasm.exe. A big problem back when the CLR version was still changing rapidly and one that needed to be solved first in .NET 1.1. Since there could be only one CLR version loaded, the RuntimeVersion registry key value needs to match the CLR version. That's very difficult to guarantee, a COM server could not control the loaded CLR version if it was already loaded. By another COM server for example.

    The version-dependent sub-keys permit registering another version of the COM server that works on another version of the CLR. Implied is that the RuntimeVersion keys will have different values. The CLR will enumerate the keys and look for one that matches its loaded version.

    Still not an ideal solution, failure was common when the very first COM server asked for a low CLR version. Which required a .config file for the client app to force a higher version. A workaround but not a pleasant one. .NET 4.0 provided a more solid solution with its in-process side-by-side CLR support. Permitting more than one CLR to be loaded and each COM server to run with its desired CLR version. So these keys are not really needed anymore. And should not be used.