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

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

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
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,500

Thanks: 723 times
Was thanked: 909 time(s) in 865 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: Member

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

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
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,500

Thanks: 723 times
Was thanked: 909 time(s) in 865 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: Member

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

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
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,500

Thanks: 723 times
Was thanked: 909 time(s) in 865 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: Member

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

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
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,500

Thanks: 723 times
Was thanked: 909 time(s) in 865 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: Member

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

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
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: Member

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

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
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,500

Thanks: 723 times
Was thanked: 909 time(s) in 865 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: Member

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

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
No worries

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

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

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
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,500

Thanks: 723 times
Was thanked: 909 time(s) in 865 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,500

Thanks: 723 times
Was thanked: 909 time(s) in 865 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: Member

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

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
Ok no worries. I've excluded the affected tests. Please keep me informed.
BenREbits
#17 Posted : Wednesday, August 22, 2018 8:03:21 AM(UTC)
Rank: Member

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

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
Morning,

Can I have an update on the progress of the fix of the issue please?
Remco
#18 Posted : Wednesday, August 22, 2018 10:47:08 AM(UTC)
Rank: NCrunch Developer

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

Thanks: 723 times
Was thanked: 909 time(s) in 865 post(s)
We've been chasing this one all week (and weekend, sadly). It's tough. It's actually been around for a while too, since the first versions of .NET Core.

The problem is being caused by package referencing overrides related to aspnetcore. When aspnetcore is referenced, certain packages (such as System.Xml.XDocument) follow a different resolution pattern and actually shouldn't be declared in the .deps file used for runtime resolution.

Now that we understand the problem quite well, we're working on a fix. Unfortunately, because of the way this area of the system works, I haven't been able to find a suitable workaround. So it'll need to be a code change. I'll let you know as soon as we have it available.
Remco
#19 Posted : Sunday, August 26, 2018 11:12:25 PM(UTC)
Rank: NCrunch Developer

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

Thanks: 723 times
Was thanked: 909 time(s) in 865 post(s)
1 user thanked Remco for this useful post.
BenREbits on 8/28/2018(UTC)
BenREbits
#20 Posted : Tuesday, August 28, 2018 8:16:17 AM(UTC)
Rank: Member

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

Thanks: 1 times
Was thanked: 1 time(s) in 1 post(s)
Hi,

Thanks for that it works much better. Thanks so much for your help.

Ben
1 user thanked BenREbits for this useful post.
Remco on 8/28/2018(UTC)
Users browsing this topic
Guest
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.086 seconds.