Bug 38331 - No longer able to run unit test project from command line via 'mono nunit-console.exe'
Summary: No longer able to run unit test project from command line via 'mono nunit-con...
Alias: None
Product: Installers
Classification: Mono
Component: General ()
Version: 4.3.0
Hardware: Macintosh Mac OS
: High critical
Target Milestone: 4.3.2 (C7)
Assignee: Alexander Köplinger [MSFT]
Depends on:
Reported: 2016-02-02 19:01 UTC by Peter Collins
Modified: 2016-05-19 10:22 UTC (History)
3 users (show)

Is this bug a regression?: ---
Last known good build:

Repro project (3.47 KB, application/zip)
2016-02-02 19:01 UTC, Peter Collins

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Peter Collins 2016-02-02 19:01:17 UTC
Created attachment 14855 [details]
Repro project

I'm getting an exception when trying to run an nunit project from command line with newer versions of mono 4.3.2. This behavior is a regression in these newer builds, as mono 4.2.x (and earlier mono 4.3.2 builds) worked with the following test case. Now, I'm seeing the following error:
> System.ArgumentException: The mono-4.6 framework is not available
Full error output:

Steps to reproduce:
1. Download the attached project.
2. Restore NuGet packages and build the project.
3. Use the nunit-console.exe in /packages/ to attempt to run the project.
>    mono SomeConsoleTest/packages/NUnit.Runners.lite. SomeConsoleTest/bin/Debug/SomeConsoleTest.dll

Mono 4.3.2 (mono-4.3.2-branch/02f59ba)
GTK+ 2.24.23 (Raleigh theme)
Package version: 403020382
Mac OS X 10.11.1
Comment 1 Rodrigo Kumpera 2016-02-02 20:37:55 UTC
Hey Alexander,

Could you look at this one?
Comment 2 Alexander Köplinger [MSFT] 2016-02-03 15:41:18 UTC
I looked at this in depth, here's the gist:

NUnit unfortunately relies on Environment.Version to special case a few things.

Environment.Version in Mono up until now just returned the FxFileVersion from Consts.cs, which changed from 4.0.30319.17020 in the .NET 4.5 profile to when we introduced .NET 4.6.

This in turn made NUnit look for major=4,minor=6 version internally, which it couldn't find because it looks at <mono-prefix>/lib/mono/2.0, 3.0, 4.0 etc folders... Those however aren't there anymore because we renamed them to 2.0-api, 3.0-api to signify they're reference assemblies. NUnit then falls back to trying to launch a separate process instead of running in the same process. This then leads to the error message from the bug report: https://github.com/nunit/nunitv2/blob/1b549f4f8b067518c7b54a5b263679adb83ccda4/src/ClientUtilities/util/Services/TestAgency.cs#L138

Now, in discussing this with Marek we agreed that Environment.Version should return a 4.0.x.x version number, as MSDN points out in https://msdn.microsoft.com/en-us/library/system.environment.version(v=vs.110).aspx:

>For the .NET Framework 4.6, it has the form 4.0.30319.42000.
>Warning: For the .NET Framework 4.5 and later, we do not recommend using the Version property to detect the version of the runtime

This was committed in mono master/c3a88ff72bdd149d449a951afda97aaea59c316a and mono-4.3.2-branch/20d7b6a5581a782d5f08cecd997417daaf3ad5fb and fixes the problem in the bug report because NUnit now uses the in-process test agent again.

However, the problem still persists if you pass -process:Separate to nunit-console, because the <mono-prefix>/lib/mono/4.0 folder isn't there anymore, leading NUnit to believe we don't have that framework.

I'm still discussing with Marek, but atm I think our only options are:

1) rename the -api folders back
2) place a breadcrumb mscorlib.dll into the folder so NUnit can find it there
Comment 3 Alexander Köplinger [MSFT] 2016-02-03 19:20:44 UTC
We decided to go with 2) and create a symlink in 4.0/mscorlib.dll that points to ../4.0-api/mscorlib.dll.

Fixed in master/a44d3c650c28a11b99caa5dafd3a55792d45806e and mono-4.3.2-branch/736c747fdfe29a742eb96812e8c9bd2bc461ce90
Comment 5 Peter Collins 2016-04-14 16:19:36 UTC
I'm able to reproduce the same, and have filed bug #40406 instead of re-opening this issue.
Comment 6 Saurabh 2016-05-19 10:22:00 UTC
As per bug #40406 I am also getting this issue (System.InvalidCastException: Specified cast is not valid). If I delete all nunit files except nunit.framework.dll then I am not seeingthis exception. This is the output: https://gist.github.com/saurabh360/ca8db19ae666badbb695f053f2447809

Hence closing this Issue.