C# Generic constraint in separate library causes BadImageFormatException

[ApocDev]

This one is pretty straightforward, it seems as though placing generic type constraints on methods, where the type exists in a different assembly, causes the original to throw a BadImageFormatException on load.

For example:

OtherLibrary.dll

public interface ISomeType
{
    int Bar { get; set; }
}

ClientResource.net.dll

class Foo
{
    public void Method<T>() where T : OtherLibrary.ISomeType {}
}

The above will throw the BadImageFormatException. However, a simple change to the following allows the assembly to load properly:

ClientResource.net.dll

class Foo
{
    public void Method<T>() where T : class {}
}

Obviously, using the class constraint is "ok" to work around the issue temporarily, but I can only assume whatever assembly resolving is being done at load, also contains other such cross-assembly type issues.

[blattersturm]

This might be some anomaly with the Mono validator, do you happen to have a quick example to repro this with?

[ApocDev]

After further investigation, it seems like this isn't always the case.

I can successfully use the same constraint clauses in some classes, but not in others. I'm not exactly sure what the trigger is in this case.

I'm attaching a reproduction test (it's more complicated than a "simple" repro, simply because I can't fully narrow down the issue here, and I can reproduce it with some of the code I've got currently)

FiveMGenericRepro.zip

You'll find the Client/NuiRpcManager-Works.cs file, which you can swap in for the other one to see that removing the generic constraints allows the assembly to load. (Even though the ClientRpcManager uses the same generic constraints for some of it's methods)

[impulsh]

This is likely due to code that enables nullable reference types (<Nullable>enable</Nullable> on your project, or #nullable enable in code). The compiler adds a System.Runtime.CompilerServices.NullableAttribute to some generic parameters that the runtime isn't able to properly validate. Notably, I've only come across this issue on the client.

A quick 'n' dirty fix is to wrap any code defining generic constraints with #nullable disable and #nullable restore to prevent these attributes from being applied.

[blattersturm]

Would the compiler do the same (or error out about a missing predefined type) if you build client code with the proper framework assemblies instead of the default .NET 4.5.x/4.6.x reference assemblies?

[impulsh]

The same behaviour occurs with both .NET 4.5.2 and the reference assemblies - compilation is fine but throws an exception at runtime.