Reputation: 7285
I am currently developing an MMC snap-in but have hit a big snag - it's done using the .Net 4.0 framework; and MMC is loading a previous version of the runtime.
Using an older version of the runtime isn't really an option, as the entire project is written for 4.0 (so far 5000 LOC); this is merely a management front-end (fancy that :P).
I checked the MMC registry key and it has version v4.0.20506 there. I can't find any other MMC .Net interop configuration anywhere.
Any ideas?
Upvotes: 0
Views: 2540
Reputation: 66
Microsoft has since posted this article regarding MMC and CLR versions http://msdn.microsoft.com/en-us/library/windows/desktop/gg983006(v=vs.85).aspx Basically, you create a magical environment variable that directs the CLR startup to a configuration file that is specific to your MMC snap-in.
Personally, I think it would have made everyone's lives easier if they would have simply changed MMC.EXE to use CLR 4 but for some reason they decided to not go that direction.
Upvotes: 1
Reputation: 103
...or you can force MMC to use v4.0 with following environment variable:
set COMPLUS_Version=v4.0.30319
Upvotes: 1
Reputation: 84744
Having read up on the matter a bit further, I can confirm that the host process must explicitly support multiple runtimes via some new APIs in .NET 4.0.
I doubt MMC (even in Windows 7) supports these APIs, since .NET 4.0 is also in beta. In the unlikely chance that it does, you can force it to use it by using the supportedRuntime element in your configuration:
<configuration>
<startup>
<supportedRuntime version="v4.0.20506"/>
</startup>
</configuration>
Failing that, however, I'm afraid you are out of luck. Your only choice then will be to change your project to target .NET 2.0.
Alternatively, you could write an unmanaged MMC snap-in that hosts it's own runtime and loads your managed one. How badly do you need those .NET 4.0 features?
Upvotes: 3