DynamicProxy does not support reference semantics with value types (C# 7.2) on .NET Core

[TAGC]

(Cross-posting some details from nsubstitute/NSubstitute#378)

C# 7.2 introduced the possibility of using reference semantics for value types - this is done by applying the in modifier for value-type parameters in method signatures.

Castle.Core does not seem to support generating mocks for interfaces that use in modifiers for value types. This has been reproduced using Castle.Core indirectly through the latest stable versions of Moq and NSubstitute:

namespace SomeProject.Tests
{
    public readonly struct Struct
    {
    }

    public interface IStructByRefConsumer
    {
        void Consume(in Struct message);
    }

    public interface IStructByValueConsumer
    {
        void Consume(Struct message);
    }

    public class TempSpec
    {
        // Fails.
        [Fact]
        internal void Struct_ByRef_Moq_Test()
        {
            _ = Mock.Of<IStructByRefConsumer>();
        }

        // Fails.
        [Fact]
        internal void Struct_ByRef_NSubstitute_Test()
        {
            _ = Substitute.For<IStructByRefConsumer>();
        }

        // Passes.
        [Fact]
        internal void Struct_ByValue_Moq_Test()
        {
            _ = Mock.Of<IStructByValueConsumer>();
        }

        // Passes.
        [Fact]
        internal void Struct_ByValue_NSubstitute_Test()
        {
            _ = Substitute.For<IStructByValueConsumer>();
        }
    }
}

Posted below is the part of the stracktrace that's common between the failing Moq and NSubstitute tests:

Message: System.TypeLoadException : Signature of the body and declaration in a method implementation do not match.  Type: 'Castle.Proxies.IStructByRefConsumerProxy'.  Assembly: 'DynamicProxyGenAssembly2, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.

Result StackTrace:	
at System.Reflection.Emit.TypeBuilder.TermCreateClass(RuntimeModule module, Int32 tk, ObjectHandleOnStack type)
   at System.Reflection.Emit.TypeBuilder.CreateTypeNoLock()
   at System.Reflection.Emit.TypeBuilder.CreateTypeInfo()
   at Castle.DynamicProxy.Generators.Emitters.AbstractTypeEmitter.CreateType(TypeBuilder type)
   at Castle.DynamicProxy.Generators.Emitters.AbstractTypeEmitter.BuildType()
   at Castle.DynamicProxy.Generators.InterfaceProxyWithoutTargetGenerator.GenerateType(String typeName, Type proxyTargetType, Type[] interfaces, INamingScope namingScope)
   at Castle.DynamicProxy.Generators.InterfaceProxyWithTargetGenerator.<>c__DisplayClass6_0.<GenerateCode>b__0(String n, INamingScope s)
   at Castle.DynamicProxy.Generators.BaseProxyGenerator.ObtainProxyType(CacheKey cacheKey, Func`3 factory)
   at Castle.DynamicProxy.ProxyGenerator.CreateInterfaceProxyWithoutTarget(Type interfaceToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options, IInterceptor[] interceptors)

[TAGC]

For what it's worth, here's the generated IL for each interface:

.class interface public abstract auto ansi 
  SomeProject.Tests.IStructByRefConsumer
{

  .method public hidebysig virtual newslot abstract instance void 
    Consume(
      valuetype SomeProject.Tests.Struct& modreq ([System.Runtime.InteropServices]System.Runtime.InteropServices.InAttribute) message
    ) cil managed 
  {
    .param [1] 
    .custom instance void [System.Runtime]System.Runtime.CompilerServices.IsReadOnlyAttribute::.ctor() 
      = (01 00 00 00 )
    // Can't find a body
  } // end of method IStructByRefConsumer::Consume
} // end of class SomeProject.Tests.IStructByRefConsumer

.class interface public abstract auto ansi 
  SomeProject.Tests.IStructByValueConsumer
{

  .method public hidebysig virtual newslot abstract instance void 
    Consume(
      valuetype SomeProject.Tests.Struct message
    ) cil managed 
  {
    // Can't find a body
  } // end of method IStructByValueConsumer::Consume
} // end of class SomeProject.Tests.IStructByValueConsumer

[TAGC]

And also, the source code for the last line of that stacktrace.

[stakx]

@TAGC: I cannot reproduce this problem. All of your tests pass just fine for me with the following NuGet package versions:

• Castle.Core 4.2.1
• Moq 4.8.2 / NSubstitute 3.1.0
• xunit 2.3.1
• xunit.runner.visualstudio 2.3.1

Some notes:

• I have run the Moq and NSubstitute tests separately since installing both Moq and NSubstitute at the same time appears to cause an assembly version conflict that I couldn't bother to fix.
• I have .NET 4.7.1 installed (IIRC).
• I haven't tried whether x86 / x64 makes a difference.
• I took a quick look at the dynamic assembly generated by DynamicProxy, it reproduces the method signature just fine (including the modreq).

[TAGC]

Try .NET Core instead of .NET Framework. I've got a suspicion it might be a problem with corefx (or coreclr).

[stakx]

Yes, the tests start failing when run under .NET Core.

If I am putting facts together correctly, then the problem is caused by DynamicProxy not emitting custom modifiers in its .NET Standard 1.3 target (see the FEATURE_EMIT_CUSTOMMODIFIERS compilation symbol in common.props):

Core/buildscripts/common.props

Lines 43 to 44 in c6f75ff

<NetStandardConstants>TRACE;FEATURE_NETCORE_REFLECTION_API;FEATURE_TEST_SERILOGINTEGRATION</NetStandardConstants>

<CommonDesktopClrConstants>TRACE;FEATURE_APPDOMAIN;FEATURE_ASSEMBLYBUILDER_SAVE;FEATURE_BINDINGLIST;FEATURE_DICTIONARYADAPTER_XML;FEATURE_EMIT_CUSTOMMODIFIERS;FEATURE_EVENTLOG;FEATURE_GAC;FEATURE_GET_REFERENCED_ASSEMBLIES;FEATURE_IDATAERRORINFO;FEATURE_ISUPPORTINITIALIZE;FEATURE_LISTSORT;FEATURE_REMOTING;FEATURE_SECURITY_PERMISSIONS;FEATURE_SERIALIZATION;FEATURE_SMTP;FEATURE_SYSTEM_CONFIGURATION;FEATURE_TARGETEXCEPTION;FEATURE_TEST_COM;FEATURE_TEST_SERILOGINTEGRATION</CommonDesktopClrConstants>

Core/buildscripts/common.props

Lines 85 to 87 in c6f75ff

	<PropertyGroup Condition="'$(TargetFramework)|$(Configuration)'=='netstandard1.3|Release'">
	<DefineConstants>$(NetStandardConstants)</DefineConstants>
	</PropertyGroup>

Core/src/Castle.Core/DynamicProxy/Generators/Emitters/MethodEmitter.cs

Lines 179 to 202 in c6f75ff

	#if FEATURE_EMIT_CUSTOMMODIFIERS
	returnRequiredCustomModifiers = returnParameter.GetRequiredCustomModifiers();
	Array.Reverse(returnRequiredCustomModifiers);
	returnOptionalCustomModifiers = returnParameter.GetOptionalCustomModifiers();
	Array.Reverse(returnOptionalCustomModifiers);
	int parameterCount = baseMethodParameters.Length;
	parametersRequiredCustomModifiers = new Type[parameterCount][];
	parametersOptionalCustomModifiers = new Type[parameterCount][];
	for (int i = 0; i < parameterCount; ++i)
	{
	parametersRequiredCustomModifiers[i] = baseMethodParameters[i].GetRequiredCustomModifiers();
	Array.Reverse(parametersRequiredCustomModifiers[i]);
	parametersOptionalCustomModifiers[i] = baseMethodParameters[i].GetOptionalCustomModifiers();
	Array.Reverse(parametersOptionalCustomModifiers[i]);
	}
	#else
	returnRequiredCustomModifiers = null;
	returnOptionalCustomModifiers = null;
	parametersRequiredCustomModifiers = null;
	parametersOptionalCustomModifiers = null;
	#endif

IIRC this is because support for emitting custom modifiers is not included in that version of .NET Standard.

The new C# in keyword gets emitted as a custom modifier (modreq), so if DynamicProxy can't emit that modreq, then the generated proxy method signature won't match your interface's method signature, thus the error under .NET Core (which uses the .NET Standard 1.3 build of DynamicProxy).

One solution might be to have DynamicProxy support a new framework target, e.g. .NET Standard 2.0, which quite possibly supports emitting custom modifiers (but I haven't checked at this point).

[TAGC]

I've found that Castle.Core fails to create a proxy for interfaces like this:

public interface IGenericStructByRefConsumer<T>
{
    T Consume(in Struct message);
}

These tests fail under both .NET Framework 4.6.1 and .NET Core 2.0:

[Fact]
internal void Struct_ByRef_Generic_Moq_Test()
{
    _ = Mock.Of<IGenericStructByRefConsumer<int>>();
}

[Fact]
internal void Struct_ByRef_Generic_NSubstitute_Test()
{
    _ = Substitute.For<IGenericStructByRefConsumer<int>>();
}

In the case of .NET Core, I get a similar sort of error to the other tests:

Signature of the body and declaration in a method implementation do not match.  Type: 'Castle.Proxies.IGenericStructByRefConsumer`1Proxy'.  Assembly: 'DynamicProxyGenAssembly2, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.

Under .NET Framework, I get a stacktrace like this:

Castle.DynamicProxy.ProxyGenerationException : There was an error in static constructor on type Castle.Proxies.IGenericStructByRefConsumer`1Proxy. This is likely a bug in DynamicProxy. Please report it.
---- System.Reflection.TargetInvocationException : Exception has been thrown by the target of an invocation.
-------- System.TypeInitializationException : The type initializer for 'Castle.Proxies.IGenericStructByRefConsumer`1Proxy' threw an exception.
------------ System.MissingMethodException : Method not found: '!0 SomeProject.Tests.IGenericStructByRefConsumer`1.Consume(SomeProject.Tests.Struct ByRef)'.
   at Castle.DynamicProxy.Internal.TypeUtil.SetStaticField(Type type, String fieldName, BindingFlags additionalFlags, Object value)
   at Castle.DynamicProxy.Generators.BaseProxyGenerator.InitializeStaticFields(Type builtType)
   at Castle.DynamicProxy.Generators.InterfaceProxyWithoutTargetGenerator.GenerateType(String typeName, Type proxyTargetType, Type[] interfaces, INamingScope namingScope)
   at Castle.DynamicProxy.Generators.InterfaceProxyWithTargetGenerator.<>c__DisplayClass6_0.<GenerateCode>b__0(String n, INamingScope s)
   at Castle.DynamicProxy.Generators.BaseProxyGenerator.ObtainProxyType(CacheKey cacheKey, Func`3 factory)
   at Castle.DynamicProxy.Generators.InterfaceProxyWithTargetGenerator.GenerateCode(Type proxyTargetType, Type[] interfaces, ProxyGenerationOptions options)
   at Castle.DynamicProxy.DefaultProxyBuilder.CreateInterfaceProxyTypeWithoutTarget(Type interfaceToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options)
   at Castle.DynamicProxy.ProxyGenerator.CreateInterfaceProxyTypeWithoutTarget(Type interfaceToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options)
   at Castle.DynamicProxy.ProxyGenerator.CreateInterfaceProxyWithoutTarget(Type interfaceToProxy, Type[] additionalInterfacesToProxy, ProxyGenerationOptions options, IInterceptor[] interceptors)

[stakx]

@TAGC: .NET 4.6.1 probably prefers the .NET Standard 1.3 build to the .NET Framework builds (a problem that has cropped up since .NET 4.6.1 was retroactively changed to support .NET standard 2.0), explaining why it is affected by this as well.

[TAGC]

How hard would it be to fix this? I'd need to manually mock all my interfaces that use in <valuetype> methods otherwise, and I guess now that C# 7.2 is out a bunch of other people will be running into similar problems.

[jonorossi]

@TAGC I've renamed the issue title, no mocking happens here that is a mocking library concern. Thanks for the issue report, I'd usually start by asking for a test case against this library not another layer up your stack, but in this case it'll be easy to make that step.

Thanks @stakx, yes it definitely sounds like this is caused by custom modifiers not emitted when using the .NET Standard 1.3 build, I disliked writing that code during the DNX port.

It looks like ParameterInfo.GetRequiredCustomModifiers (and friends) are available in .NET Standard 2.0, 1.6 and 1.5, and the coreclr has code for it.

I guess its time to also add a .NET Standard 2.0 build. However I don't think that will fix Moq (.NET Standard 1.3), NSubstitute (.NET Standard 1.3) or FakeItEasy (.NET Standard 1.6) without each project also releasing a .NET Standard 2.0 build which they do not do today, as NuGet will continue to use the .NET Standard 1.3 build. I don't think we really have any other options.

/cc @dtchepak @blairconrad @thomaslevesque

[stakx]

@jonorossi: Thanks for the hint regarding Moq. I'll take care of upgrading Moq once an updated Castle.Core package is available. (I think I'll skip over .NET Standard 1.5 and 1.6 as framework targets and go straight to .NET Standard 2.0.)

[thomaslevesque]

I guess its time to also add a .NET Standard 2.0 build

Why 2.0? If the necessary APIs are supported in 1.5, why not target the lowest possible version to support the largest number of consumers? Is there a compelling reason to target 2.0?

.NET 4.6.1 probably prefers the .NET Standard 1.3 build to the .NET Framework builds (a problem that has cropped up since .NET 4.6.1 was retroactively changed to support .NET standard 2.0), explaining why it is affected by this as well.

I don't think that's the reason; I just tried it, making sure to reference the net45 version of Castle.Core, and the problem with the generic interface still occurs. I think this is a related but different bug.