Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

NCrunch using incorrect dependency version
BenREbits
#1 Posted : Thursday, August 9, 2018 12:27:15 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 8/9/2018(UTC)
Posts: 9
Location: United Kingdom

Hi,

I have integration tests I am running which rely on reading in data from an XML file. When these tests are run via ReSharper or the integrated Visual Studio testing suite they run successfully. When trying to run through NCrunch, some of the tests fail stating:

System.IO.FileNotFoundException : Could not load file or assembly 'System.Xml.XDocument, Version=4.1.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot find the file specified.
at ...

However, in the same class some tests pass even though they are reading from an XML file (using the same functions) as well. In all failed cases it's the first brace of the method the test stops on.

Thanks,

Ben

DotNet Core SDK: 2.1.302
DotNet Core Runtime: 2.1.2
System.Xml.XDocument: 4.3.0
Remco
#2 Posted : Friday, August 10, 2018 5:15:11 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,328

Thanks: 700 times
Was thanked: 866 time(s) in 824 post(s)
Hi Ben,

Thanks for sharing this issue.

Does adding a reference to this Nuget package directly from your test project resolve the issue?
BenREbits
#3 Posted : Friday, August 10, 2018 8:15:30 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 8/9/2018(UTC)
Posts: 9
Location: United Kingdom

Sadly no. The 4.3.0 reference is in the .deps* file and other instances of XDocument work correctly in the same class so it's finding the reference occasionally, yet not every time.
Remco
#4 Posted : Saturday, August 11, 2018 1:23:52 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,328

Thanks: 700 times
Was thanked: 866 time(s) in 824 post(s)
Could you try enabling the preload assembly references setting for the test project? Hopefully this will resolve the inconsistency, so at least we see the same version of the binary loaded for each session.

Also, check the entire dependency structure to see if you have any version clashes with this particular package. For example, if you have a project in your structure that references one version of the package, and another project referencing a different version, the actual version loaded may depend upon the sequence in which the CLR loads dependencies into the environment (which depends on JIT/execution order).
BenREbits
#5 Posted : Thursday, August 16, 2018 8:19:11 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 8/9/2018(UTC)
Posts: 9
Location: United Kingdom

Enabling the setting made no difference. I have checked through all of the dependency files and can find no reference to the 4.1.1.0 version, only 4.3.0. 4.1.1.0 seems to be the version that's built in to .NET Core 2.1.2
Remco
#6 Posted : Thursday, August 16, 2018 11:08:37 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,328

Thanks: 700 times
Was thanked: 866 time(s) in 824 post(s)
BenREbits;12540 wrote:
Enabling the setting made no difference. I have checked through all of the dependency files and can find no reference to the 4.1.1.0 version, only 4.3.0. 4.1.1.0 seems to be the version that's built in to .NET Core 2.1.2


Unfortunately this is where the versioning system of .NET Core starts to create a ton of confusion.

v4.3.0 is the 'package version'. So this is the version you'll see in Nuget and it's the version number after which the directory containing the package is named.
v4.1.1.0 is the assembly version. If you open the assembly in any kind of IL analysis tool (i.e. ILSpy, ILDASM, etc), this is the version baked into the assembly file itself. It's this version that the CLR is actually trying to find.

It is possible for there to be different assembly versions for the same package version. This also gets especially complicated if you are cross targeting or working with different 'platforms', for example, if you're using different versions of .NET Core or .NET Standard side-by-side. Different versions of .NET Core actually have entirely different assemblies and even different dependency structures, even though they share the same package version numbers.

What does your solution structure look like? Are you cross-targeting at all?

If you're able to produce a sample solution that can reproduce this, I should be able to dig quite a bit deeper into what's going on. You can submit code through the contact form on this site.
BenREbits
#7 Posted : Thursday, August 16, 2018 11:24:37 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 8/9/2018(UTC)
Posts: 9
Location: United Kingdom

I love how their version of a "simplified" solution is far more complex than any they have done before.

So we're running an ASP.NET Core 2.1.2 project referencing two .NET Standard 2.0 projects. The test project is an NUnit project referencing one of the .NET Standard 2.0 projects. I will have a look to product a sample when I have some down time.

What is peculiar is it's some TestCase's within the same TestFixture which fail where others pass. They use the same process and the same XML files.
Remco
#8 Posted : Thursday, August 16, 2018 12:00:11 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,328

Thanks: 700 times
Was thanked: 866 time(s) in 824 post(s)
BenREbits;12542 wrote:
I love how their version of a "simplified" solution is far more complex than any they have done before.


Sadly, this is just the tip of the iceberg :(

BenREbits;12542 wrote:

So we're running an ASP.NET Core 2.1.2 project referencing two .NET Standard 2.0 projects. The test project is an NUnit project referencing one of the .NET Standard 2.0 projects. I will have a look to product a sample when I have some down time.

What is peculiar is it's some TestCase's within the same TestFixture which fail where others pass. They use the same process and the same XML files.


Something worth doing here would be to try debugging one of the failing tests and examining the list of loaded modules in the debug process. You can then compare these loaded modules with those shown when working with a normal, passing test. The list of loaded modules is very informative - it will give you both the true version number of every loaded assembly, and also their file location on disk.
BenREbits
#9 Posted : Thursday, August 16, 2018 1:53:57 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 8/9/2018(UTC)
Posts: 9
Location: United Kingdom

Quote:
Something worth doing here would be to try debugging one of the failing tests and examining the list of loaded modules in the debug process. You can then compare these loaded modules with those shown when working with a normal, passing test. The list of loaded modules is very informative - it will give you both the true version number of every loaded assembly, and also their file location on disk.


That was interesting. The library System.Xml.XDocument.dll is not loaded at all under NCrunch on the failing tests, under the ReSharper debug it is present. It seems to be that it's not determining that it should load the library on runtime.
BenREbits
#10 Posted : Thursday, August 16, 2018 4:05:35 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 8/9/2018(UTC)
Posts: 9
Location: United Kingdom

The test passes when the project is on it's own. When the test project references a .net standard project the issue occurs.

Further investigation has shown that although System.Xml.XDocument.dll is included in .NET Core 2.1.400 SDK (runtime 2.1.2), the actual 4.3.0 package only points to .NET Standard 1.3 (assembly version 4.0.12.0).

I have created a sample solution and sent it via the contact form which replicates the issue and I'm hoping and praying that it's not something stupid that I'm doing.

The subject is the same as the OP name and contains the link to this post
Remco
#11 Posted : Thursday, August 16, 2018 11:13:23 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,328

Thanks: 700 times
Was thanked: 866 time(s) in 824 post(s)
BenREbits;12545 wrote:

I have created a sample solution and sent it via the contact form which replicates the issue and I'm hoping and praying that it's not something stupid that I'm doing.

The subject is the same as the OP name and contains the link to this post


Sadly, this one didn't seem to have made it through. I wonder if perhaps the file size was too large for the form. Do you have another way you can share it with me? Perhaps a dropbox link or something?
BenREbits
#12 Posted : Friday, August 17, 2018 7:53:22 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 8/9/2018(UTC)
Posts: 9
Location: United Kingdom

No worries

https://1drv.ms/u/s!AlncqTB9BmvThMoFdNES0GvTa0bN2A
BenREbits
#13 Posted : Friday, August 17, 2018 1:55:02 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 8/9/2018(UTC)
Posts: 9
Location: United Kingdom

Changed the link as so it's read only to stop modification
OneDrive
Remco
#14 Posted : Friday, August 17, 2018 11:37:14 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,328

Thanks: 700 times
Was thanked: 866 time(s) in 824 post(s)
Thanks! With this sample I can reproduce the problem exactly as described. This is being caused by a dependency clash between netstandard/netcoreapp. I have some ideas on how it might be possible to fix this. I'll let you know as soon as I have more information.

If you're uncomfortable about leaving the sample online, you can take it down now. I have the info I need now. Thanks :)
Remco
#15 Posted : Sunday, August 19, 2018 4:35:13 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,328

Thanks: 700 times
Was thanked: 866 time(s) in 824 post(s)
This problem is proving much harder to resolve than I expected. It will be a few days before I can provide a fix. Sorry.
BenREbits
#16 Posted : Monday, August 20, 2018 8:21:34 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 8/9/2018(UTC)
Posts: 9
Location: United Kingdom

Ok no worries. I've excluded the affected tests. Please keep me informed.
Users browsing this topic
Guest (3)
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.062 seconds.