This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. You may be attempting to load an assembly build with a later version of the CLR than the version under which NUnit is currently running.
My answer was:
I've downloaded the NUnit 2.5 source and opened the VS2008 solution in the VS2010 beta. Once the conversion finished I opened all the projects and changed the target framework setting for all the projects to ".NET Framework 4.0". I then built the solution without any errors. I can now use the NUnit GUI app to run tests built for .NET 4.0. I've not done exhaustive testing of this build so there may be problems, but for my purposes it works fine.
It is not necessary to rebuild NUnit. I discovered that if you add the following to the relevant NUnit application config file you can run a test dll built for .NET 4.0. Under <configuration> add:
<startup> <requiredRuntime version="v4.0.20506" /> </startup>
and under <runtime> add:
<loadFromRemoteSources enabled="true" />
Just adding the requireRuntime element is insufficient and results in an security related error message mentioning the loadFromRemoteSources switch. I found something about the switch on this social.msdn post, where David DeWinter wrote:
Caveat: I'm not on the security team but will attempt to answer this nonetheless...
What's happening here is that the build tasks for Silverlight are attempting to load an assembly that, in previous versions of the CLR, would classify it as a partial trust assembly based on its evidence (e.g. its zone) according to CAS policy.
In CLR 4.0, CAS policy is totally deprecated and is not even enabled by default. Under the circumstances, though, it appears the CLR throws an Exception when what would be a partial trust load in CLR 2.0 is a full trust load in CLR 4.0.
The loadFromRemoteSources switch the Exception message refers to is in the runtime element under configuration and looks like this:
<loadFromRemoteSources enabled="true|false" />
This will not enable legacy CAS policy but will allow you (or, in this case, the build system) to load remote assemblies with the same permissions as the host AppDomain. In this case it seems as though you could modify the configuration for the build system (which I assume in this case would be Visual Studio: %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config) to enable this switch.
If you don't want to modify that configuratino then you can set the environment variable COMPLUS_EnableLegacyCASPolicy to 1, which will enable CAS Policy that was present in CLR 2.0 and also allow Silverlight to load this task.
Hope that helps. David