vstest.console.dll does not exists after upgrading VS 2022 Enterprise from Version 17.14.0 Preview 2.0 to Preview 3.0

[fmaeseele]

After upgrading from Visual Studio 2022 Enterprise from Version 17.14.0 Preview 2.0 to 3.0, I cannot run my VS Tests with the Ubuntu environment. When I look at the console I can see this:

========== Starting test discovery ==========
StreamJsonRpc.RemoteInvocationException: File /mnt/c/program files/microsoft visual studio/2022/preview/common7/ide/commonextensions/microsoft/testwindow/VsTest/vstest.console.dll does not exists
at StreamJsonRpc.JsonRpc.InvokeCoreAsync[TResult](RequestId id, String targetName, IReadOnlyList1 arguments, IReadOnlyList1 positionalArgumentDeclaredTypes, IReadOnlyDictionary2 namedArgumentDeclaredTypes, CancellationToken cancellationToken, Boolean isParameterObject) at Microsoft.VisualStudio.TestWindow.Host.TestPlatformProvider.DiscoverTestsAsync(DiscoverTestsRequest request, VsTestRunSession runSession, ImmutableDictionary2 discoverSettingsMap, ImmutableArray1 containersToDiscover, IEnumerable1 activeEnvironments, CancellationToken cancellationToken)
RPC server exception:
System.Exception: File /mnt/c/program files/microsoft visual studio/2022/preview/common7/ide/commonextensions/microsoft/testwindow/VsTest/vstest.console.dll does not exists
at Microsoft.TestPlatform.VsTestConsole.TranslationLayer.VsTestConsoleProcessManager..ctor(String vstestConsolePath) in //src/Microsoft.TestPlatform.VsTestConsole.TranslationLayer/VsTestConsoleProcessManager.cs:line 76
at Microsoft.TestPlatform.VsTestConsole.TranslationLayer.VsTestConsoleWrapper..ctor(String vstestConsolePath, ConsoleParameters consoleParameters) in //src/Microsoft.TestPlatform.VsTestConsole.TranslationLayer/VsTestConsoleWrapper.cs:line 82
at Microsoft.VisualStudio.TestWindow.Messaging.RemoteAgent.TestRunController.VsTestRunController.Create(String testConsolePath, InitializeCapabilitiesRequest clientCapabilities, IDictionary2 environment, Boolean inheritEnvironmentVariables, ITestRunDataSink dataSink, IInternalLogger logger) in D:\a\_work\1\s\src\TestWindow\Internal\RemoteAgent\TestAgentBridge\TestRunController.VsTestConsoleRunner.cs:line 92 at Microsoft.VisualStudio.TestWindow.Messaging.RemoteAgent.TestRunController.CreateVsTestRunController(ITestRunDataSink dataSink) in D:\a\_work\1\s\src\TestWindow\Internal\RemoteAgent\TestAgentBridge\TestRunController.cs:line 138 at Microsoft.VisualStudio.TestWindow.Messaging.RemoteAgent.TestRunController.<>c__DisplayClass21_0.<Initialize>b__0() in D:\a\_work\1\s\src\TestWindow\Internal\RemoteAgent\TestAgentBridge\TestRunController.cs:line 132 at System.Lazy1.ViaFactory(LazyThreadSafetyMode mode)
at System.Lazy1.ExecutionAndPublication(LazyHelper executionAndPublication, Boolean useDefaultConstructor) at System.Lazy1.CreateValue()
at Microsoft.VisualStudio.TestWindow.Messaging.RemoteAgent.TestRunController.GetRunnerForLauncher(String launcherType, RunSettingsInfo runSettingsInfo) in D:\a_work\1\s\src\TestWindow\Internal\RemoteAgent\TestAgentBridge\TestRunController.cs:line 184
at Microsoft.VisualStudio.TestWindow.Messaging.RemoteAgent.TestRunController.DiscoverTestsAsync(IEnumerable1 sources, String launcherType, String launcherConfiguration, RunSettingsInfo runSettings, RemoteTestPlatformOptions options, ITestRunDataSink dataSink, CancellationToken cancellationToken) in D:\a\_work\1\s\src\TestWindow\Internal\RemoteAgent\TestAgentBridge\TestRunController.cs:line 253 at Microsoft.VisualStudio.TestWindow.Messaging.RemoteAgent.BaseTestAgentBridge.DiscoverTestsAsync(IEnumerable1 sources, String launcherType, String launcherConfiguration, String discoverySettings, RemoteTestPlatformOptions options, CancellationToken cancellationToken) in D:\a_work\1\s\src\TestWindow\Internal\RemoteAgent\TestAgentBridge\BaseTestAgentBridge.cs:line 117

========== Test discovery aborted: 0 Tests found in 419,5 ms ==========

But I still can run my tests with the default environment (ie Windows).

Here is my testEnvironment.json file:

{
"version": "1",
"environments": [
// See https://aka.ms/remotetesting for more details
// about how to configure remote environments.
{
"name": "WSL Ubuntu-24.04",
"type": "wsl",
"wslDistribution": "Ubuntu"
},
{
"name": "Red Hat Enterprise Linux 8.10",
"type": "wsl",
"wslDistribution": "rhel8wsl"
}
]
}

[nohwnd]

this is caused by incorrect packaging of test explorer, I've made a pr for a fix. please follow this ticket which is linked to the PR: https://developercommunity.visualstudio.com/t/Remote-Testing-via-ssh:-vstest-library-d/10583603

[rafalmaciag]

I'm having the same problem.
I'm not sure if this is related to the fact I have installed VS on "d" drive. The file indeed does not exists.
vstest.console.dll
Is' a bit weird to find this file in ..2022/preview/common7/ide/commonextensions/microsoft/testwindow/VsTest folder.
Does anyone knows where this file should be located? There vstest.console.dll in the SDK for .net-core, but it might not be the same.

[nohwnd]

This is not related to installation path, the whole part that gets copied to the remote (SSH) host is not copied there, so you are not able to find the dll. It needs to be fixed on VS side.

[rafalmaciag]

So even in wsl, ssh is used? I have this problem when running unit-tests in wsl.

[nohwnd]

Yes, ssh is how the process talks with wsl. It copies vstest.console.dll (and the rest of the vstest shipment that we normally put into dotnet/sdk) into the remote system and bridges it with a client that forwards commands to it and responses back.

[rafalmaciag]

Ok, That's interesting. That explains a lot.
As a mitigation, if I manually copy files (or create hard-links) - would it work? What files are required?

[nohwnd]

In theory it should work, but maybe the deployment will try to overwrite the files, or fail, I don't remember the logic there.

You need content of this package, in contentFiles/any/net9.0/*

https://www.nuget.org/packages/Microsoft.TestPlatform.CLI/17.14.0-preview-25107-01

[rafalmaciag]

Works! 👍 Thank you!

[nohwnd]

perfect, thanks for reporting back.

[fmaeseele]

Our saviour!
Thanks a lot this workaround works well for me (Tests under WSL/Ubuntu distro)