NUnit components for version 4.0.30319 of the CLR are not installed

[dexxa]

i am getting this error when i tried to run tests.

System.ArgumentException: NUnit components for version 4.0.30319 of
the CLR are not installed
Parameter name: targetRuntime

some info about my setup:
OS: win 7 x64
NUnit.2.5.10.11092
.net framework 4
platform target: any cpu
pretty much followed this tutorial:
http://www.pluralsight-training.net/microsoft/players/PSODPlayer.aspx?author=scott-allen&name=mvc3-building-intro&mode=live&clip=0&course=aspdotnet-mvc3-intro

[Charlie Poole]

A few questions:

Did you do the msi install or use the zip?

Any changes to the NUnit directory structure?

Are you running the gui or the console runner? Standard or x86?

Under what version of .NET is NUnit running? (see Help | About NUnit)

What platform was your test assembly built for (x86, 64bit or Any CPU)?

Charlie

--
You received this message because you are subscribed to the Google Groups "NUnit-Discuss" group.
To post to this group, send email to nunit-...@googlegroups.com.
To unsubscribe from this group, send email to nunit-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nunit-discuss?hl=en.

[dexxa]

it's a zip. well i installed from Add Library Package Reference option
in VS 2010
no changes to nunit directory
i get the same message from both gui and console standard or x86
.NET 2.0
built for any cpu

On May 21, 7:20 am, Charlie Poole <nunit...@gmail.com> wrote:
> A few questions:
>
> Did you do the msi install or use the zip?
>
> Any changes to the NUnit directory structure?
>
> Are you running the gui or the console runner? Standard or x86?
>
> Under what version of .NET is NUnit running? (see Help | About NUnit)
>
> What platform was your test assembly built for (x86, 64bit or Any CPU)?
>
> Charlie
>
>
>
>
>
>
>
> On Fri, May 20, 2011 at 12:53 PM, dexxa <dexx...@gmail.com> wrote:
> > i am getting this error when i tried to run tests.
>
> > System.ArgumentException: NUnit components for version 4.0.30319 of
> > the CLR are not installed
> > Parameter name: targetRuntime
>
> > some info about my setup:
> > OS: win 7 x64
> > NUnit.2.5.10.11092
> > .net framework 4
> > platform target: any cpu
> > pretty much followed this tutorial:
>

> >http://www.pluralsight-training.net/microsoft/players/PSODPlayer.aspx...

[Charlie Poole]

Hi,

On Sat, May 21, 2011 at 10:41 AM, dexxa <dex...@gmail.com> wrote:

it's a zip. well i installed from Add Library Package Reference option
in VS 2010

I've never done this and I don't have VS2010 on this computer to try it out.
Has anyone else got experience with this approach?
 

no changes to nunit directory

So you should have a tree like

NUnit 2.6
   /bin
        /net-1.1
        /lib
       /framework
       /tests
    /net-2.0
       /lib
       /framework
       /tests
 

i get the same message from both gui and console standard or x86
.NET 2.0
built for any cpu

Running under 2.0 as you are, NUnit is correctly recognizing that it
needs to load the assembly under 4.0. It *should* then figure out that
the current 2.0 build is OK for running under 4.0.

The only way I can think of that it would fail to find the correct version
of nunit-agent.exe in the net-2.0 directory, is if the copy of NUnit you
 are using is not like what I outlined above - that structure is absolutely
required for it to work. I'm a little suspicious of the Add Library Package
Reference option, but that may only be because I have not used it.

Charlie

[dexxa]

structure looks like this actually
http://imgur.com/yVCK8

On May 21, 11:44 am, Charlie Poole <nunit...@gmail.com> wrote:
> Hi,
>

[Charlie Poole]

I'm visiting family and don't have time to test, but I'm pretty sure this won't
work. In fact - I guess you already knew that. :-)

I suggest installing a separate copy of NUnit as distributed by us. Either
install the msi or just unzip the zip without any change to the file structure.
Provided it's the same version, there should be no need to change any
of your project references.

Please let us know if this works. It's possible to install NUnit in non-standard
ways and have it work but it generally takes an intimate knowledge of how
it works, particularly as regards to running across various runtimes.

Charlie

[Rafael Teixeira]

"Add Library Package Reference" means he installed the NUnit Nuget, which is a bare bones solution, that copies things (libs and tools) and adds references to core NUnit libs but doesn't automate much anything else. I haven't had the time to continue work on my MSBuild.Nunit project which can further automate the test-on-build  scenario, and can be made to properly set things up a bit better, but I think things can't be made smooth without adding a good VS plugin for integrating NUnit and VS, like Testdriven.NET.

Just to clarify, Nuget packages (as of version 1.3) have limited installation abilities (see Nuget project at Codeplex), but in particular the NUnit Nuget doesn't use the more advanced abilites, like installing framework-version/profile-specific versions of libs, or using powershell scripts to register/install the tools in a more workable setup. With Nuget the tools are shared per-solution, so each solution will have a copy of the tools, which is nice from the point of view of having each project really match the tools and referenced libs as soon as you checkout a fresh copy from the source repository. What is needed is to setup things so that the tools can behave properly when installed in that way, which is the aim of my MSBuild.NUnit project, at least in the 'build' side of things, but I'm not sure what can be done to run correctly the GUI-runner interactively from that install.

Just my two cents,

Rafael "Monoman" Teixeira
---------------------------------------
"The most exciting phrase to hear in science, the one that heralds new discoveries, is not 'Eureka!' (I found it!) but 'That's funny ...'"
Isaac Asimov
US science fiction novelist & scholar (1920 - 1992)

[Charlie Poole]

OK, I didn't understand the terminology.

FWIW, when I was talking to folks on the original Nu project about putting out the NUnit
package myself as part of the NUnit release, we ended up disagreeing about whether
it should only include the 'lib' part or should also install the 'tool' When it became
nuget, I stopped participating, in part because of this disagreement, which is fairly
fundamental. The folks putting out the 'tool' install of NUnit wanted to keep doing
it and I did not (do not) think it's a good idea.

OTOH, it's definitely possible to make NUnit work in an environment where the entire
NUnit package is installed in the project and saved in a repository. The zip package
is sufficient to do this and no install-time executable is needed. I've even set it
up this way myself when a client absolutely insisted on it.

Honestly, I believe that a packager who is packaging a product in a way that the
upstream developers don't agree with is only asking for trouble.

I'm not 100% sure why the structure created by Nuget is not working. It has something
to do with the way NUnit locates the nunit-agent program that is used to execute
the tests in a separate process. It may be a bug in NUnit and I'll be glad to fix it
if somebody is able to figure out where the problem lies. However, since this is
a non-standard install, I'm not ready to spend time on trying to duplicate and
debug it myself. I do have a strong suspicion that the problem may not occur
with the latest code or with the NUnit 2.6 pre-release I put out a while back.

Things to check, if anyone wants to put time into this:

* Do the tests run OK using a standard install of NUnit?
* Do the tests run OK using a Nuget install based on the 2.6 code (if that exists)?
* Do the tests run OK if you move all of NUnit into tools/net-2.0?.


Charlie

[dexxa]

installed the latest 2.5
removed old references and added new ones in.
built and ran the test again.
got the same output(nunit-console.exe or nunit-console-x86.exe; same
for gui)

c:\DotNet\MVCBlog>"c:\Program Files (x86)\NUnit 2.5.10\bin
\net-2.0\nunit-console.exe" MVCBlog.Test\obj\Debug\MVCBlog.Test.dll
NUnit version 2.5.10.11092
Copyright (C) 2002-2009 Charlie Poole.
Copyright (C) 2002-2004 James W. Newkirk, Michael C. Two, Alexei A.
Vorontsov.
Copyright (C) 2000-2002 Philip Craig.
All Rights Reserved.

Runtime Environment -
OS Version: Microsoft Windows NT 6.1.7600.0
CLR Version: 2.0.50727.4959 ( Net 2.0 )

ProcessModel: Default DomainUsage: Single
Execution Runtime: Default
Unhandled Exception:

System.ArgumentException: NUnit components for version 4.0.30319 of
the CLR are not installed
Parameter name: targetRuntime

at NUnit.Util.TestAgency.LaunchAgentProcess(RuntimeFramework
targetRuntime, Boolean enableDebug)
at NUnit.Util.TestAgency.CreateRemoteAgent(RuntimeFramework
framework, Int32 waitTime, Boolean enableDebug)
at NUnit.Util.TestAgency.GetAgent(RuntimeFramework framework, Int32
waitTime, Boolean enableDebug)
at NUnit.Util.ProcessRunner.Load(TestPackage package)
at NUnit.ConsoleRunner.ConsoleUi.Execute(ConsoleOptions options)
at NUnit.ConsoleRunner.Runner.Main(String[] args)

> > On Sat, May 21, 2011 at 12:44 PM, Charlie Poole <nunit...@gmail.com>wrote:
>
> >> Hi,
>

[Charlie Poole]

Hi,

You should not be running your tests out of the obj\Debug directory but
out of bin\Debug - or wherever your output is sent. That's because
VS copies referenced assemblies to the output directory (usually bin\Debug)
but they are not present in the obj\Debug directory.

Charlie

[dexxa]

same result when i run it from bin though.

On May 23, 2:32 pm, Charlie Poole <nunit...@gmail.com> wrote:
> Hi,
>

> ...
>
> read more »

[Charlie Poole]

OK, I suppose if it can't find the NUnit components it never gets far
enough to encounter the error you will (probably) get by running from obj.

Since you are now having the problem with an NUnit install, I'll try it
myself this evening.

Charlie

[Charlie Poole]

I have experimented with this and cannot duplicate your problem. Specifically,
I am able to run NUnit under .NET 2.0 and load tests in a separate process
under .NET 4.0.

The message you are getting indicates that NUnit is unable to find some of
its components and so leads me to suspect that the installation failed in some way.

Charlie

[Charlie Poole]

Hi Neil,

I'm putting us back on the list...

NUnit uses a Uri to determine the location where it's installed. Within a Uri,
the '#' character would of course be encoded. I seem to recall that there was
once some special code to deal with this but I don't believe it's present any
longer.

Could you please file a specific bug for this situation? If nobody else has
time to work on it, I'll look at it when I'm back from vacation.

Charlie

On Wed, Sep 14, 2011 at 7:28 AM, Neil Menzies <sizen...@gmail.com> wrote:
> I've encountered this problem too, and it appears to occur only if
> NUnit (2.5.10.11092, installed from zip) is installed in a path with a
> '#' character in it.
> I can run the nunit gui from the path with a #, but as soon as I try
> to add an assembly it barfs with the CLR message.
>
> If I replace the '#' character in the folder in the path with a '.',
> and re-run it, then all works fine.
>
> Don't know if there are any other offending characters which will also
> cause the problem.
>
> HTH diagnostics.
>
> Neil Menzies

>
> On May 25, 5:18 pm, Charlie Poole <nunit...@gmail.com> wrote:
>> I have experimented with this and cannot duplicate your problem.
>> Specifically,
>> I am able to run NUnit under .NET 2.0 and load tests in a separate process
>> under .NET 4.0.
>>
>> The message you are getting indicates that NUnit is unable to find some of
>> its components and so leads me to suspect that the installation failed in
>> some way.
>>
>> Charlie
>>

>> On Mon, May 23, 2011 at 1:35 PM, Charlie Poole <nunit...@gmail.com> wrote:
>> > OK, I suppose if it can't find the NUnit components it never gets far
>> > enough to encounter the error you will (probably) get by running from obj.
>>
>> > Since you are now having the problem with an NUnit install, I'll try it
>> > myself this evening.
>>
>> > Charlie
>>

>> ...
>>
>> read more »