Search

Can not use .Net 4.0 to create MMC SnapIn by Jonathan Dickinson

Closed
as By Design Help for as By Design

21
0
Sign in
 to vote
Type: Bug
ID: 474039
Opened: 7/13/2009 3:59:21 AM
Access Restriction: Public
6
Workaround(s)
10
User(s) can reproduce this bug
If I try to create a MMC SnapIn using .Net 4.0 MMC fails to load the snapin. My MMC snap-in is 32bit on a 64bit machine.

I tried tweaking the runtime version in the MMC registry key (FxVersion) and that didn't work.
Details (expand)
Product Language
English

Version

Visual Studio 2010 Beta 1
Operating System
Windows 7
Operating System Language
English
Steps to Reproduce
1. Create the 'Hello World' MMC snap-in as outlined in the MMC 3.0 SDK documentation. Use the default Visual Studio 2010 project settings (.Net 4.0).
2. Install the snap-in.
3. Start MMC and add the snap-in.
If the snap-in is not present start MMC using "mmc /32".
Actual Results
MMC indicates that the snap-in could not be loaded. Selecting "Unload the snap-in and continue running" yields a window displaying the following message:

"Could not load file or assembly '..., Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded."
Expected Results
The snap-in should load.
TAP Code (if applicable)
 
      You can indicate your satisfaction with how Microsoft handled this issue by completing this quick 3 question survey.

 

File Attachments
0 attachments
Sign in to post a comment.
Posted by cheeyam on 9/19/2011 at 2:35 AM
Hello,

Is there a point in waiting? Will we ever get an answer?

Thanks,
Ram
Posted by Amit Kardile on 3/23/2011 at 3:48 AM
Hello Micorsoft MMC team,

Is there any news regarding this bug from the product unit who works on that specific feature area?

This bug is kind of showstopper for us and we no longer can use .net framework 4.0 for MMC snap-in development.

Regards,
Amit
Posted by Henning Krause on 10/6/2010 at 6:41 AM
I've just tried the workaround using an activation_configuration file. In the case of an MMC, I have to put an mmc.exe.activation_config in the path specified by the COMPLUS_ApplicationMigrationRuntimeActivationConfigPath environment variable.

I also had to set the useLegacyV2RuntimeActivationPolicy to true.

This works so far. But using that approach forces all managed snapins to the .NET 4 runtime, doesn't it? What about an MMC, which loads two distinct snapins, one for .NET 2.0 and one for .NET 4? If I understand the useLegacyV2RuntimeActivationPolicy attribute correctly, it disables the new SxS feature of .NET 4.

Some clarifications would be helpful.

Kind regards,
Henning Krause
Posted by Matthew Wetmore [MSFT]1 on 9/22/2010 at 2:28 PM
Jason, you indicated in the "Workarounds" tab that you found your missing piece. Does that address the comments below?

MMC is a Windows component, and Windows 7/Windows Server 2008 R2 released prior to CLRv4.
The MMC team worked directly with the CLR team to develop the workaround you're using.


Posted by Jason Burkey on 9/1/2010 at 1:32 PM
I don't see how this is in any way acceptable. The same problem occurs with PowerShell v2, and there is at least a registry based fix that ONLY affects PowerShell. How are we supposed to create management tools if the 2 most common platforms can't run the code?

It's all well and good that "continue to use .NET 3.5 for that scenario"...but we're building on .NET 4...Sure, I could build the management piece in 3.5...But then I can't link to any of my other code, so I would have to shim up the entire project in some terrible way. It's not an "inconvenience"...it's a major flaw.

I will further note that it is now 1 year after this bug was opened. The fix that the powershell team implemented isn't perfect, but it WORKS...And it's easy to implement...Load the runtime version out of the registry and use it. I cannot imagine that this is difficult by any stretch of the imagination. Someone in redmond OWNS this...Owns MMC, and owns this problem. Apparently, the solution was made available to them 1 year ago by the CLR team, and it's been ignored. That is shameful.

MMC doesn't support the latest microsoft technology. This blocks enterprise developement (the people who use MMC the most) from moving forward with these latest greatest techs. That's what this bug is about. Where is the MMC team in fixing this? Where is the MMC team in adopting and furthering the core technologies of Microsoft?

Yes there is a workaround. It is acceptable for development, but is absolutely clunky when shipping to a customer. Is there an alternative? Not really. Unless we build our own client, or go with a web interface. Neither of those are simple substitutions.

Seriously...If you can't keep it up to date, and make it work...Get rid of it. Give us a different answer to MMC. Until then, would you please just fix the problem?
Posted by Steffen Mangold on 6/30/2010 at 2:15 AM
Very poor workaround.
Can the mmc team please give some resonance for this problem?
I try to get in contact with the team but the mmc team blog is also free of any news.

If no new version of mmc comes out fast to kill the mmc support from developer side.
Posted by Matthew Wetmore [MSFT]1 on 6/24/2010 at 10:57 AM
Please see the latest work-around (workarounds tab) for Windows 7 and Windows Server 2008 R2 that will allow you to re-direct MMC to CLRv4 for specific snap-ins, rather than the other suggestions that force all MMC instances to the new CLR.
Posted by Asle Rokstad on 5/20/2010 at 3:37 AM
Any news on this issue? Is there a MMC-team responsible for mmc.exe and the .net Microsoft.ManagementConsole namespace? Can we look forward to a mmc 3.1 supporting the new .net hosting APIs?

Posted by Paul Mead on 3/29/2010 at 3:17 PM
Is this another reason to shy away from MMC? Not only is it poorly documented and not integrated with WPF, but it seems to not be getting updated. This makes me wonder if Microsoft is truly behind the MMC concept. Hmm, this does influence design decisions.
Posted by adange on 3/19/2010 at 3:51 PM
This is really unfortunate. It's a show stopper for us. The MMC snapin is an admin tool used to configure our application and uses some of the application assemblies --- or in other words our snapin has dependencies on application assemblies. We want to move the application code to .Net 4.0, but if we do that we cannot compile the snapin!!
So it seems the only choices we have are:
1. Dont move to .Net 4.0, because the snapin wont work.
2. Somehow get rid of the dependencies on the application code which is moving to .Net 4.0 (duplicate the code within the snapin).

Anyone else has better ideas?
Posted by David Lowndes on 1/25/2010 at 7:50 AM
No comment forthcoming on whether there will be an MMC update to allow .Net V4 to be used?

FWIW, the piece of .NetV4 functionality we need in an MMC is the option to specify the 64-bit registry using RegistryKey.OpenRemoteBaseKey with RegistryView.Registry64.
Posted by David Lowndes on 11/9/2009 at 4:38 AM
Rich,

This is a show stopper. We have an MMC that we'd like to build using .Net V4 so that we can easily make use of the enhanced registry support (cross 32/64 bit registry access) that's only available with .Net V4.

Is there going to be a MMC update that will enable us to use .Net V4?
Posted by Microsoft on 10/22/2009 at 11:05 AM
Unfortunately, MMC is one of the very few extensibility point in the OS that will not support .NET 4. MMC is a native code Windows component that hosts the CLR through the CLR native code hosting APIs. As part of the .NET product cycle, we enabled hosting multiple CLRs in-process at once. As part of that work, we exposed a new set of APIs to opt-in to that new scenario. All hosts, including MMC, that host the runtime will need to use these new APIs to access later CLR versions. Since Win7, and prior versions of the OS, shipped before .NET 4, they do not take advantage of the new APIs.

As a result, .NET 4 cannot be used to write MMC snap-ins. However, you can continue to use .NET 3.5 for that scenario.

I hope that this explanation helps explain the situation. Appologies for the inconvenience.

thanks -- Rich
Richard Lander
CLR PM, Microsoft
Posted by Microsoft on 7/14/2009 at 5:36 PM
Thanks for your feedback. We are routing this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team
Sign in to post a workaround.
Posted by Andrea Ferendeles on 5/10/2010 at 11:08 PM
Resolution: tell MMC to use the v4 Framework. You can either set the
COMPLUS_Version environment variable appropriately (in my case, that's
to "v4.0.30319"), or set the Framework version in
%windir%\system32\mmc.exe.config.
Posted by Andrea Ferendeles on 5/11/2010 at 4:42 AM
In my case all works fine adding the COMPLUS_Version environment variable with "v4.0.30319" as value.

Regards,
Andrea.
Posted by Matthew Wetmore [MSFT]1 on 6/24/2010 at 10:58 AM
The following article describes CLR support to re-direct specific instances of executables forward to later to CLRs, rather than setting a machine wide value for either .NET (COMPLUS_Version) or MMC (app.config)

http://msdn.microsoft.com/en-us/library/ff361644.aspx
Posted by Jason Burkey on 9/1/2010 at 4:05 PM
The COMPLUS_Version seems to work, but I cannot for the life of me get it to work with either an app.config or activation_config...Am I missing something?

I'm running 2008 R2.
Posted by Jason Burkey on 9/1/2010 at 5:05 PM
Ok...Found what was missing. The post on Activation Configuration Files left out 1 thing (or I missed it). You have to set the "useLegacyV2RuntimeActivationPolicy" attribute to "true" for that fix to work (at least for me).

This has consequences if you read the documentation. I only glanced at it, and figure I will deal with that later (or never if I just bail on the whole mmc thing because of this debacle).

Here is my activation file for anyone who's wondering.

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
    <supportedRuntime version='v4.0' />
</startup>
</configuration>
Posted by Andrea Ferendeles on 9/29/2010 at 11:01 PM
This works for me:
(mmc.exe.config)

<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
<requiredRuntime version="v4.0.20506" />
</startup>

© 2012 Microsoft Corporation. All rights reserved. Microsoft Connect Terms of Use | Trademarks | Privacy Statement