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.
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 : nunit-core@lists.launchpad.net
Unsubscribe : https://launchpad.net/~nunit-core
More help : https://help.launchpad.net/ListHelp
