This project is read-only.

Compiling NMock 3.0 RTM

Feb 13, 2011 at 4:27 PM
Edited Feb 13, 2011 at 4:29 PM


I'm trying to compile NMock3 myself. I've downloaded revision 62490 from CodePlex source code repository. I believe the 3.0 RTM sources are in RELEASES\3.0 RC1\ (the RELEASES\3.0\ directory is empty).

Because as a second step I want to compile NMock3 on Mono, I tried to create a project that doesn't rely on ILMerge. This is what I did:

  • Added everything in RELEASES\3.0 RC1\Source\NMock2\ to my project
  • Added everything in RELEASES\3.0 RC1\Source\NMock3\ to my project
  • Downloaded Castle.Core 2.5.2, made all classes internal and added them to my project
  • Configured DynProxy.snk as an embedded resource, fixed resource path in ModuleScope.cs

The assembly builds fine, but when I try to use it, I get a TypeLoadException saying "Access is denied: 'Castle.DynamicProxy.CompositionInvocation'" whereas the very same test works with the binary release from CodePlex.

Is there anything else I might need to do? The only difference I noticed was that the CodePlex binary release was compiled for .NET 4.0.20926 (that's .NET 4.0 Beta 2 afaik) whereas mine is compiled for .NET 4.0.30319 (.NET 4.0 RTM). That's odd, but I don't think it's the reason...

Feb 13, 2011 at 7:29 PM

Got it working now, but somewhere between having all of Castle.Core.* and Castle.DynamicProxy.* public and making it internal, the thing breaks.

I wonder what ILMerge is doing differently from me. I'll change classes to internal piece by piece until I have the class responsible for the break. Maybe then I'll see more.

Feb 13, 2011 at 8:31 PM
Edited Feb 13, 2011 at 8:31 PM

Internalizing any of these classes breaks my internalized copy of Castle.Core in NMock3:

  • AbstractInvocation
  • CompositionInvocation
  • IInterceptor
  • IInterceptorSelector
  • IInvocation
  • InheritanceInvocation
  • IProxyGenerationHook
  • IProxyTargetAccessor

Can't tell what ILMerge does differently yet.

Feb 25, 2011 at 1:23 PM

It appears that this is an issue with Castle.Core: for some reason, above types need to be visible to the dynamic mock assembly.

  • Adding an InternalsVisibleTo("CastleDynProxyGen") works for mocks in assemblies without a strong name but is only possible if NMock3.dll is not signed (because a strong-named assembly can only make its internals visible to another strong-named assembly).
  • Vice versa, if you strong-name NMock3 dll and add the public key to in the InternalsVisibleTo() attribute, it will work for mocking strong-named assemblies only.

Because I _really_ don't want to expose the Castle.* namespaces in NMock3 (think of using future Castle.Core version at the same time as NMock3 in your assembly), I created two personal builds of NMock3, one for assemblies with a strong name and one for assemblies without. I also avoided ILMerge, so my assemblies target .NET 4.0 RTM (although there's a newer ILMerge release available from Microsoft, maybe that fixes it, too).

In case anyone is interested, these are my builds: (a patch with my changes can be found if you go up two directory levels). The Mono builds should for all that matters be identical to the Windows ones but were, obviously, compiled using Mono (on an x64 Linux system).

Jun 12, 2011 at 6:12 AM

Greetings Cygon,

I'm trying to build nmock3 using monodevelop 2.2 (the version that comes with Ubuntu 10.04LTS). I've managed to apply the patch, but I'm still having some issues. (The compiler just seems to explode). Can you tell me what version of mono you used to build your patched version?


Peter-Frank Spierenburg.

Nov 16, 2011 at 3:33 PM

Hi Cygon,

have you finally found a solution how you can avoid exposing Castle.* namespaces in your assembly without having the problem to distinguish between assemblies with/without strong name?



Nov 29, 2011 at 2:19 PM

Sorry, seems like I wasn't subscribed to this thread and didn't see the replies.

@alaendle: Nope. Sorry, I'm not even looking for a "solution" right now since I don't see having two NMock DLLs as a problem. I doubt there even is a way to avoid that since you can't put InternalsVisibleTo() to a strong-named assembly in a weak-named one and vice versa.

@deftware: I think I used xbuild on Mono 2.6 or 2.8. I'm currently running Mono 2.10.5 and there are 3 compilation errors, one seems trivial and the other two are probably due to a missing reference to System.Configuration.dll. Shouldn't be too hard to fix :)