MemberData in derived classes fails in v2.4.1 on dotnet core (NotSupportedException)

[csMACnz]

trafficstars

I've hit this problem twice and both times figured it out without find anyone else having this issue.

When using MemberData in an abstract class, and using a name of a static method from a derived class throws an exception when run: System.NotSupportedException : Specified method is not supported.

// Apologies for the obfuscated example
public abstract class MyTestBase
{
    public const string ExpectedMemberDataMethodName = "MyData";

    [Theory]
    [MemberData(ExpectedMemberDataMethodName)]
    public void Test(int input)
    {
        // ... test
    }
}

public sealed class MyRealTest : MyTestBase
{
    public static IEnumerable<object[]> MyData()
        {
            yield return new object[] { 1 };
            yield return new object[] { 5 };
        }
}

Much digging later, and the problem is here: (deep linked into the commit from the v2.4.1 release) https://github.com/xunit/xunit/blob/c54cc52ffb275c81afed022521870193bbca6c39/src/xunit.execution/Sdk/Reflection/ReflectionMethodInfo.cs#L70

The call is being conditionally compiled out for NetStandard1.1 lib builds.

However, this works in v2.4.0 (which has the same code) but started failing when upgrading to v2.4.1. The conditional compilation was already there, however the target framework for the library was changed: (again using deep link specific commits comparing v2.4.0 to v2.4.1) 1fb6b67...c54cc52#diff-e5be6f8d4c0b7123a51f447a0fd450afL10

This change affected which conditional compilation flags where used and meant that v2.4.0 used the return Reflector.Wrap(MethodInfo.ReflectedType); code when running on dotnet core 2.X and above, but v2.4.1 now uses throw new NotSupportedException(); on all non-full framework platforms.

Note that the code causing this has already been fixed and the conditional compilation removed, so the next version (v3?) shouldn't have this problem anymore.

In the meantime, my workaround solution is to keep using v2.4.0 until a newer version with the fix comes out.

[csMACnz]

Since the cause is already fixed in master (though not the latest release) I'll close this, and hopefully find it again next time I try to update xunit and it fails.

[bedej]

Thanks @csMACnz for writing this issue with the solution, you saved me a lot of time! Hopefully there's a release soon including this fix.

[csMACnz]

@bradwilson this issue still exists in 2.4.1 two years on. I original thought v3 work come at some point, but it is still alpha right?

Is it worth seeking a fix and a new 2.4.x release of xunit v2 at all? Otherwise, I will just keep sticking to 2.4.0 everywhere instead for now.

Thanks in advance!

[bradwilson]

You can send in a PR for the v2 branch if you have a fix.

[csMACnz]

I've opened a PR with what I believe is a fix, though struggling to know exactly where to put a repro test to accompany it, the test would be similar to the repo above, but testing when targeting a .Net Core target (not full framework)

[bradwilson]

This is fixed for v2 in e813b3197c154f109c838eb0580d684b47a87a36 and will be in the first 2.5.0 prerelease build.