Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
Created attachment 14855 [details]
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.184.108.40.20650512/nunit-console.exe 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
Could you look at this one?
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 220.127.116.11 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
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
I'm able to reproduce the same, and have filed bug #40406 instead of re-opening this issue.
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.