nunit-core team mailing list archive

[Charlie Poole <charlie@xxxxxxxxx>]

As you explain the problem, I'm not sure whether multiple AppDomains
or even processes will solve it, as it really depends on what .NET
does more than anything else. We could research this, but it's pretty
trivial to just run the tests changing the settings and see what
happens. :-)

charlie

On Wed, Nov 24, 2010 at 11:16 AM, mark cortes <680735@xxxxxxxxxxxxxxxxxx> wrote:
> Let me clarify. I have 3 assemblies with the name which target different
> versions of .NET. I have 3 unit testing assemblies to test each of the 3
> production assemblies. When UnitTestAssembly2 is run, it tries to use
> ProductionAssembly1 in UnitTestAssembly1's bin folder, which fails because it
> has a different PublicKeyToken.
>
> Can multiple AppDomains, or further multiple processes resolve this? And,
> indeed, you are correct, I am trying to avoid separate runs for each assembly as
> the number of assemblies may grow to 6 or higher as new versions of .NET are
> released, and  it can become tedious to run regularly and prone to oversight as
> far as testing all assemblies.
>
> Mark
>
>
>
> ________________________________
> From: Charlie Poole <charlie@xxxxxxxxx>
> To: macortes84@xxxxxxxxx
> Sent: Tue, November 23, 2010 10:55:01 PM
> Subject: Re: [Bug 680735] [NEW] Failed tests: Could not load file or assembly
>
> Our intention is that such situations should be handled by use of
> multiple AppDomains or multiple processes. can you please try either
> or both of these and let us know if that approach solves the problem?
>
> Depending on how you are launching your tests, you can use either
> commandline options or NUnit project file settings to accomplish this.
> Of course, you can also do it by means of separate runs for each
> version, but I imagine that's what you are trying to avoid by
> including all the assemblies in the same test run.
>
> Charlie
>
> On Tue, Nov 23, 2010 at 8:42 PM, mark cortes <680735@xxxxxxxxxxxxxxxxxx> wrote:
>> Public bug reported:
>>
>> 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.
>>
>> ** Affects: nunitv2
>>     Importance: Undecided
>>         Status: New
>>
>> ** Description changed:
>>
>> - VERSION:
>> + NUNIT VERSION
>>  NUnit 2.5.7.10213
>>
>> - DESCRIPTION:
>> + 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)
>>
>> - CAUSE:
>> - 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.
>> + 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.
>>
>> - IMPORTANCE:
>> + 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.
>>
>> --
>> 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.
>

-- 
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.