.NET 4.7.2 : Warning that extensions could not be loaded from xunit.runner.visualstudio.dotnetcore.testadapter.dll

[mayka-mack]

When I run tests targeting .NET 4.7.2 within Visual Studio 2022, I get a warning message that extensions could not be loaded from xunit.runner.visualstudio.dotnetcore.testadapter.dll. The tests do run, but I wanted to check whether this error message is benign or indicative of an issue. An example skeleton solution which triggers the warning for me is attached.

XUnit.zip

20:07:10:609    Failed to load extensions from file 'C:\Users\mayka-mack\.nuget\packages\xunit.runner.visualstudio\2.5.5\build\net6.0\xunit.runner.visualstudio.dotnetcore.testadapter.dll'. Please use /diag for more information.
20:07:10:712    [xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.5.5+28b46ff510 (32-bit .NET Framework 4.8.4645.0)
20:07:10:984    [xUnit.net 00:00:00.27]   Starting:    XUnitTests
20:07:11:078    [xUnit.net 00:00:00.37]   Finished:    XUnitTests
20:07:11:183    ========== Test run finished: 1 Tests (1 Passed, 0 Failed, 0 Skipped) run in 409 ms ==========

[bradwilson]

The warning comes from VSTest and is benign. I have no idea why they try to load both the .NET Framework and .NET Core versions of the test runner, but they do. 🤷🏼‍♂️

[mayka-mack]

Good to know. Since it’s benign, I’ll just ignore the error. As this is something out of your control, this issue can be closed. Thank you very much for the clarification!

[bradwilson]

I'm going to do a little experimentation and see if there's anything I can do about it, so I'll wait to close it. I'm skeptical, but it's worth another swing at it. 😄

[bradwilson]

I actually did come up with a fix for it, and it goes away as of 2.5.6-pre.3.

The longer story: back when we supported Windows Phone (and later UWP), we had to name our test adapters with different names, because of the way discovery vs. execution worked. The discovery would happen in .NET Framework, and execution would happen in the device simulator. What it meant, though, is that both the .NET Framework and Windows Phone test adapters would have to live side-by-side in the output folder. So, all our test adapters had different file names.

This appears to be what's triggering this behavior. Now, since we only support .NET Framework and .NET Core/.NET, this separate naming system isn't necessary any more. Giving both files the same name means that VSTest stops trying to use both (which is clearly a bug in VSTest; it should never have done that, given the adapters lived in different folders named net462 and net6.0). So, "problem" fixed. 😄

[tomaszras-intive]

Hello. I think this change broke running x86 .NET Framework 4.8 Tests on Azure DevOps using VsTest@2 Task. When I upgraded from version 2.5.5. to 2.5.6 i got message:

##[warning]DiscoveryMessage : No test is available in D:\a\1\s\artifacts\bin\MyNetFmX86OnlyPorj.Tests\release\MyNetFmX86OnlyPorj.Tests.dll. Make sure that test discoverer & executors are registered and platform & framework version settings are appropriate and try again.

Any of my X86 .NET Framework test got discovered, only .NET6 x64 are working.

Reverting xunit.runner.visualstudio to 2.5.5 solves the issue. I don't see any other related things in changelog, so I guess this change broke this scenario.

[bradwilson]

@tomaszras-intive I wonder if they've hard-coded file name assumptions in their task. I wonder if I can find the source for it online...

[bradwilson]

I don't see anything xUnit.net-specific at all here (which is good): https://github.com/microsoft/azure-pipelines-tasks/blob/master/Tasks/VsTestV2/vstest.ts

Do you get any other information besides the error you pasted? How are you forcing x86 for your .NET Framework tests?

[bradwilson]

@tomaszras-intive I cannot repro this.

Project: https://dev.azure.com/xunit/_git/vs297-repro

I run dotnet test -v:normal ahead of time just to make sure that it worked, and showed that the .NET Framework tests were running in x86 mode: (pipeline output)

Then I use VsTest@2: (pipeline output)

I think you're going to need to open a new issue with a repro project, because there's something different about what you're doing vs. what I'm doing.

[tomaszras-intive]

Ok, I will create publicly available example and open a new issue.