Castle DynamicProxy - Failure when creating proxy involving a GTP used as a GTR

Question

OK, now I'm really confused.

I originally had this problem, which is, according to posters, an issue with the version of Castle.DynamicProxy that's ILMerged into the latest Rhino.Mocks library. It has, according to several authorities on the subject, been fixed in the latest Castle, but that library has not made it into a new Rhino.Mocks. Most people are saying "just download the Rhino source and the latest Castle and build your own version".

So, I did exactly that; I grabbed a ZIP of the Rhino trunk source from Ayende's GitHub, opened it up, and built it. Then, like a good little TDDer, I created a unit test to make sure my changes worked (because the latest Castle folds DynamicProxy into Core, requiring some significant referencing changes):

    [Test]
    public void MockOfInterfaceMethodWithInterfaceGTR()
    {
        var mock = mocks.DynamicMock<ITestRestrictedInterface>();
        Assert.NotNull(mock);
        Expect.Call(mock.TestMethod(new Object2())).IgnoreArguments().Return(5);
        mocks.ReplayAll();
        Assert.AreEqual(5, mock.TestMethod(new Object2()));
    }

...

internal interface ITestGenericInterface<TRest> where TRest:IObject1
{
    int TestMethod<T>(T input) where T : TRest;
}

internal interface ITestRestrictedInterface:ITestGenericInterface<IObject2> { }

internal interface IObject1 { }
internal interface IObject2:IObject1 { }

internal class Object2:IObject2 { }

The result, when run in my own production code with the latest released Rhino? Failure with the following message:

System.TypeLoadException : Method 'TestMethod' on type 'ITestRestrictedInterfaceProxy83ad369cdf41472c857f61561d434436' from assembly 'DynamicProxyGenAssembly2, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' tried to implicitly implement an interface method with weaker type parameter constraints.

...However, when I copy and paste this test into a fixture in the Rhino.Mocks.Tests project, without making any changes to referenced libraries, the test PASSES. I have made zero changes to the downloaded source. I have made ZERO changes to the test method and related interfaces/objects on both sides. I built a new Rhino.Mocks DLL (without IL-merging the Castle libs) and copied it with Castle libs back to my production solution, re-ran the test, and it still fails with the same message.

WTF?

Could it be related to the issue identified in this thread; stackoverflow.com/questions/6012420/… ? Perhaps the fact it is working at all is related to the workaround noted in that thread; perhaps your mock is (somehow) explicitly (rather than implicitly) implementing the interface in the pass scenario? — RJ Lohan
A little bit of googling turned up this post which states its a compiler bug. I'm not sure if this applies to your issue but its worth a look. They also have a solution in that post. — jduncanator
I can feel the poster's anguish and pain in his last message: WTF? Indeed. — l46kok

bryanbcook bryanbcook · Accepted Answer · 2013-02-13T06:21:06

I'm not a Castle expert nor compiler guru, but I believe the issue is a little bit of magic that is hidden inside the RhinoMocks.Tests assembly:

From https://github.com/ayende/rhino-mocks/blob/master/Rhino.Mocks.Tests/TestInfo.cs

using System.Runtime.CompilerServices;
using Rhino.Mocks;

[assembly: InternalsVisibleTo(RhinoMocks.StrongName)]

And for completeness sake, RhinoMocks.StrongName is defined as:

/// <summary>
/// Used for [assembly: InternalsVisibleTo(RhinoMocks.StrongName)]
/// Used for [assembly: InternalsVisibleTo(RhinoMocks.NormalName)]
/// </summary>
public static class RhinoMocks
{
    /// <summary>
    /// Strong name for the Dynamic Proxy assemblies. Used for InternalsVisibleTo specification.
    /// </summary>
    public const string StrongName =
        "DynamicProxyGenAssembly2, PublicKey=0024000004800000940000000602000000240000525341310004000001000100c547cac37abd99c8db225ef2f6c8a3602f3b3606cc9891605d02baa56104f4cfc0734aa39b93bf7852f7d9266654753cc297e7d2edfe0bac1cdcf9f717241550e0a7b191195b7667bb4f64bcb8e2121380fd1d9d46ad2d92d2d15605093924cceaf74c4861eff62abf69b9291ed0a340e113be11e6a7d3113e92484cf7045cc7";

    /// <summary>
    /// Normal name for dynamic proxy assemblies. Used for InternalsVisibleTo specification.
    /// </summary>
    public const string NormalName = "DynamicProxyGenAssembly2";

    /// <summary>
    /// Logs all method calls for methods
    /// </summary>
    public static IExpectationLogger Logger = new NullLogger();
}

I've seen a similar issue when using Moq, which has this issue documented.

The problem is that DynamicProxy in Castle needs to dynamically derive a new type but does not have visibility to see your interface which is internal to your assembly. Simply adding the InternalsVisibleTo to the DynamicProxyGenAssembly2 to your test library should solve the problem.

Castle DynamicProxy - Failure when creating proxy involving a GTP used as a GTR

1 Answers