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

Can't launch coreclr docker debugger #742

Closed
gregg-miskelly opened this issue Jan 15, 2019 · 8 comments
Closed

Can't launch coreclr docker debugger #742

gregg-miskelly opened this issue Jan 15, 2019 · 8 comments
Assignees
Labels
Milestone

Comments

@gregg-miskelly
Copy link
Member

From @mbialecka on January 15, 2019 3:23

Environment data

dotnet --info output:
.NET Core SDK (reflecting any global.json):
Version: 2.1.403
Commit: 04e15494b6

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

Host (useful for support):
Version: 2.1.5
Commit: 290303f510

.NET Core SDKs installed:
2.1.4 [C:\Program Files\dotnet\sdk]
2.1.104 [C:\Program Files\dotnet\sdk]
2.1.201 [C:\Program Files\dotnet\sdk]
2.1.202 [C:\Program Files\dotnet\sdk]
2.1.400 [C:\Program Files\dotnet\sdk]
2.1.401 [C:\Program Files\dotnet\sdk]
2.1.403 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.All 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.AspNetCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.3-servicing-26724-03 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

VS Code version:
Version: 1.30.2 (user setup)
Commit: 61122f88f0bf01e2ac16bdb9e1bc4571755f5bd8
Date: 2019-01-07T22:53:57.820Z
Electron: 2.0.12
Chrome: 61.0.3163.100
Node.js: 8.9.3
V8: 6.1.534.41
OS: Windows_NT ia32 10.0.18305

C# Extension version: 1.17.1

Steps to reproduce

I'm trying to launch debugger for a dockerized app. I'm using modified configuration "Docker: Launch .NET Core (Preview)" with custom Dockerfile, project location, and env vars:

        {
            "name": "Docker: Launch .NET Core (Preview)",
            "type": "docker-coreclr",
            "request": "launch",
            "preLaunchTask": "build",
            "appProject": "${workspaceFolder}/subdir",
            "dockerBuild": {
                "dockerfile": "Dockerfile.amd64.debug"
            },
            "dockerRun": {
                "env": {
                    "myvar1": "value1",
                    "myvar2": "value2"
                }
            }
        },

Actual behavior

I get the following error:

Action: debugCoreClr
Error type: ENOENT
Error Message: ENOENT: no such file or directory, unlink 'C:\Users\username\AppData\Local\Temp\temp_1547521110923_29680_8.tmp'

Version: 0.5.1
OS: win32

Copied from original issue: dotnet/vscode-csharp#2792

@gregg-miskelly gregg-miskelly changed the title Can't launch debugger for docker Can't launch coreclr docker debugger Jan 15, 2019
@philliphoff
Copy link
Member

@mbialecka Can you provide a little more context (e.g. where is the project file in this scenario, where is the Dockerfile relative to the project file and/or the workspace folder, etc.)? Can you debug a "basic" .NET Core project (e.g. dotnet new web ...) successfully, or is it just this one scenario that doesn't work?

@mbialecka
Copy link

This is the folder structure:

app
 |--dependency1
 |--dependency2
 |--mainProject (aka "subdir")
 |    |--project.csproj
 |--Dockerfile

When I created an empty web app with a custom Dockerfile, it worked. When I added a subdirectory with a console project and changed Dockerfile and launch configurations to use it, I get a similar error:

ENOENT: no such file or directory, unlink 'C:\Users\username\AppData\Local\Temp\temp_1547597025656_23348_10.tmp'

Simple repro setup:

emptywebapp
 |--subdir
 |    |--Program.cs
 |    |--subdir.csproj
 |--Dockerfile.sub.debug

Dockerfile.sub.debug:

FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
# install debuger
RUN apt-get update && \
    apt-get install -y --no-install-recommends unzip procps && \
    curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v latest -l ~/vsdbg && \
    rm -rf /var/lib/apt/lists/*

WORKDIR /app
EXPOSE 80

FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ["subdir/subdir.csproj", "./"]
RUN dotnet restore "./subdir.csproj"
COPY subdir .
WORKDIR "/src/."
RUN dotnet build "subdir.csproj" -c Release -o /app

FROM build AS publish
RUN dotnet publish "subdir.csproj" -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "subdir.dll"]

launch.json:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Docker: Launch SUB",
            "type": "docker-coreclr",
            "request": "launch",
            "preLaunchTask": "build",
            "appProject": "${workspace}/subdir",
            "dockerBuild": {
                "dockerfile": "${workspaceFolder}/Dockerfile.sub.debug"
            },
            "dockerRun": {}
        }
    ]
}

@philliphoff
Copy link
Member

Can you try the following:

{
            "name": "Docker: Launch SUB",
            "type": "docker-coreclr",
            "request": "launch",
            "preLaunchTask": "build",
            "appFolder": "${workspaceFolder}/subdir",
            "dockerBuild": {
                "dockerfile": "${workspaceFolder}/Dockerfile.sub.debug"
            },
            "dockerRun": {}
}

or

{
            "name": "Docker: Launch SUB",
            "type": "docker-coreclr",
            "request": "launch",
            "preLaunchTask": "build",
            "appProject": "${workspaceFolder}/subdir/subdir.csproj",
            "dockerBuild": {
                "dockerfile": "${workspaceFolder}/Dockerfile.sub.debug"
            },
            "dockerRun": {}
}

The debugging logic expects the appProject property to point to an actual .csproj file, whereas the appFolder property can point to just the parent folder of the .csproj. In either case, ${workspace} isn't a supported VS Code variable (where I think you intended ${workspaceFolder}).

In any case, I agree that the error returned is not intuitive; I'll add an item to the list to better detect/report incorrect options.

@mbialecka
Copy link

Thanks @philliphoff for pointing this out. I had a problem with not specifying the csproj filename. I got confused by the help article https://github.com/Microsoft/vscode-docker#application-customizations. Somehow I thought that it will find the csproj in the folder I specified. Now it seems obvious that I should have used appFolder if I wanted to specify folder path only.

Although I no longer get the error that started the thread, I still don't have the debugger up and running... I see this output in VS Code Debug Console:

Starting: "docker" exec -i db56dce01fffd1810c94a5a8e22245c505f1396d8a7ff071e2a56206bc8bab91 /remote_debugger/vsdbg --interpreter=vscode
-------------------------------------------------------------------
You may only use the Microsoft .NET Core Debugger (vsdbg) with
Visual Studio Code, Visual Studio or Visual Studio for Mac software
to help you develop and test your applications.
-------------------------------------------------------------------
realpath(): Invalid argument
realpath(): Invalid argument
realpath(): Invalid argument
realpath(): Invalid argument
Error:
  An assembly specified in the application dependencies manifest (app.deps.json) was not found:
    package: 'Microsoft.Extensions.Configuration.Abstractions', version: '2.1.1'
    path: 'lib/netstandard2.0/Microsoft.Extensions.Configuration.Abstractions.dll'
The target process exited without raising a CoreCLR started event. Ensure that the target process is configured to use .NET Core. This may be expected if the target process did not run on .NET Core.
The program '[19] dotnet' has exited with code 140 (0x8c).

I don't understand where it's coming from. My custom Dockerfile builds and publishes the binaries, and when I manually build the image, it has all the dependencies in the app folder and starts up fine. Also I'm pretty sure I use only netcoreapp2.1, not netstandard2.0.

I have an attach configuration that works fine with container built from the Dockerfile I'm trying to use for the launch configuration.

@philliphoff
Copy link
Member

@mbialecka Hmmm, my first suspicion would be that the dependencies didn't make it into the container. Debugging (launch) .NET Core in Docker in VS works a little differently than the attach scenario; we only build the base Docker target and then volume mount in the debugger bits and application bits (which are built on the host). Are the Microsoft.Extensions.Configuration.Abstractions.dll and related assemblies in the build output (e.g. bin/Debug) folder of the application? (I.e. the standard build output, not the publish output.)

We can try to sort it out via Teams/LiveShare, too, if you like.

@philliphoff
Copy link
Member

Leaving myself a note: it may be useful to add a switch to optionally disable auto-killing of containers after debugging. If the debugging dies prematurely, then we can't go spelunking into the container as it's already been cleaned up.

@mbialecka
Copy link

For posteriority: I had to add the following to my csproj:

  <PropertyGroup>
    <CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
  </PropertyGroup>

Now it works. Can be closed.

@philliphoff
Copy link
Member

@mbialecka Great! Thanks!

@vscodebot vscodebot bot locked and limited conversation to collaborators Mar 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

5 participants