2.5.5 cannot find fixture for framework 4.0

[Martin Jones]

Just downloaded v2.5.5.10112 of Nunit. In a new VS2010 project I am unable to get either the nunit.exe or nunit-console.exe programs to recognize my test cases. The programs run, and after a while tell me 'can't find test fixture' in the case of nunit-console, and a similar message with nunit. The test class has TestFixture applied, and is public, the method has TestCase applied (started as Test) and is also public. The project has references to the 2.5.5 versions of nunit.core.dll and nunit.framework.dll.

I changed the target runtime to 3.5, recompiled, and it has picked up on the test cases immediately (I'm still using the 2.5.5 dlls).

Possibly of interest, the gui really wants to use version 2 of the framework. I tried requesting version 4 from the menu but after a while, it fails to find the test and reverts back to version 2 of the framework.

I'm using VS2010 (evaluation edition at the moment), on 64 bit Vista.

I've tried to find a solution elsewhere, and full apologies in advance if it's a school-boy error on my part.

Thanks for your time on the project.

[Jv (jv-ravichandran)]

Hi Martin,

I am trying to replicate the bug you have reported in your machine. Can you
please run the same tests on a x86 machine on the .net 4.0 framework and let
me know if it works?

Jv

On Tue, May 18, 2010 at 9:20 AM, Martin Jones <email address hidden>wrote:

> Public bug reported:
>
> Just downloaded v2.5.5.10112 of Nunit. In a new VS2010 project I am
> unable to get either the nunit.exe or nunit-console.exe programs to
> recognize my test cases. The programs run, and after a while tell me
> 'can't find test fixture' in the case of nunit-console, and a similar
> message with nunit. The test class has TestFixture applied, and is
> public, the method has TestCase applied (started as Test) and is also
> public. The project has references to the 2.5.5 versions of
> nunit.core.dll and nunit.framework.dll.
>
> I changed the target runtime to 3.5, recompiled, and it has picked up on
> the test cases immediately (I'm still using the 2.5.5 dlls).
>
> Possibly of interest, the gui really wants to use version 2 of the
> framework. I tried requesting version 4 from the menu but after a while,
> it fails to find the test and reverts back to version 2 of the
> framework.
>
> I'm using VS2010 (evaluation edition at the moment), on 64 bit Vista.
>
> I've tried to find a solution elsewhere, and full apologies in advance
> if it's a school-boy error on my part.
>
> Thanks for your time on the project.
>
> ** Affects: nunitv2
> Importance: Undecided
> Status: New
>
> --
> 2.5.5 cannot find fixture for framework 4.0
> https://bugs.launchpad.net/bugs/582051
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
>
> Status in NUnit V2 Test Framework: New
>
> Bug description:
> Just downloaded v2.5.5.10112 of Nunit. In a new VS2010 project I am unable
> to get either the nunit.exe or nunit-console.exe programs to recognize my
> test cases. The programs run, and after a while tell me 'can't find test
> fixture' in the case of nunit-console, and a similar message with nunit. The
> test class has TestFixture applied, and is public, the method has TestCase
> applied (started as Test) and is also public. The project has references to
> the 2.5.5 versions of nunit.core.dll and nunit.framework.dll.
>
> I changed the target runtime to 3.5, recompiled, and it has picked up on
> the test cases immediately (I'm still using the 2.5.5 dlls).
>
> Possibly of interest, the gui really wants to use version 2 of the
> framework. I tried requesting version 4 from the menu but after a while, it
> fails to find the test and reverts back to version 2 of the framework.
>
> I'm using VS2010 (evaluation edition at the moment), on 64 bit Vista.
>
> I've tried to find a solution elsewhere, and full apologies in advance if
> it's a school-boy error on my part.
>
> Thanks for your time on the project.
>
>
>

--
Regards,

Ravichandran Jv
http://ravichandranjv.blogspot.com

[Jv (jv-ravichandran)]

Hi Martin,

I installed VS 2010 Ultimate in my machine to replicate your bug scenario
but it works in my machine properly. I saved the .nunit project file in the
bin\debug folder of my VS 2010 test project using Nunit 2.5.10112. I ran the
tests using the default project settings, which says use the default version
of the framework (which will translate to whichever framework against which
the test assembly has been compiled with) and it works absolutely fine.

So, the only difference seems to be in your 64 bit machine. I will try to
replicate the scenario in a 64-bit machine and let you know. kindly reply if
the assembly gets loaded on a 32 bit machine then we will be sure that it is
something specific to 64-bit machines.

Regards,

Jv
http://ravichandranjv.blogspot.com
On Tue, May 18, 2010 at 9:20 AM, Martin Jones <email address hidden>wrote:

> Public bug reported:
>
> Just downloaded v2.5.5.10112 of Nunit. In a new VS2010 project I am
> unable to get either the nunit.exe or nunit-console.exe programs to
> recognize my test cases. The programs run, and after a while tell me
> 'can't find test fixture' in the case of nunit-console, and a similar
> message with nunit. The test class has TestFixture applied, and is
> public, the method has TestCase applied (started as Test) and is also
> public. The project has references to the 2.5.5 versions of
> nunit.core.dll and nunit.framework.dll.
>
> I changed the target runtime to 3.5, recompiled, and it has picked up on
> the test cases immediately (I'm still using the 2.5.5 dlls).
>
> Possibly of interest, the gui really wants to use version 2 of the
> framework. I tried requesting version 4 from the menu but after a while,
> it fails to find the test and reverts back to version 2 of the
> framework.
>
> I'm using VS2010 (evaluation edition at the moment), on 64 bit Vista.
>
> I've tried to find a solution elsewhere, and full apologies in advance
> if it's a school-boy error on my part.
>
> Thanks for your time on the project.
>
> ** Affects: nunitv2
> Importance: Undecided
> Status: New
>
> --
> 2.5.5 cannot find fixture for framework 4.0
> https://bugs.launchpad.net/bugs/582051
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
>
> Status in NUnit V2 Test Framework: New
>
> Bug description:
> Just downloaded v2.5.5.10112 of Nunit. In a new VS2010 project I am unable
> to get either the nunit.exe or nunit-console.exe programs to recognize my
> test cases. The programs run, and after a while tell me 'can't find test
> fixture' in the case of nunit-console, and a similar message with nunit. The
> test class has TestFixture applied, and is public, the method has TestCase
> applied (started as Test) and is also public. The project has references to
> the 2.5.5 versions of nunit.core.dll and nunit.framework.dll.
>
> I changed the target runtime to 3.5, recompiled, and it has picked up on
> the test cases immediately (I'm still using the 2.5.5 dlls).
>
> Possibly of interest, the gui really wants to use version 2 of the
> framework. I tried requesting version 4 from the menu but after a while, it
> fails to find the test and...

[Martin Jones (martin-martinjones)]

Hi Jv,

Thanks for the quick response, and can I just quickly say thankyou,
thankyou very much for nunit.

I'm having trouble repeating the bug this morning, I remember that there
was something I left off the report last night that might be useful. Let
me explain what I have done first though.

The VS solution is in SVN so I checked it out to a 32 bit machine, and
left it in it's current 'target framework 3.5' position and it worked
fine. I changed the solution to target to framework 3.5 and it worked
fine as well. All of the target changes are on the VS projects, not nunit.

I went back to the 64 bit machine, reloaded the project and checked that
it still worked with a framework 3.5 target. It did. I then changed it
to a 4.0 project and it worked! I do not believe that anything else had
changed.

In case there was something being affected by it having run once, I
created a new 64 bit, very simple test project, and it ran fine.

In all these cases I am running a class library by setting the debug
executable to nunit.exe and giving it the name of the .dll containing
the testing code - I don't use an .nunit file.

So, I have been unable to repeat the issue I was having last night. I'm
sure you get some bogus bug reports, and I'll be the first one to admit
that I can make silly mistakes, but I really haven't made any changes
from last night other than moving it back to a framework 4.0 target.

Last night, there was one odd thing that happened while initially trying
to get nunit running. I had the error about not finding the test fixture
on the very first run. On the second attempt, I believe it found the
text fixture, but not on any subsequent runs. I believe that it was the
nunit 2.5.5 version that was running because visually it appeared
slightly different (with the tick marks) to 2.4.8 that I had been using
previously. The reason that I didn't include it in the report last night
was that I was working with two solutions and assumed that I had
accidently run an old solution where I was copying the using statements
from. Because I couldn't repeat it - I put it down to this other
solution and assumed that I was mistaken. I'm not so sure now.

My solution is now set to framework 4.0 and I will be using nunit
2.5.5.10112 for the next couple of days. If I can reproduce the error
once more, then I will let you know. If I do reproduce the error, should
I reply to this email again?

Martin

Jv wrote:
> Hi Martin,
>
> I installed VS 2010 Ultimate in my machine to replicate your bug scenario
> but it works in my machine properly. I saved the .nunit project file in the
> bin\debug folder of my VS 2010 test project using Nunit 2.5.10112. I ran the
> tests using the default project settings, which says use the default version
> of the framework (which will translate to whichever framework against which
> the test assembly has been compiled with) and it works absolutely fine.
>
> So, the only difference seems to be in your 64 bit machine. I will try to
> replicate the scenario in a 64-bit machine and let you know. kindly reply if
> the assembly gets loaded on a 32 bit machine then we will be sure that it is
> something specifi...

[Charlie Poole (charlie.poole)]

One possibility is that your setup to execute NUnit as a debug app was not
quite right at one time. This is very easy to do. :-)

Yes, this is a good place to continue the discussion until/unless we decide
it's actually an NUnit bug.

Charlie

On Tue, May 18, 2010 at 3:31 PM, Martin Jones <email address hidden>wrote:

> Hi Jv,
>
> Thanks for the quick response, and can I just quickly say thankyou,
> thankyou very much for nunit.
>
> I'm having trouble repeating the bug this morning, I remember that there
> was something I left off the report last night that might be useful. Let
> me explain what I have done first though.
>
> The VS solution is in SVN so I checked it out to a 32 bit machine, and
> left it in it's current 'target framework 3.5' position and it worked
> fine. I changed the solution to target to framework 3.5 and it worked
> fine as well. All of the target changes are on the VS projects, not nunit.
>
> I went back to the 64 bit machine, reloaded the project and checked that
> it still worked with a framework 3.5 target. It did. I then changed it
> to a 4.0 project and it worked! I do not believe that anything else had
> changed.
>
> In case there was something being affected by it having run once, I
> created a new 64 bit, very simple test project, and it ran fine.
>
> In all these cases I am running a class library by setting the debug
> executable to nunit.exe and giving it the name of the .dll containing
> the testing code - I don't use an .nunit file.
>
> So, I have been unable to repeat the issue I was having last night. I'm
> sure you get some bogus bug reports, and I'll be the first one to admit
> that I can make silly mistakes, but I really haven't made any changes
> from last night other than moving it back to a framework 4.0 target.
>
> Last night, there was one odd thing that happened while initially trying
> to get nunit running. I had the error about not finding the test fixture
> on the very first run. On the second attempt, I believe it found the
> text fixture, but not on any subsequent runs. I believe that it was the
> nunit 2.5.5 version that was running because visually it appeared
> slightly different (with the tick marks) to 2.4.8 that I had been using
> previously. The reason that I didn't include it in the report last night
> was that I was working with two solutions and assumed that I had
> accidently run an old solution where I was copying the using statements
> from. Because I couldn't repeat it - I put it down to this other
> solution and assumed that I was mistaken. I'm not so sure now.
>
> My solution is now set to framework 4.0 and I will be using nunit
> 2.5.5.10112 for the next couple of days. If I can reproduce the error
> once more, then I will let you know. If I do reproduce the error, should
> I reply to this email again?
>
> Martin
>
>
> Jv wrote:
> > Hi Martin,
> >
> > I installed VS 2010 Ultimate in my machine to replicate your bug scenario
> > but it works in my machine properly. I saved the .nunit project file in
> the
> > bin\debug folder of my VS 2010 test project using Nunit 2.5.10112. I ran
> the
> > tests using the default project settings, which says use the default
> version
> > o...

[Martin Jones (martin-martinjones)]

Charlie,

 From the first comment, yes, as ever it could be user error, but is
there something different I would need to do to run from 2.5.5 compared
to 2.4.8? I've always had success there. I follow a simple pattern of
setting up the debug executable to be nunit.exe, I then set the command
line arguments to just the name of the .dll file (no directories or
anything else).

Since I started using it I have run into the problem of the debugger not
attaching to the correct process, I made the modifications listed here:
http://frater.wordpress.com/2010/05/04/debugging-nunit-tests-under-visual-studio-2010/
and it appears to be working.

This may, of course, mean that I'm not testing against the problem I
think I saw last night. If anyone comes back to you with the same
problem, then please do come back to me if I can help further.

Another problem that may become more common is I think that nunit agent
listens on an IP address. My AV (PC-Cillin) didn't like that one bit and
reckoned that it was something highly suspect. I re-assured it, but look
out for future bug reports in this area.

Thanks,

Martin

Charlie Poole wrote:
> One possibility is that your setup to execute NUnit as a debug app was not
> quite right at one time. This is very easy to do. :-)
>
> Yes, this is a good place to continue the discussion until/unless we decide
> it's actually an NUnit bug.
>
> Charlie
>
> On Tue, May 18, 2010 at 3:31 PM, Martin Jones
> <email address hidden>wrote:
>
>> Hi Jv,
>>
>> Thanks for the quick response, and can I just quickly say thankyou,
>> thankyou very much for nunit.
>>
>> I'm having trouble repeating the bug this morning, I remember that there
>> was something I left off the report last night that might be useful. Let
>> me explain what I have done first though.
>>
>> The VS solution is in SVN so I checked it out to a 32 bit machine, and
>> left it in it's current 'target framework 3.5' position and it worked
>> fine. I changed the solution to target to framework 3.5 and it worked
>> fine as well. All of the target changes are on the VS projects, not nunit.
>>
>> I went back to the 64 bit machine, reloaded the project and checked that
>> it still worked with a framework 3.5 target. It did. I then changed it
>> to a 4.0 project and it worked! I do not believe that anything else had
>> changed.
>>
>> In case there was something being affected by it having run once, I
>> created a new 64 bit, very simple test project, and it ran fine.
>>
>> In all these cases I am running a class library by setting the debug
>> executable to nunit.exe and giving it the name of the .dll containing
>> the testing code - I don't use an .nunit file.
>>
>> So, I have been unable to repeat the issue I was having last night. I'm
>> sure you get some bogus bug reports, and I'll be the first one to admit
>> that I can make silly mistakes, but I really haven't made any changes
>> from last night other than moving it back to a framework 4.0 target.
>>
>> Last night, there was one odd thing that happened while initially trying
>> to get nunit running. I had the error about not finding the test fixture
>> on the very first run. On the second attempt, I belie...

[Jv (jv-ravichandran)]

Hi Charlie,

It does look like a bug...

what happens is, if you run the tests from NUnit separately then it works
but if you specify to VS 2010 to run the tests via the Debug executable
option then this causes the System.ApplicationException that "unable to find
tests in assembly".

After this even if you run NUnit separately and create a nw .nunit project
and attempt to add the assembly, NUnit gives the above exception.

Seems weird but VS 2010, it seems, corrupts something it runs NUnit as a
Debug executable. For this to to be replicated you should not give the
/fixture option but simply the /run option. I tried with the /fixture option
but VS simply refused to acknowledge the usage. Maybe something wrong with
the syntax that i used for /fixture= in the command line argument of VS
project properties.

I haven't tried this but, at a guess, a fresh installation of NUnit should
make it work again.

Jv
On Tue, May 18, 2010 at 7:46 PM, Charlie Poole <email address hidden> wrote:

> One possibility is that your setup to execute NUnit as a debug app was not
> quite right at one time. This is very easy to do. :-)
>
> Yes, this is a good place to continue the discussion until/unless we decide
> it's actually an NUnit bug.
>
> Charlie
>
> On Tue, May 18, 2010 at 3:31 PM, Martin Jones
> <email address hidden>wrote:
>
> > Hi Jv,
> >
> > Thanks for the quick response, and can I just quickly say thankyou,
> > thankyou very much for nunit.
> >
> > I'm having trouble repeating the bug this morning, I remember that there
> > was something I left off the report last night that might be useful. Let
> > me explain what I have done first though.
> >
> > The VS solution is in SVN so I checked it out to a 32 bit machine, and
> > left it in it's current 'target framework 3.5' position and it worked
> > fine. I changed the solution to target to framework 3.5 and it worked
> > fine as well. All of the target changes are on the VS projects, not
> nunit.
> >
> > I went back to the 64 bit machine, reloaded the project and checked that
> > it still worked with a framework 3.5 target. It did. I then changed it
> > to a 4.0 project and it worked! I do not believe that anything else had
> > changed.
> >
> > In case there was something being affected by it having run once, I
> > created a new 64 bit, very simple test project, and it ran fine.
> >
> > In all these cases I am running a class library by setting the debug
> > executable to nunit.exe and giving it the name of the .dll containing
> > the testing code - I don't use an .nunit file.
> >
> > So, I have been unable to repeat the issue I was having last night. I'm
> > sure you get some bogus bug reports, and I'll be the first one to admit
> > that I can make silly mistakes, but I really haven't made any changes
> > from last night other than moving it back to a framework 4.0 target.
> >
> > Last night, there was one odd thing that happened while initially trying
> > to get nunit running. I had the error about not finding the test fixture
> > on the very first run. On the second attempt, I believe it found the
> > text fixture, but not on any subsequent runs. I believe that it was the
> > nunit 2.5.5 version that was r...

[Jv (jv-ravichandran)]

Hi Charlie,

And more to it. I took Martin's link to the blog on how to Debug with VS2010
and added the startup tag to point to v4 and from then on NUnit crashes so I
remove the startup element from the nunit.exe.config file but still NUnit
fails to start! I tried debugging from VS 2010 and it throws a
FileNotFoundException for NUnitGUIRunner. It seems that the assembly
reference to the GAC version is no longer valid! It does seem that VS does
something fishy when using the nunit-agent for debugging:)

Jv

On Wed, May 19, 2010 at 11:36 AM, RJV <email address hidden> wrote:

> Hi Charlie,
>
> It does look like a bug...
>
> what happens is, if you run the tests from NUnit separately then it works
> but if you specify to VS 2010 to run the tests via the Debug executable
> option then this causes the System.ApplicationException that "unable to find
> tests in assembly".
>
> After this even if you run NUnit separately and create a nw .nunit project
> and attempt to add the assembly, NUnit gives the above exception.
>
> Seems weird but VS 2010, it seems, corrupts something it runs NUnit as a
> Debug executable. For this to to be replicated you should not give the
> /fixture option but simply the /run option. I tried with the /fixture option
> but VS simply refused to acknowledge the usage. Maybe something wrong with
> the syntax that i used for /fixture= in the command line argument of VS
> project properties.
>
> I haven't tried this but, at a guess, a fresh installation of NUnit should
> make it work again.
>
> Jv
> On Tue, May 18, 2010 at 7:46 PM, Charlie Poole <email address hidden>wrote:
>
>> One possibility is that your setup to execute NUnit as a debug app was not
>> quite right at one time. This is very easy to do. :-)
>>
>> Yes, this is a good place to continue the discussion until/unless we
>> decide
>> it's actually an NUnit bug.
>>
>> Charlie
>>
>> On Tue, May 18, 2010 at 3:31 PM, Martin Jones
>> <email address hidden>wrote:
>>
>> > Hi Jv,
>> >
>> > Thanks for the quick response, and can I just quickly say thankyou,
>> > thankyou very much for nunit.
>> >
>> > I'm having trouble repeating the bug this morning, I remember that there
>> > was something I left off the report last night that might be useful. Let
>> > me explain what I have done first though.
>> >
>> > The VS solution is in SVN so I checked it out to a 32 bit machine, and
>> > left it in it's current 'target framework 3.5' position and it worked
>> > fine. I changed the solution to target to framework 3.5 and it worked
>> > fine as well. All of the target changes are on the VS projects, not
>> nunit.
>> >
>> > I went back to the 64 bit machine, reloaded the project and checked that
>> > it still worked with a framework 3.5 target. It did. I then changed it
>> > to a 4.0 project and it worked! I do not believe that anything else had
>> > changed.
>> >
>> > In case there was something being affected by it having run once, I
>> > created a new 64 bit, very simple test project, and it ran fine.
>> >
>> > In all these cases I am running a class library by setting the debug
>> > executable to nunit.exe and giving it the name of the .dll containing
>> > the testing code - I ...

[Jv (jv-ravichandran)]

Hi Charlie,

I downloaded NUnit afresh and deleted all NUnit folders and installed NUnit
and it works again. Now, I am going to try with VS2010 again and see what it
is that VS does when debugging. I also found that the NUnit Agent processes
are not closed by VS for each debug execution failure.

Jv
On Wed, May 19, 2010 at 12:00 PM, RJV <email address hidden> wrote:

> Hi Charlie,
>
> And more to it. I took Martin's link to the blog on how to Debug with
> VS2010 and added the startup tag to point to v4 and from then on NUnit
> crashes so I remove the startup element from the nunit.exe.config file but
> still NUnit fails to start! I tried debugging from VS 2010 and it throws a
> FileNotFoundException for NUnitGUIRunner. It seems that the assembly
> reference to the GAC version is no longer valid! It does seem that VS does
> something fishy when using the nunit-agent for debugging:)
>
> Jv
>
> On Wed, May 19, 2010 at 11:36 AM, RJV <email address hidden> wrote:
>
>> Hi Charlie,
>>
>> It does look like a bug...
>>
>> what happens is, if you run the tests from NUnit separately then it works
>> but if you specify to VS 2010 to run the tests via the Debug executable
>> option then this causes the System.ApplicationException that "unable to find
>> tests in assembly".
>>
>> After this even if you run NUnit separately and create a nw .nunit project
>> and attempt to add the assembly, NUnit gives the above exception.
>>
>> Seems weird but VS 2010, it seems, corrupts something it runs NUnit as a
>> Debug executable. For this to to be replicated you should not give the
>> /fixture option but simply the /run option. I tried with the /fixture option
>> but VS simply refused to acknowledge the usage. Maybe something wrong with
>> the syntax that i used for /fixture= in the command line argument of VS
>> project properties.
>>
>> I haven't tried this but, at a guess, a fresh installation of NUnit should
>> make it work again.
>>
>> Jv
>> On Tue, May 18, 2010 at 7:46 PM, Charlie Poole <email address hidden>wrote:
>>
>>> One possibility is that your setup to execute NUnit as a debug app was
>>> not
>>> quite right at one time. This is very easy to do. :-)
>>>
>>> Yes, this is a good place to continue the discussion until/unless we
>>> decide
>>> it's actually an NUnit bug.
>>>
>>> Charlie
>>>
>>> On Tue, May 18, 2010 at 3:31 PM, Martin Jones
>>> <email address hidden>wrote:
>>>
>>> > Hi Jv,
>>> >
>>> > Thanks for the quick response, and can I just quickly say thankyou,
>>> > thankyou very much for nunit.
>>> >
>>> > I'm having trouble repeating the bug this morning, I remember that
>>> there
>>> > was something I left off the report last night that might be useful.
>>> Let
>>> > me explain what I have done first though.
>>> >
>>> > The VS solution is in SVN so I checked it out to a 32 bit machine, and
>>> > left it in it's current 'target framework 3.5' position and it worked
>>> > fine. I changed the solution to target to framework 3.5 and it worked
>>> > fine as well. All of the target changes are on the VS projects, not
>>> nunit.
>>> >
>>> > I went back to the 64 bit machine, reloaded the project and checked
>>> that
>>> > it still worked wit...

[Martin Jones (martin-martinjones)]

Hi Jv, Charlie,

Just throwing in some further details in case this helps to diagnose the
problem.

I found that initially it was unable to find the test fixture for both
nunit.exe and nunit-console.exe. Jv - it looks like you had luck from
the console initially. Did you run from the console first, and then try
from visual studio? Is something being cached between runs?

If there is some kind of cache, it is possibly flushed on VS exit, or
when the machine is restarted (/tmp equivalent?). Initially I was having
problems on Monday night, and then when I tried to reproduce them on
Tuesday morning I failed. It was then that I noticed the extra
nunit-agent.exe process and the fact that, although it was now running
the tests the debugger was not stopping the program.

The information from the blog was used to get the debugger working
nicely with the nunit executable. The changes only seem to mean that the
tests are run in the same process, but that means that F5 attaches the
debugger to the correct process.

Before I made the changes from the blog I can confirm that I saw an
nunit-agent.exe hanging around in the list of processes after the nunit
gui had terminated.

Thanks,

Martin

Jv wrote:
> Hi Charlie,
>
> I downloaded NUnit afresh and deleted all NUnit folders and installed NUnit
> and it works again. Now, I am going to try with VS2010 again and see what it
> is that VS does when debugging. I also found that the NUnit Agent processes
> are not closed by VS for each debug execution failure.
>
> Jv
> On Wed, May 19, 2010 at 12:00 PM, RJV <email address hidden> wrote:
>
>> Hi Charlie,
>>
>> And more to it. I took Martin's link to the blog on how to Debug with
>> VS2010 and added the startup tag to point to v4 and from then on NUnit
>> crashes so I remove the startup element from the nunit.exe.config file but
>> still NUnit fails to start! I tried debugging from VS 2010 and it throws a
>> FileNotFoundException for NUnitGUIRunner. It seems that the assembly
>> reference to the GAC version is no longer valid! It does seem that VS does
>> something fishy when using the nunit-agent for debugging:)
>>
>> Jv
>>
>> On Wed, May 19, 2010 at 11:36 AM, RJV <email address hidden> wrote:
>>
>>> Hi Charlie,
>>>
>>> It does look like a bug...
>>>
>>> what happens is, if you run the tests from NUnit separately then it works
>>> but if you specify to VS 2010 to run the tests via the Debug executable
>>> option then this causes the System.ApplicationException that "unable to find
>>> tests in assembly".
>>>
>>> After this even if you run NUnit separately and create a nw .nunit project
>>> and attempt to add the assembly, NUnit gives the above exception.
>>>
>>> Seems weird but VS 2010, it seems, corrupts something it runs NUnit as a
>>> Debug executable. For this to to be replicated you should not give the
>>> /fixture option but simply the /run option. I tried with the /fixture option
>>> but VS simply refused to acknowledge the usage. Maybe something wrong with
>>> the syntax that i used for /fixture= in the command line argument of VS
>>> project properties.
>>>
>>> I haven't tried this but, at a guess, a fresh installation of NUnit...

[Charlie Poole (charlie.poole)]

Hello Martin,

The problem of debugging is separate. If you are running tests in a separate
process, then you have to attach to that process. Visual Studio won't do
that for you automatically when the initial process launches the test
process. The trick is to wait for the tests to load and then attach to
nunit-agent. You can determine whether nunit-agent is in use by using Tools
| Test Assemblies...

For the fundamental problem... choose one scenario and determine exactly
what versions (note the plural) of .NET are being used. Again, Tools | Test
Assemblies will give you this information. In some of the cases you
describe, two different versions of .NET are surely in use. Document the
exact case and tell us what is happening - or several different cases if you
like. This will be clearer than simply describing how you initiate the
program because the same commands can give different results depending on
how many versions of .NET you have installed.

Charlie

On Wed, May 19, 2010 at 3:00 PM, Martin Jones <email address hidden>wrote:

> Hi Jv, Charlie,
>
> Just throwing in some further details in case this helps to diagnose the
> problem.
>
> I found that initially it was unable to find the test fixture for both
> nunit.exe and nunit-console.exe. Jv - it looks like you had luck from
> the console initially. Did you run from the console first, and then try
> from visual studio? Is something being cached between runs?
>
> If there is some kind of cache, it is possibly flushed on VS exit, or
> when the machine is restarted (/tmp equivalent?). Initially I was having
> problems on Monday night, and then when I tried to reproduce them on
> Tuesday morning I failed. It was then that I noticed the extra
> nunit-agent.exe process and the fact that, although it was now running
> the tests the debugger was not stopping the program.
>
> The information from the blog was used to get the debugger working
> nicely with the nunit executable. The changes only seem to mean that the
> tests are run in the same process, but that means that F5 attaches the
> debugger to the correct process.
>
> Before I made the changes from the blog I can confirm that I saw an
> nunit-agent.exe hanging around in the list of processes after the nunit
> gui had terminated.
>
> Thanks,
>
> Martin
>
> Jv wrote:
> > Hi Charlie,
> >
> > I downloaded NUnit afresh and deleted all NUnit folders and installed
> NUnit
> > and it works again. Now, I am going to try with VS2010 again and see what
> it
> > is that VS does when debugging. I also found that the NUnit Agent
> processes
> > are not closed by VS for each debug execution failure.
> >
> > Jv
> > On Wed, May 19, 2010 at 12:00 PM, RJV <email address hidden> wrote:
> >
> >> Hi Charlie,
> >>
> >> And more to it. I took Martin's link to the blog on how to Debug with
> >> VS2010 and added the startup tag to point to v4 and from then on NUnit
> >> crashes so I remove the startup element from the nunit.exe.config file
> but
> >> still NUnit fails to start! I tried debugging from VS 2010 and it throws
> a
> >> FileNotFoundException for NUnitGUIRunner. It seems that the assembly
> >> reference to the GAC version is no longer valid! It doe...

[Martin Jones (martin-martinjones)]

Hi Charlie,

Yes, I was able to attach the debugger after the nunit-agent was started
but that's hassle compared to previously just being able to hit F5. I
probably run the code through tests every fifteen minutes or so. The
advice given on the blog means that the separate attaching is no longer
necessary, it just works from F5. Shouldn't I just leave the nuint
instance running and let it pick up on the file changes? Probably, but
F5 is so ingrained it's a bit like the escape key if you're familiar
with the vi editor.

For the fundamental problem, apologies that I didn't provide the exact
frameworks in use. However, I have failed to reproduce the problem so I
was just trying to think of other information that could be useful - I
agree it isn't as precise and rich with exact information that would
really help nail the bug, so with that in mind:

I have a solution with two class libraries one of which, Testing,
contains the test code.

The "Start External Program" in the Debug part of the testing project is
set to:
C:\Program Files (x86)\NUnit 2.5.5\bin\net-2.0\nunit.exe

The command line arguments are simply set to:
Testing.dll

I run all of my tests normally just by hitting F5, or control F5.

The following is the output of "Test Assemblies" without the blog
suggested modifications:
nunit.exe ( 3500 )
   CLR Version: 2.0.50727.4200 ( Net 2.0 )

nunit-agent.exe ( 2888 )
   CLR Version: 4.0.30319.1 ( Net 4.0 )

   test-domain-Testing.dll
     ApplicationBase: C:\Users\mj\Desktop\Projects\okapi\Testing\bin\Debug
     Configuration File:
C:\Users\mj\Desktop\Projects\okapi\Testing\bin\Debug\Testing.dll.config
     Testing
       Path:
C:/Users/mj/Desktop/Projects/okapi/Testing/bin/Debug/Testing.DLL
       Image Runtime Version: 4.0.30319
       Uses: nunit.framework, Version=2.5.5.10112, Culture=neutral,
PublicKeyToken=96d09a1eb7f44a77

There is no Testing.dll.config file.

However, even after I took the blog modifications out, I couldn't repeat
the problem. The only problem I have in this situation is that F5
doesn't know to attach the debugger to nunit-agent.exe - not something
to classify as a bug.

Therefore, I am now using the modified nuint.exe.config file (included
inline at the end). This allows me to keep hitting F5 and have it work
as expected. Here's the output of "Test Assemblies" in this case:
nunit.exe ( 3616 )
   CLR Version: 4.0.30319.1 ( Net 4.0 )

   test-domain-Testing.dll
     ApplicationBase: C:\Users\mj\Desktop\Projects\okapi\Testing\bin\Debug
     Configuration File:
C:\Users\mj\Desktop\Projects\okapi\Testing\bin\Debug\Testing.dll.config
     Testing
       Path:
C:/Users/mj/Desktop/Projects/okapi/Testing/bin/Debug/Testing.DLL
       Image Runtime Version: 4.0.30319
       Uses: nunit.framework, Version=2.5.5.10112, Culture=neutral,
PublicKeyToken=96d09a1eb7f44a77

One of the interesting things that I have not been able to reproduce is
nunit.exe insisting on using framework 2 when looking at File|Select
Runtime. When I was having the problem (with original nunit.exe.config),
this would always be set to 2. I tried to change it but the nunit gui
would appear to be reloading, repeat the message about not finding test
fixtures, ...

[Jv (jv-ravichandran)]

Hi Martin,

The cache option was not checked. No, I do not/did not use the console at
all.

NUnit 2.x.x was not supposed to recognize .Net 4.0...the subsequent major
version would do that. So, although it is a bug, it really is not, as I
replied in the blog post.

Jv
On Wed, May 19, 2010 at 6:30 PM, Martin Jones <email address hidden>wrote:

> Hi Jv, Charlie,
>
> Just throwing in some further details in case this helps to diagnose the
> problem.
>
> I found that initially it was unable to find the test fixture for both
> nunit.exe and nunit-console.exe. Jv - it looks like you had luck from
> the console initially. Did you run from the console first, and then try
> from visual studio? Is something being cached between runs?
>
> If there is some kind of cache, it is possibly flushed on VS exit, or
> when the machine is restarted (/tmp equivalent?). Initially I was having
> problems on Monday night, and then when I tried to reproduce them on
> Tuesday morning I failed. It was then that I noticed the extra
> nunit-agent.exe process and the fact that, although it was now running
> the tests the debugger was not stopping the program.
>
> The information from the blog was used to get the debugger working
> nicely with the nunit executable. The changes only seem to mean that the
> tests are run in the same process, but that means that F5 attaches the
> debugger to the correct process.
>
> Before I made the changes from the blog I can confirm that I saw an
> nunit-agent.exe hanging around in the list of processes after the nunit
> gui had terminated.
>
> Thanks,
>
> Martin
>
> Jv wrote:
> > Hi Charlie,
> >
> > I downloaded NUnit afresh and deleted all NUnit folders and installed
> NUnit
> > and it works again. Now, I am going to try with VS2010 again and see what
> it
> > is that VS does when debugging. I also found that the NUnit Agent
> processes
> > are not closed by VS for each debug execution failure.
> >
> > Jv
> > On Wed, May 19, 2010 at 12:00 PM, RJV <email address hidden> wrote:
> >
> >> Hi Charlie,
> >>
> >> And more to it. I took Martin's link to the blog on how to Debug with
> >> VS2010 and added the startup tag to point to v4 and from then on NUnit
> >> crashes so I remove the startup element from the nunit.exe.config file
> but
> >> still NUnit fails to start! I tried debugging from VS 2010 and it throws
> a
> >> FileNotFoundException for NUnitGUIRunner. It seems that the assembly
> >> reference to the GAC version is no longer valid! It does seem that VS
> does
> >> something fishy when using the nunit-agent for debugging:)
> >>
> >> Jv
> >>
> >> On Wed, May 19, 2010 at 11:36 AM, RJV <email address hidden>
> wrote:
> >>
> >>> Hi Charlie,
> >>>
> >>> It does look like a bug...
> >>>
> >>> what happens is, if you run the tests from NUnit separately then it
> works
> >>> but if you specify to VS 2010 to run the tests via the Debug executable
> >>> option then this causes the System.ApplicationException that "unable to
> find
> >>> tests in assembly".
> >>>
> >>> After this even if you run NUnit separately and create a nw .nunit
> project
> >>> and attempt to add the assembly, NUnit gives the above exception.
> >>>
> >>> Seems ...

[Martin Jones (martin-martinjones)]

Hi Jv,

I didn't realize that 2.x.x. wasn't supposed to be able to work with
4.0, but that seems a sensible decision. And I agree that would mean
that this isn't really a bug, especially seeing as it has essentially
evaporated on my machine, and it has disappeared on yours.

I'm happy that I can use it with the modification to the
nunit.exe.config file, and so far without any further hiccups.

Thankyou, and thankyou Charlie, for your time on this.

Martin

Jv wrote:
> Hi Martin,
>
> The cache option was not checked. No, I do not/did not use the console at
> all.
>
> NUnit 2.x.x was not supposed to recognize .Net 4.0...the subsequent major
> version would do that. So, although it is a bug, it really is not, as I
> replied in the blog post.
>
> Jv
> On Wed, May 19, 2010 at 6:30 PM, Martin Jones <email address hidden>wrote:
>
>> Hi Jv, Charlie,
>>
>> Just throwing in some further details in case this helps to diagnose the
>> problem.
>>
>> I found that initially it was unable to find the test fixture for both
>> nunit.exe and nunit-console.exe. Jv - it looks like you had luck from
>> the console initially. Did you run from the console first, and then try
>> from visual studio? Is something being cached between runs?
>>
>> If there is some kind of cache, it is possibly flushed on VS exit, or
>> when the machine is restarted (/tmp equivalent?). Initially I was having
>> problems on Monday night, and then when I tried to reproduce them on
>> Tuesday morning I failed. It was then that I noticed the extra
>> nunit-agent.exe process and the fact that, although it was now running
>> the tests the debugger was not stopping the program.
>>
>> The information from the blog was used to get the debugger working
>> nicely with the nunit executable. The changes only seem to mean that the
>> tests are run in the same process, but that means that F5 attaches the
>> debugger to the correct process.
>>
>> Before I made the changes from the blog I can confirm that I saw an
>> nunit-agent.exe hanging around in the list of processes after the nunit
>> gui had terminated.
>>
>> Thanks,
>>
>> Martin
>>
>> Jv wrote:
>>> Hi Charlie,
>>>
>>> I downloaded NUnit afresh and deleted all NUnit folders and installed
>> NUnit
>>> and it works again. Now, I am going to try with VS2010 again and see what
>> it
>>> is that VS does when debugging. I also found that the NUnit Agent
>> processes
>>> are not closed by VS for each debug execution failure.
>>>
>>> Jv
>>> On Wed, May 19, 2010 at 12:00 PM, RJV <email address hidden> wrote:
>>>
>>>> Hi Charlie,
>>>>
>>>> And more to it. I took Martin's link to the blog on how to Debug with
>>>> VS2010 and added the startup tag to point to v4 and from then on NUnit
>>>> crashes so I remove the startup element from the nunit.exe.config file
>> but
>>>> still NUnit fails to start! I tried debugging from VS 2010 and it throws
>> a
>>>> FileNotFoundException for NUnitGUIRunner. It seems that the assembly
>>>> reference to the GAC version is no longer valid! It does seem that VS
>> does
>>>> something fishy when using the nunit-agent for debugging:)
>>>>
>>>> Jv
>>>>
>>>> On Wed, May 19, 2010 at 11:36 AM, RJV <jv.ravichandran@gm...

[Volkmar Nissen (v-nissen)]

Hi,

I faced the same issue.

When I changed nunit-console.exe.config and added <startup> <supportedRuntime version="4.0.30319" /></startup>
and
   <loadFromRemoteSources enabled="true" />
 as described above, the console version of NUnit worked properly when I added the /framwork=4.0.30319 option to the command line.
A second start of the nunit console without /framework option was also successful.

Starting the test using the GUI tool was never successful even after applying the neccessary changes in nunit.exe.config (The GUI version has no /framework option)

what can I do to either further analyze the problem or to find some other solution?

Volkmar

[Charlie Poole (charlie.poole)]

Hi Volkmar,

I guess we should document using the config as a workaround. The
reason it's only a
workaround and not a solution is that NUnit is intended to work while
running under
one framework and testing using another one.

The fact that the console worked properly using the /framework
argument would seem
to indicate that NUnit is not correctly detecting that the test
assembly is built for
.NET 4.0. This is surprising, since the detection is working in other cases.

It will help to know exactly which .NET framework versions are installed on
any systems where this problem is seen. NUnit detects all installed .NET
frameworks and acts (should act) accordingly.

Note that there is a bug in the case of Mono 4.0, which is not known to
NUnit as of this version.

Charlie

On Mon, Jul 5, 2010 at 1:58 AM, Volkmar Nissen <email address hidden> wrote:
> Hi,
>
> I faced the same issue.
>
> When I changed nunit-console.exe.config and added <startup>  <supportedRuntime version="4.0.30319" /></startup>
> and
>   <loadFromRemoteSources enabled="true" />
>  as  described above, the console version of NUnit worked properly when I added the /framwork=4.0.30319 option to the command line.
> A second start of the nunit console without /framework option was also successful.
>
> Starting the test using the GUI tool was never successful even after
> applying the neccessary changes in nunit.exe.config (The GUI version has
> no /framework option)
>
> what can I do to either further analyze the problem or to find some
> other solution?
>
> Volkmar
>
> --
> 2.5.5 cannot find fixture for framework 4.0
> https://bugs.launchpad.net/bugs/582051
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
>

[Carlos Serrano (casmrv)]

Hi
I am having the same problem with VS 2010, .NET 4.0, NUnit 2.5.5.10112 on a 64 bit system.

I am dealing with 3 projects, one of them being a trivial 1 TestFixture class with 1 Test method and 1 Setup method and nothing else.

Initially, using a fairly large project that was originally developed on VS2008 with .NET 3.5 and moved to VS2010 with .NET 4.0, I got a number of cases in which, from time to time, launching nunit-console from VS would not execute any test - it would just report 0 test executed. Relaunching it would cause it to actually execute the tests. I spent a fair amount of time trying to figure out what would cause it, but it was transient and I could not find anything more precise.

I exited VS 2010, loaded another project - and tried to run nunit. The project had the same type of setting in terms of framework, etc..., and the same level of complexity (a few hundred test fixture classes, a total of a couple of thousand tests). Initially, I got the same issue (no error reported, but 0 test reported executed) - after the first try, the second one did execute the tests, and that was the case until I rebuilt.
From that point on, I systematically got "unable to locate fixture".

I ended up exiting VS 2010 again, building the simple project described above, and now I systematically get "unable to locate fixture".

Using the GUI tool properly configured to handle .net 4.0, I get a message telling me that it could not find any test. And that is systematic now.

I started on a second 64 bit system, using the small project again, and managed to go through the same cycle: not working, working, not working anymore.

This is very puzzling but not inconsistent with what was described earlier.

Nunit is a very good tool I have been using for a while and I rely on immensily (thanks for all the work).
I hope the source of this can be identified, and a work-around provided.

Thanks!

[Carlos Serrano (casmrv)]

Sorry, forgot to be specific (since Charles asked the question) - the version of .NET is 4.0.30319.
I think the version is quoted earlier in trail too.
Thanks!

[Charlie Poole (charlie.poole)]

I just re-read the thread, including some items I missed...

It is NOT correct that NUnit 2.5.5 is "not supposed to work" with .NET 4.0. Indeed,
it does work , at least - as the saying goes - on my machine.

Workarounds are well and good, but it would be great to continue to try to identify
what isn't working as it should and fix it!

Here's a question for all who reported the bug. Is this only present on 64-bit
machines? If you have a bug running on a 32-bit OS, is it the same stack trace?

Charlie

[Martin Jones (martin-martinjones)]

Charlie,

I have failed to reproduce the original error on my 64 bit machine, and
it didn't happen on the 32 bit machine at all. That of course doesn't
mean that the 32 bit machine doesn't suffer the problem, just that I
haven't seen it.

One thing to consider with the information in this post is that the
original fault occured on 64 bit vista. I am now on 64 bit Win 7, and no
longer have the old machine available.

I found that I had to restart the 64 bit machine before I could edit the
app config file. Something had it locked, but all applications had been
closed and there was no agent running in the task manager. I was going
to get the sysinternals tools to find out which process, but once again,
the problem has snuck away. So, I haven't been able to determine which
process had it locked. I don't know if this will ever be relevant though.

I needed to edit the config file to put it back into the non-workaround
situation. However, after doing this, nunit worked fine and showed the
v2 stuff in the gui, and the v4 stuff in the agent.

I have played around with my firewall settings to see if that could
possibly affect it. I was trying to think of something that would happen
first time you ran it, and then didn't affect it later. However, getting
the firewall to block both processes, or prompt for what to do for both
processes didn't generate the error.

So, sorry, but I can't answer the question :-(

On the 2.5.5 and v4 bit: I probably misinterpreted Jv's comment on NUnit
2.x.x. not recognizing .net 4. Yes, it does work on my machines.

Thanks,

Martin

Charlie Poole wrote:
> I just re-read the thread, including some items I missed...
>
> It is NOT correct that NUnit 2.5.5 is "not supposed to work" with .NET 4.0. Indeed,
> it does work , at least - as the saying goes - on my machine.
>
> Workarounds are well and good, but it would be great to continue to try to identify
> what isn't working as it should and fix it!
>
> Here's a question for all who reported the bug. Is this only present on 64-bit
> machines? If you have a bug running on a 32-bit OS, is it the same stack trace?
>
> Charlie
>

[Charlie Poole (charlie.poole)]

Since there are several related fixes in the code already, I'm going to put out 2.5.6 without any further changes on this bug. Then we'll see what's left to fix.

[Charlie Poole (charlie.poole)]

Created feature request #582051 to deal with the issue of having to continually re-attach the nunit-agent process

[Chris Shaw (cshaw-alionscience)]

I have a few comments to add (apologies if I missed anyone else mentioning these above...)

To quote Carlos S, "I am having the same problem with VS 2010, .NET 4.0, NUnit 2.5.5.10112 on a 64 bit system."

My testing project worked fine under .NET 3.5, with NUnit 2.5, even on this 64-bit machine.

After upgrading (.NET 4.0, NUnit 2.5.5), all seemed to be well at first, and then NUnit could not find any tests. The GUI seems permanently set for .NET 2.0, even when I try to change it. 'nunit-console.exe' works correctly for me when I use the /framework flag, though it did *not* work without the flag, even on a 32-bit machine.

After reading through this bug (after trying various times to run my tests), I checked my Task Manager, and found two entries each of 'nunit-agent.exe' and nunit-agent-x86.exe' (I had closed NUnit itself earlier). Once I killed all four of those processes, the NUnit GUI found my tests again.

I hope this is some help to you -- you've made a great tool that I depend on implicitly.

Thanks,
--Chris Shaw

[Charlie Poole (charlie.poole)]

Hi Chris,

Thanks - this is helpful. Any chance you could try it with 2.5.7 as well?

Charlie

On Mon, Aug 2, 2010 at 3:35 PM, Chris Shaw <email address hidden> wrote:
> I have a few comments to add (apologies if I missed anyone else
> mentioning these above...)
>
> To quote Carlos S, "I am having the same problem with VS 2010, .NET 4.0,
> NUnit 2.5.5.10112 on a 64 bit system."
>
> My testing project worked fine under .NET 3.5, with NUnit 2.5, even on
> this 64-bit machine.
>
> After upgrading (.NET 4.0, NUnit 2.5.5), all seemed to be well at first,
> and then NUnit could not find any tests.  The GUI seems permanently set
> for .NET 2.0, even when I try to change it.  'nunit-console.exe' works
> correctly for me when I use the /framework flag, though it did *not*
> work without the flag, even on a 32-bit machine.
>
> After reading through this bug (after trying various times to run my
> tests), I checked my Task Manager, and found two entries each of 'nunit-
> agent.exe' and nunit-agent-x86.exe' (I had closed NUnit itself earlier).
> Once I killed all four of those processes, the NUnit GUI found my tests
> again.
>
> I hope this is some help to you -- you've made a great tool that I
> depend on implicitly.
>
> Thanks,
> --Chris Shaw
>
> --
> 2.5.5 cannot find fixture for framework 4.0
> https://bugs.launchpad.net/bugs/582051
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
>

[Chris Shaw (cshaw-alionscience)]

Hi Charlie,

OK, after installing 2.5.7, I notice:

NUnit hasn't (in about 1/2 a dozen tries) been unable to find my tests -- they all seemed to run correctly.

After the first run, however, 'nunit-agent-x86.exe' was left in my Process list. After that, each subsequent run seemed to start (and later kill) a new instance, while leaving the first instance running.

Once, I tried Stopping the tests (from the GUI) before they completed. That time, another instance of 'nunit-agent-86.exe' was left behind. The next run still seemed to run OK, however (starting and then killing a new (third) process).

Now, I have no NUnit running, but two 'nunit-agent-86.exe' processes still running, according to the Task Manager.

I've never seen an instance of 'nunit-agent.exe' while doing any of this.

Hope this helps,
--Chris

(BTW, I used to be able to put breakpoints into my tests (and into my code base) that would get hit when NUnit ran the tests. Now, they don't get hit, and VS says that 'No symbols have been loaded..' when NUnit is running. Is that an intended change? --cs)

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Charlie Poole
Sent: Monday, August 02, 2010 4:56 PM
To: Shaw, Christopher
Subject: Re: [Bug 582051] Re: 2.5.5 cannot find fixture for framework 4.0

Hi Chris,

Thanks - this is helpful. Any chance you could try it with 2.5.7 as
well?

Charlie

On Mon, Aug 2, 2010 at 3:35 PM, Chris Shaw <email address hidden> wrote:
> I have a few comments to add (apologies if I missed anyone else
> mentioning these above...)
>
> To quote Carlos S, "I am having the same problem with VS 2010, .NET 4.0,
> NUnit 2.5.5.10112 on a 64 bit system."
>
> My testing project worked fine under .NET 3.5, with NUnit 2.5, even on
> this 64-bit machine.
>
> After upgrading (.NET 4.0, NUnit 2.5.5), all seemed to be well at first,
> and then NUnit could not find any tests.  The GUI seems permanently set
> for .NET 2.0, even when I try to change it.  'nunit-console.exe' works
> correctly for me when I use the /framework flag, though it did *not*
> work without the flag, even on a 32-bit machine.
>
> After reading through this bug (after trying various times to run my
> tests), I checked my Task Manager, and found two entries each of 'nunit-
> agent.exe' and nunit-agent-x86.exe' (I had closed NUnit itself earlier).
> Once I killed all four of those processes, the NUnit GUI found my tests
> again.
>
> I hope this is some help to you -- you've made a great tool that I
> depend on implicitly.
>
> Thanks,
> --Chris Shaw
>
> --
> 2.5.5 cannot find fixture for framework 4.0
> https://bugs.launchpad.net/bugs/582051
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
>

--
2.5.5 cannot find fixture for framework 4.0
https://bugs.launchpad.net/bugs/582051
You received this bug notification because you are a direct subscriber
of the bug.

Status in NUnit V2 Test Framework: In Progress

Bug description:
Just downloaded v2.5.5.10112 of Nunit. In a new VS2010 project I am unable to ge...

[Charlie Poole (charlie.poole)]

Hi Chris,

Are these your tests or the NUnit tests? I ask because the NUnit tests do
run extra copies of nunit-agent.

When running your own tests, there should be a copy of nunit-agent which
is created each time you load or reload the tests. It doesn't go away at
the end of the run, howver.

To debug in this situation, you have to attach to nunit-agent, which is a
limitation of our use of a separate process.

From what you are saying, I'm seeing this bug pretty well fixed, but
I'll wait to see if there are comments from anybody else.

Charlie

On Mon, Aug 2, 2010 at 4:41 PM, Chris Shaw <email address hidden> wrote:
> Hi Charlie,
>
> OK, after installing 2.5.7, I notice:
>
> NUnit hasn't (in about 1/2 a dozen tries) been unable to find my tests
> -- they all seemed to run correctly.
>
> After the first run, however, 'nunit-agent-x86.exe' was left in my
> Process list.  After that, each subsequent run seemed to start (and
> later kill) a new instance, while leaving the first instance running.
>
> Once, I tried Stopping the tests (from the GUI) before they completed.
> That time, another instance of 'nunit-agent-86.exe' was left behind.
> The next run still seemed to run OK, however (starting and then killing
> a new (third) process).
>
> Now, I have no NUnit running, but two 'nunit-agent-86.exe' processes
> still running, according to the Task Manager.
>
> I've never seen an instance of 'nunit-agent.exe' while doing any of
> this.
>
> Hope this helps,
> --Chris
>
> (BTW, I used to be able to put breakpoints into my tests (and into my
> code base) that would get hit when NUnit ran the tests.  Now, they don't
> get hit, and VS says that 'No symbols have been loaded..' when NUnit is
> running.  Is that an intended change?  --cs)
>
>
> -----Original Message-----
> From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Charlie Poole
> Sent: Monday, August 02, 2010 4:56 PM
> To: Shaw, Christopher
> Subject: Re: [Bug 582051] Re: 2.5.5 cannot find fixture for framework 4.0
>
> Hi Chris,
>
> Thanks - this is helpful. Any chance you could try it with 2.5.7 as
> well?
>
> Charlie
>
> On Mon, Aug 2, 2010 at 3:35 PM, Chris Shaw <email address hidden> wrote:
>> I have a few comments to add (apologies if I missed anyone else
>> mentioning these above...)
>>
>> To quote Carlos S, "I am having the same problem with VS 2010, .NET 4.0,
>> NUnit 2.5.5.10112 on a 64 bit system."
>>
>> My testing project worked fine under .NET 3.5, with NUnit 2.5, even on
>> this 64-bit machine.
>>
>> After upgrading (.NET 4.0, NUnit 2.5.5), all seemed to be well at first,
>> and then NUnit could not find any tests.  The GUI seems permanently set
>> for .NET 2.0, even when I try to change it.  'nunit-console.exe' works
>> correctly for me when I use the /framework flag, though it did *not*
>> work without the flag, even on a 32-bit machine.
>>
>> After reading through this bug (after trying various times to run my
>> tests), I checked my Task Manager, and found two entries each of 'nunit-
>> agent.exe' and nunit-agent-x86.exe' (I had closed NUnit itself earlier).
>> Once I killed all four of those processes, the NUnit GUI found my tests
>> again.
>>
>> I ...

[Charlie Poole (charlie.poole)]

Based on lack of further comments, I marked this as fixed in an earlier release.

[Rami Abughazaleh (rami-abughazaleh)]

I am experiencing this issue with NUnit v2.5.9.10348.

Windows Server 2008 R2 Enterprise (64-bit)

C:\nunit\net-2.0\nunit-console-x86.exe c:\unittests\MyTest\MyTest.nunit /config=my-config-test /framework=4.0 /run=MyTest.Tests.Test /noshadow /xml:c:\unittests\MyTest.xml
NUnit version 2.5.9.10348
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.4927 ( Net 2.0 )

ProcessModel: Default DomainUsage: Default
Execution Runtime: v4.0
Unable to locate fixture

However, if I immediately run it again, it works as expected.

I have this consistently reproducible from a vmware snapshot.

The vmware snapshot has the following components installed\settings configured in order:
.net 3.5.1
sql server 2008 r2 express with management studio
.net 4.0 full
logged in as a domain user
iis
disabled uac
enabled interactive service detection service

But I'm not sure if all of them are relevant.

Is there anything else I can do to produce a more verbose output\log for diagnostics?

Should I create a new bug or should this one be re-opened?

Thank you.

[Jv (jv-ravichandran)]

http://kinkelder-duiven.nl/AWStats/news.html?w3v5j0