How to apply .NET app.config to COM server without compromise?

Question

We have an outdated application with a COM based plugin system. To register your own plugin, DllRegistryServer is DllRegistryServer , which registers the COM classes and adds some registry information for accounting. For .NET components, we have a COM server written in C # that calls RegistrationServices.RegisterAssembly . For maximum compatibility, this C # dll is for .NET v2.0. (Native) plugin registrar CoCreateInstance() C # server.

Since .NET plugins can focus on .NET v4.0, in the application configuration we have the following:

 <?xml version="1.0" encoding="utf-8" ?> <configuration> <!-- Load 4.0 if available, otherwise 2.0 --> <!-- http://msdn.microsoft.com/en-us/library/w4atty68.aspx --> <!-- http://msdn.microsoft.com/en-us/library/w671swch.aspx --> <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0" /> <supportedRuntime version="v2.0.50727" /> </startup> </configuration> 

The problem is that COM registration must be done in Vista or 7, so the plugin registrar is created using COM Elevation Moniker, which launches it outside the procedure in the system surrogate ( dllhost.exe ). This creates a problem because the config application is not applied to dllhost.exe .

We want to solve this problem without writing a custom surrogate, deploying two versions of the C # COM server, requiring v4.0 runtime or manually placing the CLR on it.

How to apply application configuration to an object created by Mon Elever COM module?

Answer 1

Referring to this, which you probably also read: http://blogs.msdn.com/b/clrteam/archive/2010/06/23/in-proc-sxs-and-migration-quick-start.aspx

See the "Managed COM Component" section. Besides the relatively simple hack to update the registry (which I would personally avoid, because sifting through reflection to find all your CLSIDs is probably not cool), I saw this bit of text:

If a managed COM component is activated through a manifest without registration (which cannot be extended to contain a SupportedRuntimes entry), runtime activation will look for a configuration file next to the assembly containing the COM visibility class

Can you try adding Plugin.dll.config to one of your plugins and see if this fixes the problem? The above article provides some specific examples below the section that I mentioned, but apparently you can copy / paste what you have for testing, at least (to be a little more elegant, there are parts that you not needed depending on your configuration).

Given that this is from the CLR command, my assumption will be that your choice is a reg hack or configuration file.