Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot debug .NET Framework 4.7.2 unit test from "Debug Test" code lens in VSCode #4361

Closed
ghost opened this issue Jan 22, 2021 · 22 comments
Closed

Comments

@ghost
Copy link

ghost commented Jan 22, 2021

Issue Description

When I click on the "Debug Test" code lens above my NUnit tests, I get the following error popup in the corner of VSCode:
image

Error processing 'configurationDone' request. Unknown Error: 0x80131c30

I can debug my code just fine from the VSCode debug menu, breakpoints are hit. I'm also able to debug tests form the "Debug Test" code lens in other projects that are .NET Core. Appears to be only a .NET Framework error.

This error happens when running VSCode as Administrator and as a normal user (tested both.) I tried disabling all other extensions and only using the ms-dotnettools.csharp extension, but I'm getting the same error.

Steps to Reproduce

  1. Create a .NET Framework 4.7.2 test project:
    <Project Sdk="Microsoft.NET.Sdk">
    
        <PropertyGroup>
    	    <TargetFramework>net472</TargetFramework>
    	    <Platform>x64</Platform>    
    	    <IsPackable>false</IsPackable>
        </PropertyGroup>
    
        <ItemGroup>
    	    <PackageReference Include="NUnit" Version="3.12.0" />
    	    <PackageReference Include="NUnit3TestAdapter" Version="3.16.1" />
    	    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.5.0" />
        </ItemGroup>
    
    </Project>
    using NUnit.Framework;
    
    namespace tests
    {
        [TestFixture]
        public class Tests
        {
    	    [Test]
    	    public void Test1()
    	    {
    		    Assert.That(true, Is.EqualTo(true));
    	    }
        }
    }
  2. Create a .vscode\settings.json with the following setting:
    {
        "csharp.unitTestDebuggingOptions": {
    	    "type": "clr"
        }
    }
  3. Set a breakpoint in the test and click the "Debug Test" code lens above the test function.

Expected Behavior

Test runs and breakpoint is hit.

Actual Behavior

Debugging appears to start, but then stops and gives this error:
> Error processing 'configurationDone' request. Unknown Error: 0x80131c30

Logs

OmniSharp log

[info]: OmniSharp.DotNetTest.VSTestManager read: {"MessageType":"TestSession.Connected","Payload":null}
[info]: OmniSharp.DotNetTest.VSTestManager read: {"MessageType":"ProtocolVersion","Payload":1}
[info]: OmniSharp.DotNetTest.DebugSessionManager Debug session started.
[info]: OmniSharp.DotNetTest.DebugSessionManager Debug session ended.

C# log

none

Environment information

VSCode version: 1.52.1
C# Extension: 1.23.8

Dotnet Information .NET SDK (reflecting any global.json): Version: 5.0.100 Commit: 5044b93829

Runtime Environment:
OS Name: Windows
OS Version: 10.0.18363
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\5.0.100\

Host (useful for support):
Version: 5.0.0
Commit: cf258a14b7

.NET SDKs installed:
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.300 [C:\Program Files\dotnet\sdk]
2.1.301 [C:\Program Files\dotnet\sdk]
2.1.403 [C:\Program Files\dotnet\sdk]
2.1.801 [C:\Program Files\dotnet\sdk]
2.2.207 [C:\Program Files\dotnet\sdk]
3.1.300 [C:\Program Files\dotnet\sdk]
3.1.301 [C:\Program Files\dotnet\sdk]
5.0.100 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.23 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 3.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.1 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.23 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.5 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 3.1.9 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
Microsoft.WindowsDesktop.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs:
https://aka.ms/dotnet-download

Visual Studio Code Extensions
Extension Author Version
auto-using Fudge 0.7.15
Bookmarks alefragnani 12.1.4
bracket-pair-colorizer CoenraadS 1.0.61
cake-vscode cake-build 1.0.0
code-spell-checker streetsidesoftware 1.10.2
csharp ms-dotnettools 1.23.8
debugger-for-chrome msjsdiag 4.12.11
docker-explorer formulahendry 0.1.7
docomment k--kato 0.1.20
EditorConfig EditorConfig 0.16.4
gitlens eamodio 11.1.3
jupyter ms-toolsai 2020.12.414227025
markdown-pdf yzane 1.4.4
ng-template Angular 11.1.0
npm-intellisense christian-kohler 1.3.1
openapi-lint mermade 1.2.0
plantuml jebbs 2.14.1
plantuml jkeys089 1.8.1
python ms-python 2021.1.502429796
python tht13 0.2.3
remote-containers ms-vscode-remote 0.155.1
remote-ssh ms-vscode-remote 0.62.0
remote-ssh-edit ms-vscode-remote 0.62.0
remote-ssh-explorer ms-vscode-remote 0.56.0
remote-wsl ms-vscode-remote 0.52.0
rust rust-lang 0.7.8
stylelint shinnn 0.51.0
swagger-viewer Arjun 3.0.1
vscode-custom-css be5invis 4.0.1
vscode-docker ms-azuretools 1.9.1
vscode-icons vscode-icons-team 11.1.0
vscode-markdownlint DavidAnson 0.38.0
vscode-npm-script eg2 0.3.13
vscode-remote-extensionpack ms-vscode-remote 0.20.0
vscode-test-explorer hbenl 2.19.5
vscode-todo-highlight wayou 1.0.4
vscode-typescript-tslint-plugin ms-vscode 1.3.3
vscode-xml redhat 0.14.0
vscode-yaml redhat 0.14.0
@gregg-miskelly
Copy link
Contributor

This is expected, though the error message could certainly be better. The problem is the debugger is being told to launch for coreclr debugging. See https://github.com/OmniSharp/omnisharp-vscode/wiki/Desktop-.NET-Framework for more information.

@ghost
Copy link
Author

ghost commented Jan 22, 2021

@gregg-miskelly I have already changed the unitTestDebuggingOptions options in my sample repo. I pointed this out in my "Steps to reproduce".

@gregg-miskelly
Copy link
Contributor

Is your unit test process 32-bit?
That error is CORDBG_E_UNCOMPATIBLE_PLATFORMS (The operation failed because debuggee and debugger are on incompatible platforms.)

@ghost
Copy link
Author

ghost commented Jan 22, 2021

Is there a quick way to determine if the unit test process is 32 or 64 bit? Or should I just run it and look for the process in the Task Manager?

@gregg-miskelly
Copy link
Contributor

I am definitely not an expert on unit test projects. So there could be a better way, but I would either check task manager or have your code log the value of IntPtr.Size.

@ghost
Copy link
Author

ghost commented Jan 22, 2021

Ok I expanded Visual Studio Code in Windows Task Manager and the only process that I'm seeing running as 32 bit is something called the "Code Helper":

image

IntPtr.Size output a value of 4, which seems to indicate 32 bit.

@gregg-miskelly
Copy link
Contributor

I think that isn't the right process. That sounds like a part of VS Code, where your code is probably running in some unit test runner process, though maybe I am wrong.

At any rate, this extension only supports debugging x64 processes. So this is your problem. You may be able to fix this by either setting 'Platform' to 'x64' in your project file, or maybe clearing 'Prefer32Bit'. Though I don't know a ton about nunit, so maybe it doesn't respect that.

@ghost
Copy link
Author

ghost commented Jan 22, 2021

I'll update my question. I do have <Platform>x64</Platform> in my unit test .csproj file already, I have this whole time.

I've never heard of Prefer32Bit before, do you set this in your project's .csproj file? Like this?

<PropertyGroup>
  <TargetFramework>net472</TargetFramework>
  <Platform>x64</Platform>
  <Prefer32Bit>false</Prefer32Bit>
</PropertyGroup>

@gregg-miskelly
Copy link
Contributor

Yup.

@ghost
Copy link
Author

ghost commented Jan 23, 2021

Ok I added both of those things and I have the same problem.

I'm really not sure why my unit test process that gets kicked off (which I'm assuming is the NUnit3TestAdapter package) is running in 32 bit. It hasn't done that in the 1.5+ years that I've been working in this repository, it just started recently. What determines the platform that the test adapter process runs at? Is it Omnisharp? Or the C# package? Or VSCode?

If anyone has anymore information about any of this, I'm willing to try any sort of fix. I'd also like to know if anyone can reproduce this problem.

Thanks for your help so far @gregg-miskelly!

@ghost
Copy link
Author

ghost commented Jan 25, 2021

As an update, one of my friends is able to reproduce this exact same issue on his computer.

From what I can deduce, there seems to be something wrong with the "Debug Test" code lens. Here's a minimum setup that both of us used to reproduce this issue:

Following this process will NOT produce the error:

  1. dotnet clean
  2. dotnet build
  3. Hit "Debug Test"

But this process WILL produce the error:

  1. dotnet clean
  2. Hit "Debug Test"

It seems like "Debug Test" is doing something differently that running a full dotnet build command is doing? Both commands use the same MSBuild file location on my computer: Microsoft (R) Build Engine version 16.8.0+126527ff1 for .NET.

Omnisharp Debug Test issue.zip

@ghost
Copy link
Author

ghost commented Mar 18, 2021

Just to loop back around on this, I updated my installation of Visual Studio 2019 to the latest version (v16.9.2), which upgraded the build engine to Microsoft (R) Build Engine version 16.9.0+57a23d249 for .NET. With this upgrade I'm able to debug .NET Framework 4.7.2 projects in VSCode again.

I'm not sure exactly what the issue was, but it must be something with Visual Studio's installation alongside VSCode that was causing some issues. Or it was a bug in something was was installed with Visual Studio, maybe the initial release of .NET 5?

Either way I hope this helps someone 😊

@ghost ghost closed this as completed Mar 18, 2021
@ghost
Copy link
Author

ghost commented Apr 13, 2021

Nevermind this is still an issue 🙁

@ghost ghost reopened this Apr 13, 2021
@Toucan4Life
Copy link
Contributor

Toucan4Life commented Jun 10, 2021

After multiple weeks encountering this issue, I found a working solution.

Fix : Create a "My_Project.runsettings" file specifying "x64" and refer to it in the settings.json of you solution with "omnisharp.testRunSettings":"Path_To_My_File\My_Project.runsettings"

Explanation : The "0x80131c30" signify that the debugger and the debuggee doesn't target the same platform. (https://www.hresult.info/FACILITY_URT/0x80131C30)

In my case my project was targeting x64 and the debugger was launching with x86 (this can be seen using trace log on omnisharp, and you'll see it is using testhost.net47.x86.exe).

In my case I needed to specify to launch the debugger in x64. In Visual Studio, this can be done thanks to the property "TargetPlatform" of the runSettings file (https://docs.microsoft.com/en-us/visualstudio/test/configure-unit-tests-by-using-a-dot-runsettings-file?view=vs-2019#the-runsettings-file).

Fortunately, we can specify in omnisharp the runSettings file thanks to #3573. Unfortunately, this option was not made visible through intellisense (#3916).

Don't know why using .Net Core projects I didn't had the issue.

Hope this helps !

@microestc
Copy link

thanks

@ghost
Copy link
Author

ghost commented Sep 1, 2021

@ToucanSuperMan420 unfortunately, this did not work for me. When I add in the .runsettings file and then hit the "Debug Test" Code Lens link above one of my tests, the tests are attempted to be ran by Microsoft.VisualStudio.TestPlatform, which complains about a missing UnitTest.Project.deps.json file or missing testhost.dll. The NUnit Test Runner isn't being called at all, even though I'm referencing the NuGet package in my test project.

@IlIlIllIllI
Copy link

1 ½ years later, new job, new laptop, and this is still an issue. Can reproduce locally with .NET Framework 4.5 using SDK csproj format:

Unable to start program 'C:\Program Files\dotnet\sdk\6.0.300\Extensions..\TestHost\testhost.x86.exe'. Unknown Error: 0x80131c30

@gregg-miskelly
Copy link
Contributor

This is because you are trying to run tests in an x86 process, and VS Code only supports debugging 64-bit processes.

@IlIlIllIllI
Copy link

@gregg-miskelly the issue is that no where am I explicitly saying "run these tests in x86".

I'm not sure where in the process I'm doing something wrong.

  1. Install latest VSCode
  2. Install Omnisharp C# extension (ms-dotnettools.csharp)
  3. Create a .NET Framework 4.5 SDK-style Solution/Project
  4. Create some tests
  5. Hit "Debug Test"

I have all of the setting mentioned above, <Prefer32Bit>false</Prefer32Bit> & <Platform>x64</Platform>, and I have "csharp.unitTestDebuggingOptions": { "type": "clr" } in my folder's .vscode settings.json file.

Are you able to reproduce this or is everything working for you?

@gregg-miskelly
Copy link
Contributor

@RLPHRE I believe you want to configure your project to use a .runsettings file. Documentation: link

I think the .runsettings file you want should look like this:

<?xml version="1.0" encoding="utf-8"?>
<RunSettings>
  <RunConfiguration>
    <TargetPlatform>x64</TargetPlatform>
  </RunConfiguration>
</RunSettings>

@IlIlIllIllI
Copy link

@gregg-miskelly ok I'm able to get this working.

Though I think there is something actionable in this ticket. Should OmniSharp's documentation be updated to reflect that when you're using .NET Framework with tests you MUST have a .runsettings file?

In this scenario OmniSharp doesn't seem to work "out of the box" like it does for .NET Core/.NET.

Does the documentation already reflect this and I just missed it?

@gregg-miskelly
Copy link
Contributor

@RLPHRE I updated https://github.com/OmniSharp/omnisharp-vscode/wiki/Desktop-.NET-Framework and https://github.com/OmniSharp/omnisharp-vscode/wiki/How-to-run-and-debug-unit-tests with better information. If there are other spots you think the documentation should be updated, let me know. I also fixed the debugger to put up a better error message when it is asked to launch an x86 .NET Framework program.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants