Error Moles 0.94.51023.0 on VS 2010 SP1

Question

I try mole System.ServiceModel v4 in VS 2010 SP1 with Moles 0.94.51023.0, and I keep getting the following error message: The type or namespace name "IHttpCookieContainerManager" does not exist in the namespace "ssm :: System.ServiceModel.Channels" ( do you miss the assembly reference?) [my-test-project.Test \ obj \ Debug \ Moles \ ssm \ mgcsproj] my-test-project.Test \ mgcs 293022 43

This interface seems to have been removed from System.ServiceModel.dll in .NET 4.0, since I can only find it in System.ServiceModel.dll v2.0.5.0 (Silverlight) when searching in the browser for objects.

I can reproduce this via cmdline using moles.exe, and I tried modifying the moles file to only generate the type names that I specify, but that doesn't make any difference. This worked fine until my upgrade to VS2010 SP1, so I suspect this is a bug, but any help would be appreciated.

Thanks Nick

Answer 1

I also debugged this myself and found that the root cause is VS2010 SP1 (and the related GDR KB update for .NET 4 ) to update one DLL set, but not another:

System.ServiceModel.dll in% ProgramFiles (x86)% \ Associated assemblies \ does not match the one installed in .NET v4, on% windir% \ Microsoft.NET \ Framework64 \ v4.0.30319 ...

Post VS 2010 SP1 Update:

% Program Files (x86)% \ Reference Assemblies \ Microsoft \ Framework.NETFramework \ v4.0 \ System.ServiceModel.dll → File Version 4.0.30319.1

% windir% \ Microsoft.NET \ Framework64 \ v4.0.30319 \ System.ServiceModel.dll → File Version 4.0.30319.225

Comparing these two DLLs in the object explorer in VS as well as in Reflector causes the IHttpCookieContainerManager interface to be removed in a newer file. Therefore, I suspect it is a combination of .NET sensing that detects a newer DLL and Moles that reflects an older one when you create a generation / generation. I was able to manually generate the Moles dll for the new DLL by manually launching the Moles exe without any link paths of any type, unlike the MSBuild target, which adds a bunch of ref links during build.

Answer 2

I don’t know why this is happening, but I had the same problem, and I solved it using filters like Moles, and only including the ones I really need (which has a good side effect of speeding up compilation a lot !!). This is an example .moles file that I use:

 <Moles xmlns="http://schemas.microsoft.com/moles/2010/"> <Assembly Name="System.ServiceModel"/> <StubGeneration> <Types> <Clear/> <Add Namespace="System.ServiceModel.Description!"/> </Types> </StubGeneration> </Moles> 

Answer 3

It looks like it was a conflict between the System and System.ServiceModel assemblies that Moles used to compile.

I recently installed Microsoft.NET Framework 4.5.

After uninstalling and reinstalling 4.0, everything worked.

Answer 4

Well, in case someone works with outdated code and turns out to be cornered using Microsoft Moles, I have done extensive work on this topic and hope to retain some of the anger and frustration that I came across.

I tried using the accepted answer sentence, which meant going to the Moles directory (in C: \ Program Files ..) and running the command line utility (moles.exe) as an administrator. There are many options, one of which allows you to include reference assemblies (as suggested above).

However, even when I try to run the utility without reference assemblies, the utility eventually calls the C # compiler (csc.exe) with predefined reference assembly goals, in which I conclude that there is confusion between versions of the .NET Framework, I could not get it to not turn on these assembly paths.

My specific scenario was that I was trying to install Mole on a custom assembly, however, since I apparently had .NET 4.5 installed on this machine, it complained about a compilation about System.Collections.Generics IReadOnlyCollection, IReadOnlyDictionary, and I think different.

Solution . Decision I got is to use Mole filters, which I read about in other posts and on the Microsoft Moles website (there is a special link for troubleshooting .NET 4.5 on the main page). In Visual Studio, I simply added the Moles assembly to my unit test project for my custom assembly that is referenced by right-clicking in the solution explorer. Then I tried to build. For each error I received, I noticed classes that violate the rules and excluded them from Shimmed or Stubbed by adding the following to the moles file:

 <Moles xmlns="http://schemas.microsoft.com/moles/2010/"> <Assembly Name = "MyCustomAssembly" /> <StubGeneration> <Types> <Remove TypeName="ClassThatUsesIReadOnlyCollectionEtc" /> </Types> </StubGeneration> <MoleGeneration> <Types> <Remove TypeName="ClassThatUsesIReadOnlyCollectionEtc" /> </Types> </MoleGeneration> </Moles> 

Now it’s clear that you are not going to work if you need classes that you exclude from the mole / stub generation, but for my case this worked fine because the intruder classes were not important and I would not need a Stub or Helmet something- sometime in these classes.