nunit-core team mailing list archive

[Charlie Poole <charlie@xxxxxxxxx>]

Of course, NUnit specifies the locations to be searched. The point is
that only one set of locations can be specified per AppDomain,
therefore ylou need to use multiple AppDomains (either in the same or
different processes) in order to have separate locations specified for
each assembly.

I'll mark this bug pending for now.

Charlie

On Wed, Nov 24, 2010 at 10:55 PM, mark cortes <680735@xxxxxxxxxxxxxxxxxx> wrote:
> I'm almost positive NUnit is specifying the search paths, unless you are
> positive I am wrong. I want to watch the update bug a little longer. From what
> I've gathered it's surely related to AppDomains/Processes, and it may be related
> to identically named assemblies.Thank you, you've been more than helpful.
>
>
> ________________________________
> From: Charlie Poole <charlie@xxxxxxxxx>
> To: macortes84@xxxxxxxxx
> Sent: Wed, November 24, 2010 9:04:25 PM
> Subject: Re: [Bug 680735] [NEW] Failed tests: Could not load file or assembly
>
> Assemblies are found by the .NET loader, not by NUnit. When you run
> several assemblies in the same AppDomain, you are essentially saying
> that all the assemblies will use the same AppBase, ProbingPath, etc.
> The problem is that you may not have specified this, but are just
> seeing it as the default behavior.
>
> I think the ultimate solution is for the default behavior to provide
> the _most_ isolation, rather than the _least_. That way, unless you
> specify otherwise, NUnit could use a separate process per assembly,
> giving the same behavior that occurs when you test each assembly in a
> separate execution of NUnit.
>
> However, this is a significant breaking change, so won't happen in the
> 2.x series.
>
> If the update behavior you see only happens when the assemblies have
> the same name, we can redirect this bug to fix that behavior. If it's
> more general, then it's better to treat it as a separate bug.
>
> Charlie
>
> On Wed, Nov 24, 2010 at 7:19 PM, mark cortes <680735@xxxxxxxxxxxxxxxxxx> wrote:
>> Now, I understand. Thank you. Running the assemblies in separate AppDomains
>> causes the correct assemblies to be loaded; however, the leaf nodes for some
> of
>> the assemblies don't update and remain gray after the test runs. That should
>> probably be reported as a separate bug. Still, I think the reference
> assemblies
>> should only be searched for in the path of whichever assembly is being tested.
>>
>> --
>> 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 direct subscriber
> of the bug.
>
> 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.
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/nunitv2/+bug/680735/+subscribe
>
> --
> 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.
>

** Changed in: nunitv2
       Status: New => Incomplete

-- 
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: Incomplete

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.