Using a .NET-2.0-targeted COM DLL in the GAC on a

Question

Greetings again,

Following up my previous question, I'm trying to maximize the compatibility of my C#-written Windows Explorer extension. In particular, I'm interested in making sure it works in an environment in which .NET 4 is installed and .NET 3.5 and below are not installed. One would think there's no problem, but apparently it's not so simple...

There are two problems. First, non-.NET-4-targeted assemblies flat out will not load with CLR 4 unless they have a .config file that specifies <supportedRuntime version="v4.0" />. Even trying to use ngen on them will fail without this .config file. But my DLL goes in the GAC. How do I get a .config file in there too? Others have asked the same thing, and reached the conclusion "well, I'll just make a static Settings class instead." Obviously I can't do that...

Second problem: When I register my DLL with regasm.exe, and then open up the registry to see what it wrote, I see RuntimeVersion = v2.0.50727 under its CLSID entry. This also prevents the DLL from loading. Only after I manually change the RuntimeVersion value to v4.0.30319 does the DLL load.

So what the heck do I have to make my installer do here? For the first one I have no idea. For the second, I guess I have to have the installer set the registry's RuntimeVersion manually to whatever .NET version is installed? That seems too wacky to be true...

Answer 1

.Net 2.0 - 3.5 and .Net 4.0 has two different GAC's, if I recall correctly.

"The size issue is partially solved with .NET 4 installer (x86 + x64) being 54 MB and not embedding full runtime installation packages for previous versions." - http://en.wikipedia.org/wiki/.NET_Framework

So if you install .Net 3.5, you get the previous .Net runtimes. This might be confusing with .NET 4.0, which does not include these previous runtimes. I believe this means you need to install .Net 3.5 runtime along-side .Net 4.0 to get <= .Net 3.5 runtimes to install into the GAC.

I also believe if you change the RuntimeVersion, you are getting the .DLL to install into the wrong GAC. It would be interesting, however, if this does work. I wouldn't trust it in a real-time environment, but it would be very interesting indeed.