Optional default generic parameter on object type is resolving to System.Reflection.Missing not null

I have a public extension method that looks like this:

public static T MinOrDefault <T>(this IEnumerable<T> source, T defaultValue = default(T))
{
    return MinOrDefaultImplementation(source, defaultValue);
}

I have an NUnit unit test that looks like this:

            [Test]
            public void MinOrDefault_OnEmptyGenericEnumerable_ReturnsDefault()
            {
                var emptyGenericEnumerable = Enumerable.Empty<object>();

                Assert.That(() => emptyGenericEnumerable.MinOrDefault(), Is.EqualTo(default(object)));
            }

This test is failing in NCrunch, however when I run it with ReSharper's TestRunner it passes.

NCrunch states this:

Expected: null
But was: <System.Reflection.Missing>

I have tested using many other classes for the generic Enumerable.Empty with this and it seems to work, just not for System.Object.

Not sure if this is a bug or a known issue or what? Let me know if you need more info.

Thanks.

Hi,

When running this code myself, it seems to work correctly.

There have been previous reports of similar issues around 'default default' generic parameters, so I do think that there is a bug here.

Which version of the .NET framework is this project compiled for? Also, is there anything else interesting you can tell me about the project itself (i.e. is it using any unusual frameworks or tools)?

If you have time, something that may be very telling is if you're able to reproduce the problem inside a small cut-down solution. This would help to establish whether it is related to your environment or the project/solution.

A workaround to the problem is to change the code so that it doesn't use this particular syntax for the defaultValue parameter. You may be able to get away with using a non-generic object box with some tricky type-casting...


Cheers,

Remco

I've pared down the solution to the bare minimum required for me to reproduce the issue. I've tested on two machines with the same result.

(- BROKEN LINK -)(- BROKEN LINK -)[/url]

(- BROKEN LINK -)Screenshot[/url]

(- BROKEN LINK -)Success in Resharper[/url]

Using NCrunch 1.42.0.12

Compiling for .NET 3.5 on both Library and Unit Test .dlls.

Using NUnit 2.5.10.11092 due to that is the version that ReSharper 6.1 uses and it is not compatible with higher versions so I wanted to avoid conflicts.

My next step will be trying to change to .NET 4.0 to see if that works. My work around has been to just not use "object" as the type and use "string" just to make NCrunch happy. I may just change to object and ignore the test in NCrunch as the CI server will run the test anyway and it should pass there.

Hopefully you will be able to reproduce with what I have given you above. If there are any other environment settings you need let me know.

Thanks for a great product and great support.

Couple extra data points:

I just changed framework to .NET 4.0 for both libraries and still get the NCrunch test failure. So it doesn't seem to be target framework specific.

I also used NuGet to grab the latest NUnit version for the posted solution and got the same NCrunch test failure. So that doesn't seem to be the problem.

Stepping thru with the debugger has the System.Reflection.Missing on the defaultValue parameter as soon as it enters the method when running through NCrunch. When using Resharper test runner and debugging it, defaultValue is coming in as null.

Thanks
Jon

Hi Jon -

Thanks for supplying the sample solution! This immediately allowed me to reproduce the problem. Hopefully I should have this resolved soon.


Cheers,

Remco

Great news. In this specific situation it ended up not hurting me as I discovered I needed to add a constraint on the method to only accept IComparable<T>, which eliminated the System.Object parameter as acceptable anyway, however there may come a time where there are other cases when that is not true, so still looking forward to a fix in a future release. Thanks again for the great communication.

For anyone interested, 1.43 has just been released with a fix for the above problem.