Moles 0.94.51023.0 error on VS 2010 SP1

Question

I'm trying to mole System.ServiceModel v4 in VS 2010 SP1 with Moles 0.94.51023.0 and I keep getting the following errror: The type or namespace name 'IHttpCookieContainerManager' does not exist in the namespace 'ssm::System.ServiceModel.Channels' (are you missing an assembly reference?) [my-test-project.Test\obj\Debug\Moles\ssm\m.g.csproj] my-test-project.Test\m.g.cs 293022 43

This interface appears to have been removed from System.ServiceModel.dll in .NET 4.0 as I can only find it in System.ServiceModel.dll v2.0.5.0 (Silverlight) when I search in the Object Browser.

I'm able to reproduce this via the cmdline using moles.exe and I've tried altering the moles file to only generate type names I specify but it doesn't appear to make any difference. This was working fine prior to my upgrade to VS2010 SP1 so I suspect it's a bug, but any help would be appreciated.

Thanks Nick

Proprietress

Answer 1

I debugged this on my own as well and found that the root cause appears to be that VS2010 SP1 (and the related GDR KB update for .NET 4) update one set of DLLs but not another:

The System.ServiceModel.dll in %ProgramFiles(x86)%\Referenced Assemblies\ doesn’t match the one in the .NET v4 install at %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 Browser in VS as well as in Reflector yields the result that the IHttpCookieContainerManager interface has been removed in the newer file. So I suspect that this is a combination of .NET probing finding the newer DLL and Moles reflecting over the older one when doing mole/stub generation. I was able to manually generate a Moles dll for the newer DLL by running the Moles exe manually with no reference paths of any kind as opposed to the MSBuild target that adds a bunch of ref paths during a build.

Proprietress

I was able to resolve this problem more simply (from my perspective, since I'm not at all familiar with Moles -- I only want to build my team's project). I simply updated the DLL in %Program Files(x86)%\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\ to the newer version available in %windir%\Microsoft.NET\Framework64\v4.0.30319\ Make backups first! (as I did) I don't know what other effects this may have, but it may be a simple way to get past the build step. @Nick: Could you provide the actual moles.exe command that you ran? – Brigandage

@Dustin - I dont have the command anymore as it's been quite a while. My apologies. – Proprietress

No apology necessary! If not for your answer, I would have probably not solved this problem for quite some time. – Brigandage

You may also want to check out this solution: https://mcmap.net/q/1158335/-using-moles-for-tdd-with-httpwebrequest – Cambria

You may have to close all Microsoft programs in order to copy the file without getting an access denied error – Cleora

Answer 2

I don't know why that happens, but I had the same issue, and I resolved it by using Moles type filters, and only including the ones I really need (which has the nice side-effect of speeding up compilation quite a lot!!). This is an example .moles file I'm using:

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

Firebrat

That solved my problem of getting the type or namespace IReadOnlyCollection<T> doesn't exist in the namespace System.Collections.Generic.... – Orthostichy

Answer 3

It looks like it was a conflict between the System and System.ServiceModel assemblies that Moles was using for compilation.

I had recently installed the Microsoft .NET Framework 4.5.

After uninstalling this and re-installing 4.0 everything worked.

Invective

Answer 4

Well, in case anyone is working with legacy code and happens to be cornered into using Microsoft Moles, I've done extensive digging on this topic and hope to save some from the anger and frustration I encountered.

I tried using the accepted answer's suggestion, which meant going to the Moles directory (in C:\Program Files..) and running the command line utility (moles.exe) as Administrator. There a lot of options, one of which allows you to include referenced assemblies (as suggested above).

However, even when trying to run the utility without referenced assemblies, the utility ultimately calls the C# compiler (csc.exe) with pre-defined referenced assembly paths, which is where I conclude that the confusion between .NET Framework versions occurs. I couldn't get it not to include these assembly paths.

My specific scenario was that I was trying to Mole a custom assembly, however because, apparently, I had .NET 4.5 installed on this machine, it was complaining upon compilation about System.Collections.Generics IReadOnlyCollection, IReadOnlyDictionary, and I think one other.

Solution: The only solution I got to work was to use Mole filters, which I read about on other posts and on the Microsoft Moles website (there is a special link for .NET 4.5 troubleshooting on the main page). In Visual Studio, I simply added the Moles assembly to my unit test project for my referenced custom assembly via right click in Solution Explorer. I then tried to build. For each error I received, I noted the offending classes and excluded them from being 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 clearly that's not going to work if you need the classes that you're excluding from mole/stub generation, however for my case it worked fine because the offending classes were not important and I wouldn't be needing to Stub or Shim anything in those classes.

Growth