How do I set an unmanaged application's prefered CLR () at run time?

Question

I have an unmanaged application (MSACCESS.EXE), which dynamically loads various .NET assemblies (via COM interop).

Currently, the unmanaged application automatically initializes the .NET 2.0 CLR when the first assembly is loaded. Since I want to migrate (some of) the .NET assemblies to .NET Framework 4.x, I want the unmanaged application to load the .NET 4.0 CLR instead.

It is well-known that this can be done by providing the following *.exe.config file to the unmanaged application:

<configuration>
  <startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version="v4.0.30319"/>
  </startup>
</configuration>

This works. However, it requires creating modifying the user's MS Office installation (by creating a file in the same folder as msaccess.exe), which I'd like to avoid, because (a) it requires administrative permissions and (b) it potentially affects other, unrelated Access-based applications as well.

Thus, I'd like to set this supportedRuntime configuration at run-time, using VBA and/or (more likely) Windows API calls.

How do I modify an unmanaged application's "CLR preference" at runtime?

Alternative solutions that I have tried and ruled out:

Dynamically load the correct CLR via CorBindToRuntimeEx: This would solve my problem, but I can't get it to work with late binding. That is why I currently investigate alternative approaches.

All you have to do is use the correct version of Regasm.exe, it records the preferred CLR version in the registry. So no longer C:\Windows\Microsoft.NET\Framework\v2.0.50727\Regasm.exe like you used to but now v4.0.30319. — Hans Passant, Jun 15 '19 at 22:49

score 1 · Accepted Answer · answered Jun 14 '19 at 09:35

The <supportedRuntime> and useLegacyV2RuntimeActivationPolicy stuff is really only necessary if you either have mixed-mode assemblies (where, for backwards compatibility reasons, it will not load them in anything beyond the CLR 2.0) or 2.x assemblies trying to load 4.x ones.

If you have pure managed assemblies, then .NET 4's in-process side-by-side execution will ensure that both CLR 2.x and CLR 4.x can be loaded in the same process, as needed by assemblies. The only real problem you could run into is that an assembly loaded in the 2.x runtime won't be able to load a 4.x assembly; in that scenario you would still have to force the 4.x framework through configuration. Likewise, sharing data through remoting and AppDomains won't work for components running in different frameworks, though that's a fairly rare scenario.

How do I set an unmanaged application's prefered CLR () at run time?

1 Answers1