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, and then still be set on framework 2 under File|Select
Runtime. This problem doesn't occur for me anymore, even after reverting
nunit.exe.config to its original state.

Martin

Here is the modified nunit.exe.config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
	<startup>
		<requiredRuntime version="4.0.30319"/>
	</startup>
   <!--
      Application settings for NUnit-gui.exe. Do NOT put settings
	 for use by your tests here.
	-->
   <appSettings>
     <!--
      Uncomment to specify the url to be used for help. If not used, the
      default value is something like
		file://localhost/C:/Program Files/NUnit 2.2/doc/index.html
	 This setting is provided in case your default browser doesn't
	 support this format.
	-->
     <!-- <add key="helpUrl" value="http://www.nunit.org" /> -->
   </appSettings>

   <!-- Set the level for tracing NUnit itself -->
   <!-- 0=Off 1=Error 2=Warning 3=Info 4=Debug -->
   <system.diagnostics>
	  <switches>
       <add name="NTrace" value="0" />
	  </switches>
	</system.diagnostics>

   <runtime>
   	<loadFromRemoteSources enabled="true"/>
     <!-- We need this so test exceptions don't crash NUnit -->
     <legacyUnhandledExceptionPolicy enabled="1" />

     <!-- Look for addins in the addins directory for now -->
     <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
       <probing privatePath="lib;addins" />
     </assemblyBinding>

     <!--
     The following <assemblyBinding> section allows running nunit under
     .NET 1.0 by redirecting assemblies. The appliesTo attribute
     causes the section to be ignored except under .NET 1.0
     on a machine with only the .NET version 1.0 runtime installed.
     If application and its tests were built for .NET 1.1 you will
     also need to redirect system assemblies in the test config file,
     which controls loading of the tests.
    -->
     <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"
        appliesTo="v1.0.3705">

       <dependentAssembly>
         <assemblyIdentity name="System"
                           publicKeyToken="b77a5c561934e089"
                           culture="neutral"/>
         <bindingRedirect  oldVersion="1.0.5000.0"
                           newVersion="1.0.3300.0"/>
       </dependentAssembly>

       <dependentAssembly>
         <assemblyIdentity name="System.Data"
                           publicKeyToken="b77a5c561934e089"
                           culture="neutral"/>
         <bindingRedirect  oldVersion="1.0.5000.0"
                           newVersion="1.0.3300.0"/>
       </dependentAssembly>

       <dependentAssembly>
         <assemblyIdentity name="System.Drawing"
                           publicKeyToken="b03f5f7f11d50a3a"
                           culture="neutral"/>
         <bindingRedirect  oldVersion="1.0.5000.0"
                           newVersion="1.0.3300.0"/>
       </dependentAssembly>

       <dependentAssembly>
         <assemblyIdentity name="System.Windows.Forms"
                           publicKeyToken="b77a5c561934e089"
                           culture="neutral"/>
         <bindingRedirect  oldVersion="1.0.5000.0"
                           newVersion="1.0.3300.0"/>
       </dependentAssembly>

       <dependentAssembly>
         <assemblyIdentity name="System.Xml"
                           publicKeyToken="b77a5c561934e089"
                           culture="neutral"/>
         <bindingRedirect  oldVersion="1.0.5000.0"
                           newVersion="1.0.3300.0"/>
       </dependentAssembly>

     </assemblyBinding>

   </runtime>

</configuration>

Charlie Poole wrote:
> 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.
>>
>