Bug #561487 “NullReferenceException ProcessRunner.Load loading t...” : Bugs : NUnit V2

ruddy (douglass) on 2010-04-12

description:	updated
description:	updated

Revision history for this message

Charlie Poole (charlie.poole) wrote on 2010-04-12:

#1

Unless this is replicated in a 32-bit environment, it points out a problem with our testing and release process: nobody involved has a 64 bit system to test with ... more on that on the mailing list.

The specific error is interesting. The first stack trace shows ProcessRunner in both
the original error and the rethrown error. This indicates that

1) NUnit is using a separate process to run the tests.

2) That separate process seems to think that _it_ needs to kick off a separate
process, which is what is causing the error.

So, we need to know two things:

1) Why is a separate process needed in the first place?

2) Why does the second process seem to want a third one?

Item #2 is the bug.

Info that will help me...

1) Under what runtime are you running NUnit initially?
See the help | about dialog for the runtine.

2) For what runtime was your test assembly compiled?

3) Is NUnit (or nunit-console) launching nunit-agent.exe or
nunit-agent-x86.exe? (See Task manager)

4) Can this be replicated with a simple C# program or does
it only happen with C++/CLI.

Thanks for your report.

Charlie

Revision history for this message

ruddy (douglass) wrote on 2010-04-12:

#2

#1 2.0.50727.4927 (Net 2.0)

#2 v4.0.30128

#3 As far as i can tell no additional processes are being launched - unless they are starting/stopping inside the refresh window of Task Manager.

#4 I have replicated it using a simple c# test dll - stack trace looks identical to me

System.NullReferenceException...

Server stack trace:
   at NUnit.Util.ProcessRunner.Load(TestPackage package)
   at NUnit.Core.ProxyTestRunner.Load(TestPackage package)
   at NUnit.Util.RemoteTestAgent.AgentRunner.Load(TestPackage package)
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at NUnit.Core.TestRunner.Load(TestPackage package)
   at NUnit.Core.ProxyTestRunner.Load(TestPackage package)
   at NUnit.Util.ProcessRunner.Load(TestPackage package)
   at NUnit.Util.TestLoader.LoadTest(String testName)

Revision history for this message

Charlie Poole (charlie.poole) wrote on 2010-04-12:

#3

Hi,

Thanks for the info...

> #1 2.0.50727.4927 (Net 2.0)
>
> #2 v4.0.30128

These two values indicate that a process should be launched. NUnit should detect that the assembly was built
using 4.0.30128 and decide to launch a process.

> #3 As far as i can tell no additional processes are being launched - unless they are starting/stopping inside the refresh window of Task Manager.

It may be faiing too quickly to show up, but the stack trace seems to indicate it is launched.

> #4 I have replicated it using a simple c# test dll - stack trace looks identical to me

System.NullReferenceException...

Server stack trace:
   at NUnit.Util.ProcessRunner.Load(TestPackage package)
   at NUnit.Core.ProxyTestRunner.Load(TestPackage package)
   at NUnit.Util.RemoteTestAgent.AgentRunner.Load(TestPackage package)
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at NUnit.Core.TestRunner.Load(TestPackage package)
   at NUnit.Core.ProxyTestRunner.Load(TestPackage package)
   at NUnit.Util.ProcessRunner.Load(TestPackage package)
   at NUnit.Util.TestLoader.LoadTest(String testName)

The top section (Server Stack trace) is from the nunit-agent executable. The presense of
RemoteTestAgent gives it away.

The bottom section is from the nunit executable. Notice also how "ProcessTestRunner" appears in both of them. That's the runner NUnit uses when it needs to launch a process. So it looks like nunit is not creating the server process in a way that allows it to run the test. The runner in that process decides it needs another process, which should not happen.

I can try this on a 32 bit system to see if it replicates, but it's likely to behave differently. Here's an idea... rename the binaries nunit-agent.exe and nunit-agent-x86.exe to something else and watch it crash in a different way. Then rename them back to their original names one at a time so we can deduce which one is running. nunit-x86 should always launch nunit-agent-x86 and if it failed to do so it would cause a problem.

Charlie

Hi,

Thanks for the info...

> #1 2.0.50727.4927 (Net 2.0)
> 
> #2 v4.0.30128

These two values indicate that a process should be launched. NUnit should detect that the assembly was built
using 4.0.30128 and decide to launch a process.

> #3 As far as i can tell no additional processes are being launched - unless they are starting/stopping inside the refresh window of Task Manager.

It may be faiing too quickly to show up, but the stack trace seems to indicate it is launched.

> #4 I have replicated it using a simple c# test dll - stack trace looks identical to me

System.NullReferenceException...

Server stack trace:
   at NUnit.Util.ProcessRunner.Load(TestPackage package)
   at NUnit.Core.ProxyTestRunner.Load(TestPackage package)
   at NUnit.Util.RemoteTestAgent.AgentRunner.Load(TestPackage package)
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at NUnit.Core.TestRunner.Load(TestPackage package)
   at NUnit.Core.ProxyTestRunner.Load(TestPackage package)
   at NUnit.Util.ProcessRunner.Load(TestPackage package)
   at NUnit.Util.TestLoader.LoadTest(String testName)

The top section (Server Stack trace) is from the nunit-agent executable. The presense of 
RemoteTestAgent gives it away.

The bottom section is from the nunit executable. Notice also how "ProcessTestRunner" appears in both of them. That's the runner NUnit uses when it needs to launch a process. So it looks like nunit is not creating the server process in a way that allows it to run the test. The runner in that process decides it needs another process, which should not happen.

I can try this on a 32 bit system to see if it replicates, but it's likely to behave differently. Here's an idea... rename the binaries nunit-agent.exe and nunit-agent-x86.exe to something else and watch it crash in a different way. Then rename them back to their original names one at a time so we can deduce which one is running. nunit-x86 should always launch nunit-agent-x86 and if it failed to do so it would cause a problem.

Charlie

Revision history for this message

Charlie Poole (charlie.poole) wrote on 2010-04-13:

#4

I verified that this cannot be replicated in a 32-bit environment, so I'll ask you to do a bit more...

Edit nunit-x86.exe.config to set the internal trace level to 5. Do the same for nunit-agent-x86.exe.config.

Try to run and after the failure to load exit.

You should find several trace files in your <ApplicationData>/NUnit/logs directory. Attach them to this bug.

Charlie

Changed in nunitv2:
status:	New → Triaged
importance:	Undecided → High

Revision history for this message

ruddy (douglass) wrote on 2010-04-13:

#5

Here's the information from the first set of addtional info (Renaming the processes)

With both nunit-x86.exe & nunit-agent-x86.exe renamed

System.ArgumentException...
   at NUnit.Util.TestAgency.LaunchAgentProcess(RuntimeFramework targetRuntime, Boolean enableDebug)
   at NUnit.Util.TestAgency.CreateRemoteAgent(RuntimeFramework framework, Int32 waitTime, Boolean enableDebug)
   at NUnit.Util.TestAgency.GetAgent(RuntimeFramework framework, Int32 waitTime, Boolean enableDebug)
   at NUnit.Util.ProcessRunner.Load(TestPackage package)
   at NUnit.Util.TestLoader.LoadTest(String testName)

with just nunit-x86.exe renamed

System.NullReferenceException...

Server stack trace:
   at NUnit.Util.ProcessRunner.Load(TestPackage package)
   at NUnit.Core.ProxyTestRunner.Load(TestPackage package)
   at NUnit.Util.RemoteTestAgent.AgentRunner.Load(TestPackage package)
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at NUnit.Core.TestRunner.Load(TestPackage package)
   at NUnit.Core.ProxyTestRunner.Load(TestPackage package)
   at NUnit.Util.ProcessRunner.Load(TestPackage package)
   at NUnit.Util.TestLoader.LoadTest(String testName)

Revision history for this message

ruddy (douglass) wrote on 2010-04-13:

#6

Requested Logs Edit (2.1 KiB, application/zip)

I have also attached the log files as requested.

A couple things i noticed during my gathering of this information - probably just some incoherent ramblings - but i'll throw them out there.

1. If you don't properly rename the .config to match the .exe for nunit/agent both will crash on startup

2. If you manually run nunit-agent it will launch and stay running and then (apparently) cause any additional ones spawned (by say nunit) to apparently hang (could see them in the sysinternal process explorer as a child of nunit) and a few seconds after trying to load the test dll nunit complains that no test was found in the dll -- took me a while to figure out why the problem had apparently morphed.

3. I downloaded the code for 2.5.4 and built it with VS2010RC - but i don't see any configurations that make the "x86" versions - so i didn't go any further - i had originally (Last week) downloaded 2.5.3, converted the 2008 solutions to VS2010RC, manually changed all the projects to build against .NET 4.0 & target the x86 and that would successfully load and execute the tests (For what little that is worth) but when i saw 2.5.4 was available i thought i'd try that instead since it should load and handle the .NET 4.0 tests

Revision history for this message

Charlie Poole (charlie.poole) wrote on 2010-04-13: Re: [Bug 561487] Re: NullReferenceException ProcessRunner.Load loading test

#7

The log files nailed it. In the nunit log, you can see NUnit properly deciding
to use .NET 4.0. In the agent log, on line 3, you can see that agent is
running under .NET 2.0!

After all the talk about 64-bitness and other complexities, the answer is
actually very simple. NUnit never heard of .NET 4.0.30128 because I
never told it about it!

If you use the source, you can make a quick fix to TestAgency.cs.
Search for '4.0.21006' and add two lines just like what's there for
Beta 1 and Beta 2. I'll be fixing it in a more general way, but just
adding your own version number should work as well.

Regarding the other points:

1. The distribution provides properly named configs, so you shouldn't
have to rename them. But see #3 as well.

2. NUnit-agent is not intended to be run manually. Do you think we need
a warning somewhere?

3. The VS builds are for convenience. You can't really build a distribution
copy of NUnit except with the NAnt build. That's because the distribution
includes builds for different frameworks. It also does some of the config
renaming you were talking about. It's possible that we will make the IDE
build the primary build at some time in the future, after we drop support
for .NET 1.0 and 1.1.

Charlie

On Tue, Apr 13, 2010 at 8:40 AM, ruddy <email address hidden> wrote:
> I have also attached the log files as requested.
>
> A couple things i noticed during my gathering of this information -
> probably just some incoherent ramblings - but i'll throw them out there.
>
> 1. If you don't properly rename the .config to match the .exe for
> nunit/agent both will crash on startup
>
> 2. If you manually run nunit-agent it will launch and stay running and
> then (apparently) cause any additional ones spawned (by say nunit) to
> apparently hang (could see them in the sysinternal process explorer as a
> child of nunit) and a few seconds after trying to load the test dll
> nunit complains that no test was found in the dll -- took me a while to
> figure out why the problem had apparently morphed.
>
> 3. I downloaded the code for 2.5.4 and built it with VS2010RC - but i
> don't see any configurations that make the "x86" versions - so i didn't
> go any further - i had originally (Last week) downloaded 2.5.3,
> converted the 2008 solutions to VS2010RC, manually changed all the
> projects to build against .NET 4.0 & target the x86 and that would
> successfully load and execute the tests (For what little that is worth)
> but when i saw 2.5.4 was available i thought i'd try that instead since
> it should load and handle the .NET 4.0 tests
>
>
>
> ** Attachment added: "Requested Logs"
> http://launchpadlibrarian.net/44046074/nunit-gui_2824.zip
>
> --
> NullReferenceException ProcessRunner.Load loading test
> https://bugs.launchpad.net/bugs/561487
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
>

The log files nailed it. In the nunit log, you can see NUnit properly deciding
to use .NET 4.0. In the agent log, on line 3, you can see that agent is
running under .NET 2.0!

After all the talk about 64-bitness and other complexities, the answer is
actually very simple. NUnit never heard of .NET 4.0.30128 because I
never told it about it!

If you use the source, you can make a quick fix to TestAgency.cs.
Search for '4.0.21006' and add two lines just like what's there for
Beta 1 and Beta 2. I'll be fixing it in a more general way, but just
adding your own version number should work as well.

Regarding the other points:

1. The distribution provides properly named configs, so you shouldn't
have to rename them. But see #3 as well.

2. NUnit-agent is not intended to be run manually. Do you think we need
a warning somewhere?

3. The VS builds are for convenience. You can't really build a distribution
copy of NUnit except with the NAnt build. That's because the distribution
includes builds for different frameworks. It also does some of the config
renaming you were talking about. It's possible that we will make the IDE
build the primary build at some time in the future, after we drop support
for .NET 1.0 and 1.1.

Charlie

On Tue, Apr 13, 2010 at 8:40 AM, ruddy <douglass@omtool.com> wrote:
> I have also attached the log files as requested.
>
> A couple things i noticed during my gathering of this information -
> probably just some incoherent ramblings - but i'll throw them out there.
>
> 1. If you don't properly rename the .config to match the .exe for
> nunit/agent both will crash on startup
>
> 2. If you manually run nunit-agent it will launch and stay running and
> then (apparently) cause any additional ones spawned (by say nunit) to
> apparently hang (could see them in the sysinternal process explorer as a
> child of nunit) and a few seconds after trying to load the test dll
> nunit complains that no test was found in the dll -- took me a while to
> figure out why the problem had apparently morphed.
>
> 3. I downloaded the code for 2.5.4 and built it with VS2010RC - but i
> don't see any configurations that make the "x86" versions - so i didn't
> go any further - i had originally (Last week) downloaded 2.5.3,
> converted the 2008 solutions to VS2010RC, manually changed all the
> projects to build against .NET 4.0 & target the x86 and that would
> successfully load and execute the tests (For what little that is worth)
> but when i saw 2.5.4 was available i thought i'd try that instead since
> it should load and handle the .NET 4.0 tests
>
>
>
> ** Attachment added: "Requested Logs"
>   http://launchpadlibrarian.net/44046074/nunit-gui_2824.zip
>
> --
> NullReferenceException ProcessRunner.Load loading test
> https://bugs.launchpad.net/bugs/561487
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
>

Revision history for this message

ruddy (douglass) wrote on 2010-04-14:

#8

I can change the source code (and did), but in order to load the dll it has to be compiled for x86 - and of course its not readily doing that as we've discussed - so when i forced nunit to build as x86: NUnitConfiguration::GetTestAgentExePath is trying to load nunit-agent-x86.exe which of course didn't get built...

As to my previous ramblings
#1 was only a problem because i tried renaming the .exe as you suggested for a test, but in order for the renamed nunit to actually run after renaming i had to rename the config which sort of lead to the #2 issue {strictly speaking i didn't have to rename the nunit-agent config file since it was not intended to run in the test anyway} and of course i wouldn't have normally run the agent manually but i was just verifying it was no longer crashing at startup because of mismatched configuration file. Some type of warning might be nice, but hardly a major priority.

#3 - is only somewhat problematic since i'd like to build the x86 version of the code to fix this {since a build targeting 'any cpu' will load as 64bit code on a 64bit machine but then gives a "bad image" error on trying to load a 32 bit C++/clI test dll which is where i started down this path to begin with...} of course, manually updating the projects, while not hard, is something that will get lost with each new code drop.

FWIW: This is not a critical issue for me personally at this point as i can use 2.5.3 that i had already built against 4.0/x86 for the time being. I'd be happy to try any patches/release that this is corrected in when-ever it becomes available.

Revision history for this message

Charlie Poole (charlie.poole) wrote on 2010-04-14:

#9

I see the problem.... If you have it installed, just build with NAnt. The Nant
script for each of the exe's builds both the cil and the x86 images. Failing
that, you can easily work with the VS solution if you're willing to hack it....

For each exe (nunit, nunit-console and nunit-agent) create another project
containing the same files called nunit-x86, nunit-console-x86 and
nunit-agent-x86. They should be identical except that the platform target
is x86 and the assemblies have a different name. Copy all your assemblies
into a directory structure similar to what the nunit install provides: a main
directory for the executables plus subdirectories lib, test and framework.

Or wait for 2.5.5 around the end of the month. :-)

Charlie

On Tue, Apr 13, 2010 at 5:07 PM, ruddy <email address hidden> wrote:
> I can change the source code (and did), but in order to load the dll it
> has to be compiled for x86 - and of course its not readily doing that as
> we've discussed - so when i forced nunit to build as x86:
> NUnitConfiguration::GetTestAgentExePath is trying to load nunit-
> agent-x86.exe which of course didn't get built...
>
> As to my previous ramblings
> #1 was only a problem because i tried renaming the .exe as you suggested for a test, but in order for the renamed nunit to actually run after renaming i had to rename the config which sort of lead to the #2 issue {strictly speaking i didn't have to rename the nunit-agent config file since it was not intended to run in the test anyway} and of course i wouldn't have normally run the agent manually but i was just verifying it was no longer crashing at startup because of mismatched configuration file. Some type of warning might be nice, but hardly a major priority.
>
> #3 - is only somewhat problematic since i'd like to build the x86
> version of the code to fix this {since a build targeting 'any cpu' will
> load as 64bit code on a 64bit machine but then gives a "bad image" error
> on trying to load a 32 bit C++/clI test dll which is where i started
> down this path to begin with...} of course, manually updating the
> projects, while not hard, is something that will get lost with each new
> code drop.
>
> FWIW: This is not a critical issue for me personally at this point as i
> can use 2.5.3 that i had already built against 4.0/x86 for the time
> being. I'd be happy to try any patches/release that this is corrected
> in when-ever it becomes available.
>
> --
> NullReferenceException ProcessRunner.Load loading test
> https://bugs.launchpad.net/bugs/561487
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
>

I see the problem.... If you have it installed, just build with NAnt. The Nant
script for each of the exe's builds both the cil and the x86 images. Failing
that, you can easily work with the VS solution if you're willing to hack it....

For each exe (nunit, nunit-console and nunit-agent) create another project
containing the same files called nunit-x86, nunit-console-x86 and
nunit-agent-x86. They should be identical except that the platform target
is x86 and the assemblies have a different name. Copy all your assemblies
into a directory structure similar to what the nunit install provides: a main
directory for the executables plus subdirectories lib, test and framework.

Or wait for 2.5.5 around the end of the month. :-)

Charlie

On Tue, Apr 13, 2010 at 5:07 PM, ruddy <douglass@omtool.com> wrote:
> I can change the source code (and did), but in order to load the dll it
> has to be compiled for x86 - and of course its not readily doing that as
> we've discussed - so when i forced nunit to build as x86:
> NUnitConfiguration::GetTestAgentExePath is trying to load nunit-
> agent-x86.exe which of course didn't get built...
>
> As to my previous ramblings
> #1 was only a problem because i tried renaming the .exe as you suggested for a test, but in order for the renamed nunit  to actually run after renaming i had to rename the config which sort of lead to the #2 issue {strictly speaking i didn't have to rename the nunit-agent config file since it was not intended to run in the test anyway} and of course i wouldn't have normally run the agent manually but i was just verifying it was no longer crashing at startup because of mismatched configuration file.  Some type of warning might be nice, but hardly a major priority.
>
> #3 - is only somewhat problematic since i'd like to build the x86
> version of the code to fix this {since a build targeting 'any cpu' will
> load as 64bit code on a 64bit machine but then gives a "bad image" error
> on trying to load a 32 bit C++/clI test dll which is where i started
> down this path to begin with...} of course, manually updating the
> projects, while not hard, is something that will get lost with each new
> code drop.
>
> FWIW: This is not a critical issue for me personally at this point as i
> can use 2.5.3 that i had already built against 4.0/x86 for the time
> being.  I'd be happy to try any patches/release that this is corrected
> in when-ever it becomes available.
>
> --
> NullReferenceException ProcessRunner.Load loading test
> https://bugs.launchpad.net/bugs/561487
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
>

Revision history for this message

Charlie Poole (charlie.poole) wrote on 2010-04-15:

#10

The fix is in trunk. It would be great if you could try it in your environment.

Changed in nunitv2:
assignee:	nobody → Charlie Poole (charlie.poole)
milestone:	none → 2.5.5
status:	Triaged → Fix Committed

Revision history for this message

ruddy (douglass) wrote on 2010-04-15:

#11

I'd be glad to if i had a clue how to fetch the trunk? any cliff notes or pointers to where to start would be helpful - thanks.

Revision history for this message

Charlie Poole (charlie.poole) wrote on 2010-04-15:

#12

The best info is probably that in the developer faq:
http://nunit.org/wiki/doku.php?id=dev:faq

However, re-reading this thread, I see that your environment might not
allow you to produce
the same packages that NUnit delivers, so I'm posting a patched
installer for you at
http://nunit.org/downloads/NUnit-2.5.4.10105-dbg.msi

You'll have to uninstall our existing 2.5.4 copy to install this one.

Charlie

On Thu, Apr 15, 2010 at 5:12 AM, ruddy <email address hidden> wrote:
> I'd be glad to if i had a clue how to fetch the trunk? any cliff notes
> or pointers to where to start would be helpful - thanks.
>
> --
> NullReferenceException ProcessRunner.Load loading test
> https://bugs.launchpad.net/bugs/561487
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
>

Revision history for this message

ruddy (douglass) wrote on 2010-04-16:

#13

That worked correctly - the tests loaded and executed properly.

Thanks!

Revision history for this message

Charlie Poole (charlie.poole) wrote on 2010-04-16:

#14

Thanks for checking - it will be in the 2.5.5 release.
Charlie

On Fri, Apr 16, 2010 at 3:56 AM, ruddy <email address hidden> wrote:
> That worked correctly - the tests loaded and executed properly.
>
> Thanks!
>
> --
> NullReferenceException ProcessRunner.Load loading test
> https://bugs.launchpad.net/bugs/561487
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
>

Revision history for this message

Peter Ritchie (1-launchpad-peterritchie-com) wrote on 2010-04-19:

#15

I've encountered this same problem on my 64-bit computer. I've tried your 10105 build and it resolves the problems I've encountered.

Is there any way to make this build the current download? Anyone installing VS 2010 on a 64-bit computer who wants to use nunit is going to encounter this problem as soon as they try to run their unit tests.

Cheers -- Peter

Revision history for this message

Charlie Poole (charlie.poole) wrote on 2010-04-19:

#16

A preview of the 2.5.5 release will be out this week.

Charlie

On Mon, Apr 19, 2010 at 9:15 AM, Peter Ritchie
<email address hidden> wrote:
> I've encountered this same problem on my 64-bit computer. I've tried
> your 10105 build and it resolves the problems I've encountered.
>
> Is there any way to make this build the current download? Anyone
> installing VS 2010 on a 64-bit computer who wants to use nunit is going
> to encounter this problem as soon as they try to run their unit tests.
>
> Cheers -- Peter
>
> --
> NullReferenceException ProcessRunner.Load loading test
> https://bugs.launchpad.net/bugs/561487
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
>

Charlie Poole (charlie.poole) on 2010-04-23

Changed in nunitv2:
status:	Fix Committed → Fix Released

Affects		Status	Importance	Assigned to	Milestone
	NUnit V2	Fix Released	High	Charlie Poole	NUnit V2 2.5.5
Nominated for Trunk by Xiao Zong

NUnit V2

NullReferenceException ProcessRunner.Load loading test

Bug Description

Related branches

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches