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.
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.
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).
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
BenREbits 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.
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.
BenREbits 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 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.
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.
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
BenREbits 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?
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 :)
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.