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 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 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 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 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.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>> --
> >>>>> 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 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
> >>>
> >>
> >>
> >> --
> >> Regards,
> >>
> >> Ravichandran Jv
> >> http://ravichandranjv.blogspot.com
> >>
> >
> >
>
> --
> 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.
>