search

xunit / visualstudio.xunit

VSTest runner for xUnit.net (for Visual Studio Test Explorer and dotnet test)
https://xunit.net/
Other
146 stars 81 forks source link

Failure to load xunit.runner.utility.net452.dll on case sensitive file system #358

Closed manfred-brands closed 9 months ago

manfred-brands commented 1 year ago

We are using case sensitive file names on our Windows NTFS source directories to ensure no casing errors occur which throw of git and our github builds that run under Unix.

fsutil.exe file setCaseSensitiveInfo C:\Development enable

This gives use problems with xunit 2.4.2 The NuGet package xunit.runner.reporters contains the the file xunit.runner.reporters.net452.dll However the code looks for: bin\Debug\net48\xunit.runner.utility.net452.DLL Note the capital .DLL extension.

The cause is the use of the (deprecated) Assembly.CodeBase which returns a URL which xunit, inside its GetLocalCodeBase extension method, then converts to a Path. The code should call Assembly.Location instead.

CodeBase: file:///C:/Users/m.brands/source/Tests/bin/Debug/net48/Tests.DLL
Location: C:\Users\m.brands\source\Tests\bin\Debug\net48\Tests.dll

I'm happy to create a PR for this.

bradwilson commented 1 year ago

The issue with just swapping out .CodeBase for .Location is that they actually point to different locations. The former points to the original location of the assembly, whereas the latter points to the location the assembly was loaded from. When using shadow copying with app domains, those two locations are different. We will frequently use the result of .CodeBase to find the location where the assemblies exist on disk, so that we can find other things in the same folder (like your configuration file) that don't get copied over into the shadow copy folder.

Unfortunately, the bug appears to come from the .NET Framework itself (when running on Windows) where they clearly did not anticipate that users would turn on a case sensitive file system, and just blindly adding .DLL to the end of the assembly would be "fine".

I'm not 100% sure that I have an easy fix. I'm reluctant to just hard-transform all .DLL into .dll, since that isn't necessarily the correct behavior either. I'm going to keep this open as an issue that requires more investigation.

bradwilson commented 9 months ago

Coming back to this, I don't think there's anything we can or should do here, as the issue belongs with .NET for not preserving the case of the filename when handing it back to us.