nunit-core team mailing list archive

[Charlie Poole <charlie@xxxxxxxxx>]

Comments on your two separate stack traces:

#1) The key line here is
nunit.core.dll!NUnit.Core.DomainAgent.CreateInstance(System.AppDomain
targetDomain) + 0x8c Bytes

This static method attempts to create an instance of the DomainAgent
class in the test AppDomain. In order to create the instance, .NET must
locate the definition of the Type in the nunit.core assembly. However,
that assembly is not available in the ApplicationBase of the test
domain, since it's a part of NUnit itself.

In order to resolve the missing assembly, NUnit intercepts the failed
load. The AssemblyResolver class supplies the location of the nunit.core
assembly. The exception is thrown as a result of not finding the
assembly file but is caught and handled by .NET with the help of NUnit's
AssemblyResolver.

I know of no other way to handle this. If you are catching all
exceptions _when_they_are_thrown_ you will see this one. Isn't there an
option to  only stop for exceptions that are not handled?

#2) In this trace, NUnit is trying to load info in the visualstate xml
file. The assembly that is failing to load is the assembly generated by
.NET to handle the serialization of the data in the file. My guess is
that this generated assembly contains a reference to one of the NUnit
assemblies with the definition of the data structure. In that case, the
same mechanism as for the first stack trace would come into play.

The mechanism by which NUnit injects it's own assemblies into the test
AppDomain relies entirely on AssemblyResolver, which in turn relies on
the exception mechanism.

Your short-term solution is to turn off as many exceptions as necessary
to make debugging possible. A (much) longer-term solution is for us to
find a better way to load the code we need without relying on
exceptions. In fact, I believe we have that for NUnit 3.0. Avoiding this
design dependency on exceptions being thrown is one of the key
motivations behind the 3.0 rewrite.

I'm re-categorizing this as a 3.0 bug, just as you initially filed it,
since we won't really be able to solve the problem till 3.0. I'm also
renaming it to reflect what has to be done.

** Summary changed:

- Exceptions while starting NUnit Gui
+ Loading of tests should not depend on AssemblyResolver handling failures

** Project changed: nunitv2 => nunit-3.0

-- 
You received this bug notification because you are a member of NUnit
Developers, which is subscribed to NUnit V2.
https://bugs.launchpad.net/bugs/939596

Title:
  Loading of tests should not depend on AssemblyResolver handling
  failures

Status in NUnit Test Framework:
  New

Bug description:
  We have NUnit-Test which tests functions which call functions in
  native Dlls (via PInvoke). So we have always native and mamanged
  Debugger attached. When starting Gui parameterized with the test-
  assembly, the Debugger reports multiple Exceptions
  (EEFileLoadException, I think they are native C++) while the Gui tries
  to load the tests  (before anyone has done anything in the gui).

  It would be nice if it could be changed that no exception is thrown.
  The debugger always stops (if exceptions catching is put on, which
  must be to find errors in own code).

To manage notifications about this bug go to:
https://bugs.launchpad.net/nunit-3.0/+bug/939596/+subscriptions