TypeLoadException in nunit3-console 3.0.1

[CharliePoole]

@yaakov-h commented on Sun Mar 13 2016

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 commented on Mon Mar 14 2016

@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 commented on Mon Mar 14 2016

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 commented on Tue Mar 15 2016

Why is the old runner loading the new engine?

---

@CharliePoole commented on Tue Mar 15 2016

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 commented on Tue Apr 12 2016

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

---

@CharliePoole commented on Tue Apr 12 2016

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 commented on Wed Apr 13 2016

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

---

@knocte commented on Wed Apr 13 2016

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 commented on Thu Apr 14 2016

@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 commented on Fri Apr 15 2016
#1413 provides a short term fix for this by using a local engine. I am moving out of the 3.2.1 milestone.

---

@rprouse commented on Sat Jun 25 2016

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 commented on Sat Jun 25 2016

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