TypeLoadException in nunit3-console 3.0.1

[yaakov-h]

When using NUnit.Console 3.0.1 from the NuGet gallery, I'm getting an exception when starting the runner.

I'm only seeing this behaviour on some PCs.

NUnit Console Runner 3.0.5813
Copyright (C) 2015 Charlie Poole

System.TypeLoadException: Could not load type 'NUnit.Engine.IAvailableRuntimes' from assembly 'nunit.engine.api, Version=3.0.0.0, Culture=neutral, PublicKeyToken=2638cd05610744eb'.
   at NUnit.Engine.TestEngine.Initialize()
   at NUnit.Engine.TestEngine.NUnit.Engine.ITestEngine.get_Services()
   at NUnit.ConsoleRunner.ConsoleRunner..ctor(ITestEngine engine, ConsoleOptions options, ExtendedTextWriter writer)
   at NUnit.ConsoleRunner.Program.Main(String[] args)

This issue only occurs when trying to run NUnit.Console on a PC that has NUnit 3.2 installed globally by MSI.

[rprouse]

@CharliePoole looks like an error with our engine resolution that we didn't think of. The console is finding the newer engine in the install directory and using that. Any ideas what we can do about it?

[CharliePoole]

Ah ha! I didn't think of this. The new engine is getting loaded. It references the api assembly that is found in its own directory. But the old api assembly is already in memory.

@yaakov-h A workaround is to upgrade the console nuget package to 3.2. You don't have to upgrade the framework if you don't want to.

A temporary fix we could make would be to only use the local engine.

A longer term fix that allows dropping in new engine releases will take some thinking.

[yaakov-h]

Why is the old runner loading the new engine?

[CharliePoole]

Because nunit.engine.api is designed to find the newest engine available and use it, within limits set by the client program - nunit3-console in this case. Clearly, we have a glitch, as described in my note above.

[rprouse]

@CharliePoole, should we do a temporary fix for this for 3.2.1?

[CharliePoole]

Good idea. It's just a matter of having the console runner specify true for privateCopy when it calls TestEngineActivator.CreateInstance. That's what Ive just done for the gui.

[rprouse]

@CharliePoole, sounds good. I have put in the 3.2.1 milestone and assigned it to me for the temporary fix.

[knocte]

A workaround is to upgrade the console nuget package to 3.2.

Are you sure about this? This is affecting me when simply running the test within XamarinStudio (not the console runner), and I'm already using version 3.2.

More info: https://bugzilla.xamarin.com/show_bug.cgi?id=40035

[rprouse]

@knocte, I am pretty sure your problem is a different issue. It looks to be a problem with the XamarinStudio test runner which we did not write. I actually didn't even know it worked for NUnit 3 😄

Looking at the source for the MonoDevelop NUnit 3 runner, they have not updated it or the engine to 3.2 yet, so it is not you that needs to update to 3.2, it is Xamarin Studio.

Looking at their runner code, they are loading v3.0.1 of the nunit.framework.dll into their test runner and directly linking to v3.0.1 of the nunit.engine. This locks Xamarin users into v3.0.1 of NUnit. Their runner code is totally incorrect. They really should have contacted us for guidance.

[rprouse]

#1413 provides a short term fix for this by using a local engine. I am moving out of the 3.2.1 milestone.

[rprouse]

I am going to leave this On Deck, but move out of the 3.4 milestone. The temporary fix is still in place and works. I think we need time to discuss possible fixes and work through the potential consequences of each. Until we do that, I think sticking with a local engine is safest.

[CharliePoole]

I agree. This is really a symptom of the overall issue addressed by #1132. Should that be an Epic?

[CharliePoole]

Issue moved to nunit/nunit-console #6 via ZenHub