Hello Mark,

Yes, I understand that, having written the code. If you use a separate AppDomain
or process per assembly, this will no longer be the case. Each test
domain will have it's own set probing path, based on the location of
the single assembly being loaded in that domain and I expect it to
work in both cases.

Is there an obstacle to your simply trying this suggestion? It's just
a matter of changing your command line or nunit project settings and
it would be quite helpful to know whether it does solve the problem
for you.

Charlie

On Wed, Nov 24, 2010 at 2:39 PM, mark cortes <[email protected]> wrote:
> I can tell you exactly what's causing it. NUnit specifies a list of  paths 
> when
> it loads an assembly. These paths are used by .NET to search  for any 
> referenced
> assemblies. The path list that NUnit specifies is basically the path to EVERY
> assembly in the NUnit project.  Thus, NUnit searches for references in other
> loaded assemblies'  directories instead of just the local directory. I can 
> send
> you the project which demonstrates this via private transmission, as well as 
> the
> log generated by fuslogvw.exe which reveals the paths .NET is searching for 
> the
> references in.
>
> Mark
>
> --
> Failed tests: Could not load file or assembly
> https://bugs.launchpad.net/bugs/680735
> You received this bug notification because you are a member of NUnit
> Developers, which is subscribed to NUnit V2.
>

-- 
Failed tests: Could not load file or assembly
https://bugs.launchpad.net/bugs/680735
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:
NUNIT VERSION
NUnit 2.5.7.10213

DESCRIPTION
When multiple test assemblies are loaded into NUnit, and they reference 
different strongly named assemblies with the same file name, all but the first 
assembly fails all tests. The tests fail indicating the following exception was 
thrown:

NUnitTests.Common.ByteExtensionsTests.HighNibble:
System.IO.FileLoadException : Could not load file or assembly 'NLib, 
Version=1.1.0.0, Culture=neutral, PublicKeyToken=16fb73b766f2d210' or one of 
its dependencies. The located assembly's manifest definition does not match the 
assembly reference. (Exception from HRESULT: 0x80131040)

PROBABLE CAUSE
By using fuslogvw.exe and reading about Microsoft's assembly loader, I have 
concluded the following: When Microsoft's assembly loader is searching for an 
assembly, it stops looking on the first directory containing an assembly with 
the correct file name. If the found assembly differs by version number or 
PublicKeyToken, a FileLoadException is thrown instead of looking further. This 
is apparently by design by Microsoft for performance reasons, although 
unintuitive. NUnit appears to cause the test assembly to search for referenced 
assemblies in the directories of ALL loaded test assemblies, and in the same 
order. Thus, the wrong assembly is used from the wrong directory. Under the 
unlikely case the referenced assemblies weren't strongly named, no error would 
be thrown indicating the wrong library is being tested.

SIGNIFICANCE
Using assemblies with identical names is useful when creating libraries to 
target multiple .NET Framework versions. NUnit 2.5.7 is unusable as a means to 
test the assemblies simultaneously, and it becomes necessary to test each piece 
of the final solution separately.



_______________________________________________
Mailing list: https://launchpad.net/~nunit-core
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~nunit-core
More help   : https://help.launchpad.net/ListHelp

Reply via email to