How to apply .NET app.config to out-of-proc COM server?

We have a legacy application with a COM-based plugin system. To register a native plugin, DllRegistryServer is called, which registers the COM classes and adds some registry information for bookkeeping. For .NET components, we have a COM server written in C# that calls RegistrationServices.RegisterAssembly. For maximum compatibility, this C# dll targets .NET v2.0. The (native) plugin registrar CoCreateInstance()s the C# server.

Since .NET plugins may target .NET v4.0, we have the following in the application config:

<?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 issue is that COM registration needs to be run elevated in Vista or 7, so the plugin registrar is created with the COM Elevation Moniker, which runs it out-of-proc in the system surrogate (dllhost.exe). This creates a problem, because the application config 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 the v4.0 runtime, or manually hosting the CLR.

How do I apply the application config to an object created by the COM Elevation Moniker?

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

Look in the section "Managed COM Component". Aside from the relatively straightforward 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 reg-free manifest (which cannot be extended to contain a SupportedRuntimes entry), runtime activation will look for a configuration file next to the assembly containing the COM visible class

Can you try adding Plugin.dll.config to one of your plugins and see if this resolves the issue? The included article has some specific examples below the section I mentioned, but for all extent and purposes it looks like you can copy/paste what you have for testing at least (to be a bit more elegant there are pieces you do not need depending on your configuration).

Given that this is from the CLR team, my assumption here is going to be that your choices are the reg hack or the config file.