-
Notifications
You must be signed in to change notification settings - Fork 744
Running under mono #3257
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Never mind. |
Well, I spoke to soon. Tried running full framework tests, and got:
Since I know that the full test suite is run under mono for integration testing, I must be doing something wrong. BTW, this is running under Ubuntu 16.0.4. And:
|
CI is using Mono 5.10 on Travis and Azure Pipelines is up to 5.11 I think. I know that if we upgrade to Mono 5.13, a whole bunch of tests start failing with double precision issues and stack trace mismatches. (I'll have to dig up the issue I posted them in.) I saw this in CI and also on Ubuntu 18.0.4 with Mono 5.20. Mono quirks have eaten up so much of my time that I'm being careful to remain good-humored about it. :') Missing System.Web though makes me think you might have installed mono-devel instead of mono-complete, on the Mono install webpage's advice that it solves most missing assembly issues. |
Here's the 24 tests I'd expect to see fail unless you roll back to Mono 5.11: I should reopen that issue and get to work, I guess. |
These are the ones that failed for me under 5.20 (26 of them):
|
I had installed mono-runtime. Installing mono-complete did solve the missing dll problem. I do not really need mono-complete, however :( |
@jnm2 There is no mono release 5.11 :(
|
It really surprises me that we are running the integration tests under a mono release which is over a year old! There have been four releases of mono since then. I would have thought that the problems with the newer versions would have been identified and fixed by now :( |
@oznetmaster I have no idea what I was remembering. The last version of Mono that works for us is 5.18, and 5.20 introduces all those issues you mention.
This is what happens when we pin the Mono version in Travis due to needing to force a newer version. So the failures should start rolling in at any time from our AzDO build.
Based on the dates you posted, the earliest we could have detected this incoming situation was ~5 weeks ago. Some of these failures are due to overspecified tests (stack traces), and others look like Mono must be plain broken because its behavior is not matching .NET Core or .NET Framework:
Mono had me on a fine chase recently. ThreadAbortExceptions disappeared, waited until the next unrelated exception is thrown, and came back to life with all the original context missing. The cause of this was a fundamental runtime spec violation. We saw the side effects of this ten years ago in a number of tests but couldn't figure out what was behind it, so we just disabled those tests on Mono. I'm flattered by your faith in us that we're able to keep up with whatever Mono throws at us next, but it's also a time sink. Other than CI, it's hard for the team to even be aware of this because it's not practical for us to use Ubuntu when working on NUnit on a regular basis. (This thread abort bug for example afflicts only the non-Windows builds of Mono.) |
Yeah, sounds like mono-devel might contain System.Web. |
Since I only maintain the CF version of NUnit, which does not involve CI at all, I have not been exposed to all these issues. Now, I only need a reliable NUnit that works on the current Mono (5.20.1) on Ubunto 16.0.2. I would be happy to help find the problems, but my environment is Mono on a different computer then I am running VS 2019 on, so debugging is very difficult. |
I do not control the mono version on that machine either. |
Thanks. It's probably down to you and me to sort these out. I will start working on it absolutely next (I just fixed #3258.) That means probably this weekend. |
Ok. Let me know what I can do. |
Is this time travel on github now? |
Reading through this, I noticed that the first comment uses nunitlite, while the second uses nunitlite runner. I wonder if we are all thinking of the same thing as we read this, so I suggest clarifying. NUnitlite is used from an executable test that uses the AutoRun class. NUnitlite runner is something I banged together to allow running tests from a dll and to run under a third target, different from the test target and the sut target. We distribute it but do not really explain it to users. Maybe that is a mistake. Anyway, it seems important to be clear in every example which of the two we are talking about. |
Yes, I tried both to see what happened. In this environment, I can only use NUnitlite, so I used NUnitlite runner to run the framework tests, since they are only a dll. |
For some reason, the NUnit build creates the nunitlite.tests.exe, but does not create a nunit.framework.tests.exe, hence the need to use the runner. |
That's because we wanted to exercise use of NUnitLite when testing NUnitLite. In that case, if you are only using the runner for the NUnit tests themselves. Its possible to add another build of the runner that targets 4.7. Nothing else would need to be re-targeted. |
For this one:
I stepped through the test using MonoDevelop with both Mono 5.18 and 5.20. It appears that Mono 5.20 loses the stack trace during the MethodInfo.Invoke call. I can't think of any option but to ignore this test on Mono from now on. We should find or file a bug too and link it. |
@oznetmaster This is out of the way then as soon as you have time to review #3261. :) |
I noticed that our master branch was still failing. I must have missed these two tests when I did #3261 and I submitted the PR while AzDO was still using Mono 5.18, so that's why the build succeeded for #3261. https://nunit.visualstudio.com/NUnit/_build/results?buildId=1760: ❌ ReflectTests.DynamicInvokeWithTransparentExceptionsPreservesStackTrace The fix is to do the same as #3261 for these two. I may have time late tonight. |
trying to run the .NET 4.5 build under mono, executing nunitlite.tests.exe results in:
I have no idea what to do to debug this. This test exe runs correctly under .NET 4.5 on windows.
The text was updated successfully, but these errors were encountered: