Hi Ben,

Thanks for sharing this issue.

Does adding a reference to this Nuget package directly from your test project resolve the issue?

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

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.

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



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.

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

No worries

https://1drv.ms/u/s!AlncqTB9BmvThMoFdNES0GvTa0bN2A

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

Ok no worries. I've excluded the affected tests. Please keep me informed.

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.

Hi,

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

Ben