question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

.NET Core Debugging using Docker: No Symbols have been loaded for this document.

See original GitHub issue

Issue Description

Anytime, when debugging a .Net Core application running inside a docker container, symbols for the project will never load. This means that breakpoints will never be hit. image

I did notice this link on the Readme.md and I am using Ubuntu 20.04 and I’m pretty sure it has OpenSSL and glibc.

Steps to Reproduce

I’d recommend the plugin vscode-solution-explorer to quickly create this test case. Otherwise, you can grab the project generated by the steps below here: test.zip

  1. Open an empty folder on VSCode.
  2. Using vscode-solution-explorer, create a new solution. I called it test (test.sln).
  3. Using vscode-solution-explorer, create a new project using the ASP.NET Core Web API template. I called it test.API (test.API/test.API.csproj).
  4. Add <DebugType>portable</DebugType> to test.API/test.API.csproj inside the only PropertyGroup node.
  5. Place a Dockerfile in the test.API project folder and give it the contents of:
# ----------------------------------------------------------
FROM mcr.microsoft.com/dotnet/core/sdk:3.1

WORKDIR /vsdbg

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
            unzip \
    && rm -rf /var/lib/apt/lists/* \
    && curl -sSL https://aka.ms/getvsdbgsh \
        | bash /dev/stdin -v latest -l /vsdbg

WORKDIR /app
COPY ./test.sln ./

ENV DOTNET_USE_POLLING_FILE_WATCHER 1
ENV DOTNET_CLI_TELEMETRY_OPTOUT 1

WORKDIR /app/test.API

# ENTRYPOINT dotnet watch run --urls=http://*:5000 <- This disallows the launch type of docker to work due to duplicate process names
ENTRYPOINT dotnet run --urls=http://*:5000

# ----------------------------------------------------------

  1. Place a docker-compose.yml in the root of the workspace and give it the contents of:
version: "3"
services:
    # Api Setup
    api:
      container_name: testapi
      build: 
        context: ./
        dockerfile: ./test.API/Dockerfile
      volumes:
        - ./test.API:/app/test.API
      environment:
        - DOTNET_USE_POLLING_FILE_WATCHER=1
        - DOTNET_ROLL_FORWARD_ON_NO_CANDIDATE_FX=2
        - DOTNET_CLI_TELEMETRY_OPTOUT=1
      ports:
          - "5000:5000"
      restart: always
      # logging:
      #   driver: none
  1. Create a launch.json for the workspace and give it the contents of:
{
   // Use IntelliSense to find out which attributes exist for C# debugging
   // Use hover for the description of the existing attributes
   // For further information visit https://github.com/OmniSharp/omnisharp-vscode/blob/master/debugger-launchjson.md
   "version": "0.2.0",
   "configurations": [
       {
           "name": "Docker .NET Core Attach (Preview)",
           "type": "docker",
           "request": "attach",
           "platform": "netCore",
           "sourceFileMap": {
               "/src": "${workspaceFolder}"
           }
       },
       {
        "name": "Test Attach",
        "type":"coreclr",
        "request":"attach",
        "processId": "${command:pickRemoteProcess}",
        "pipeTransport": {
            "pipeProgram": "docker",
            "pipeArgs": [ "exec", "-i", "testapi" ],
            "debuggerPath": "/vsdbg/vsdbg",
            "pipeCwd": "${workspaceRoot}/test.API/",
            "quoteArgs": false
        },
        "sourceFileMap": {
            "/app/test.API": "${workspaceRoot}/test.API",
        }
    },
        
    ]
}
  1. Set a breakpoint on the Get() method of the default WeatherForecastController.cs and launch either config.

Expected Behavior

The breakpoint inside WeatherForecastController.cs would continue to stay red and the VSCode debugger would pause on it once one goes to localhost:5000/WeatherForecast.

Actual Behavior

The breakpoint turns into a hollow grey circle and when hovered it states “No symbols have been loaded for this document.” When going to localhost:5000/WeatherForecast, the breakpoint is skipped.

Logs

OmniSharp log

Starting OmniSharp server at 9/3/2020, 12:31:21 PM Target: /vso/source/test/test.sln

OmniSharp server started. Path: /home/marcus/.vscode/extensions/ms-dotnettools.csharp-1.23.2/.omnisharp/1.37.1/run PID: 968691

    Starting OmniSharp on ubuntu 20.4 (x64)
    DotNetPath set to dotnet
    Located 1 MSBuild instance(s)
        1: StandAlone 16.8.0 - "/home/marcus/.vscode/extensions/ms-dotnettools.csharp-1.23.2/.omnisharp/1.37.1/omnisharp/.msbuild/Current/Bin"
    MSBUILD_EXE_PATH environment variable set to '/home/marcus/.vscode/extensions/ms-dotnettools.csharp-1.23.2/.omnisharp/1.37.1/omnisharp/.msbuild/Current/Bin/MSBuild.exe'
    Registered MSBuild instance: StandAlone 16.8.0 - "/home/marcus/.vscode/extensions/ms-dotnettools.csharp-1.23.2/.omnisharp/1.37.1/omnisharp/.msbuild/Current/Bin"
        CscToolExe = csc.exe
        MSBuildToolsPath = /home/marcus/.vscode/extensions/ms-dotnettools.csharp-1.23.2/.omnisharp/1.37.1/omnisharp/.msbuild/Current/Bin
        CscToolPath = /home/marcus/.vscode/extensions/ms-dotnettools.csharp-1.23.2/.omnisharp/1.37.1/omnisharp/.msbuild/Current/Bin/Roslyn
        BypassFrameworkInstallChecks = true
        MSBuildExtensionsPath = /home/marcus/.vscode/extensions/ms-dotnettools.csharp-1.23.2/.omnisharp/1.37.1/omnisharp/.msbuild
    Detecting Cake files in '/vso/source/test'.
    Could not find any Cake files
    Detecting projects in '/vso/source/test/test.sln'.
    Queue project update for '/vso/source/test/test.API/test.API.csproj'
    Detecting CSX files in '/vso/source/test'.
    Could not find any CSX files
    Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.CSharpFormattingWorkspaceOptionsProvider, Order: 0
    Loading project: /vso/source/test/test.API/test.API.csproj
    Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.Completion.CompletionOptionsProvider, Order: 0
    Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.RenameWorkspaceOptionsProvider, Order: 100
    Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.ImplementTypeWorkspaceOptionsProvider, Order: 110
    Invoking Workspace Options Provider: OmniSharp.Roslyn.CSharp.Services.BlockStructureWorkspaceOptionsProvider, Order: 140
    Configuration finished.
    Omnisharp server running using Stdio at location '/vso/source/test' on host 966045.
    Could not read state file "obj/Debug/netcoreapp3.1/test.API.csprojAssemblyReference.cache". Access to the path "/vso/source/test/test.API/obj/Debug/netcoreapp3.1/test.API.csprojAssemblyReference.cache" is denied.
    Could not write state file "obj/Debug/netcoreapp3.1/test.API.csprojAssemblyReference.cache". Access to the path '/vso/source/test/test.API/obj/Debug/netcoreapp3.1/test.API.csprojAssemblyReference.cache' is denied.
    Could not write lines to file "obj/Debug/netcoreapp3.1/.NETCoreApp,Version=v3.1.AssemblyAttributes.cs". Access to the path "/vso/source/test/test.API/obj/Debug/netcoreapp3.1/.NETCoreApp,Version=v3.1.AssemblyAttributes.cs" is denied.
    The "WriteLinesToFile" task returned false but did not log an error.
    Successfully loaded project file '/vso/source/test/test.API/test.API.csproj'.

/vso/source/test/test.API/test.API.csproj /home/marcus/.vscode/extensions/ms-dotnettools.csharp-1.23.2/.omnisharp/1.37.1/omnisharp/.msbuild/Current/Bin/Microsoft.Common.CurrentVersion.targets(2121,5): Error: Could not read state file “obj/Debug/netcoreapp3.1/test.API.csprojAssemblyReference.cache”. Access to the path “/vso/source/test/test.API/obj/Debug/netcoreapp3.1/test.API.csprojAssemblyReference.cache” is denied. /home/marcus/.vscode/extensions/ms-dotnettools.csharp-1.23.2/.omnisharp/1.37.1/omnisharp/.msbuild/Current/Bin/Microsoft.Common.CurrentVersion.targets(2121,5): Error: Could not write state file “obj/Debug/netcoreapp3.1/test.API.csprojAssemblyReference.cache”. Access to the path ‘/vso/source/test/test.API/obj/Debug/netcoreapp3.1/test.API.csprojAssemblyReference.cache’ is denied. /home/marcus/.vscode/extensions/ms-dotnettools.csharp-1.23.2/.omnisharp/1.37.1/omnisharp/.msbuild/Current/Bin/Microsoft.Common.CurrentVersion.targets(3350,5): Error: Could not write lines to file “obj/Debug/netcoreapp3.1/.NETCoreApp,Version=v3.1.AssemblyAttributes.cs”. Access to the path “/vso/source/test/test.API/obj/Debug/netcoreapp3.1/.NETCoreApp,Version=v3.1.AssemblyAttributes.cs” is denied. /home/marcus/.vscode/extensions/ms-dotnettools.csharp-1.23.2/.omnisharp/1.37.1/omnisharp/.msbuild/Current/Bin/Microsoft.Common.CurrentVersion.targets(3350,5): Error: The “WriteLinesToFile” task returned false but did not log an error.

    Adding project '/vso/source/test/test.API/test.API.csproj'
    Update project: test.API
    Queue project update for '/vso/source/test/test.API/test.API.csproj'
    Loading project: /vso/source/test/test.API/test.API.csproj
    Could not read state file "obj/Debug/netcoreapp3.1/test.API.csprojAssemblyReference.cache". Access to the path "/vso/source/test/test.API/obj/Debug/netcoreapp3.1/test.API.csprojAssemblyReference.cache" is denied.
    Could not write lines to file "obj/Debug/netcoreapp3.1/.NETCoreApp,Version=v3.1.AssemblyAttributes.cs". Access to the path "/vso/source/test/test.API/obj/Debug/netcoreapp3.1/.NETCoreApp,Version=v3.1.AssemblyAttributes.cs" is denied.
    The "WriteLinesToFile" task returned false but did not log an error.
    Successfully loaded project file '/vso/source/test/test.API/test.API.csproj'.

/vso/source/test/test.API/test.API.csproj /home/marcus/.vscode/extensions/ms-dotnettools.csharp-1.23.2/.omnisharp/1.37.1/omnisharp/.msbuild/Current/Bin/Microsoft.Common.CurrentVersion.targets(2121,5): Error: Could not read state file “obj/Debug/netcoreapp3.1/test.API.csprojAssemblyReference.cache”. Access to the path “/vso/source/test/test.API/obj/Debug/netcoreapp3.1/test.API.csprojAssemblyReference.cache” is denied. /home/marcus/.vscode/extensions/ms-dotnettools.csharp-1.23.2/.omnisharp/1.37.1/omnisharp/.msbuild/Current/Bin/Microsoft.Common.CurrentVersion.targets(3350,5): Error: Could not write lines to file “obj/Debug/netcoreapp3.1/.NETCoreApp,Version=v3.1.AssemblyAttributes.cs”. Access to the path “/vso/source/test/test.API/obj/Debug/netcoreapp3.1/.NETCoreApp,Version=v3.1.AssemblyAttributes.cs” is denied. /home/marcus/.vscode/extensions/ms-dotnettools.csharp-1.23.2/.omnisharp/1.37.1/omnisharp/.msbuild/Current/Bin/Microsoft.Common.CurrentVersion.targets(3350,5): Error: The “WriteLinesToFile” task returned false but did not log an error.

    Update project: test.API

C# log

Installing C# dependencies... Platform: linux, x86_64, name=ubuntu, version=20.04

Downloading package ‘OmniSharp for Linux (x64)’ (47203 KB)… Done! Validating download… Integrity Check succeeded. Installing package ‘OmniSharp for Linux (x64)’

Downloading package ‘.NET Core Debugger (linux / x64)’ (54671 KB)… Done! Validating download… Integrity Check succeeded. Installing package ‘.NET Core Debugger (linux / x64)’

Downloading package ‘Razor Language Server (Linux / x64)’ (52580 KB)… Done! Installing package ‘Razor Language Server (Linux / x64)’

Finished

Environment information

VSCode version: 1.48.2 C# Extension: 1.23.2

Mono Information OmniSharp using built-in mono
Dotnet Information .NET Core SDK (reflecting any global.json): Version: 3.1.401 Commit: 39d17847db

Runtime Environment: OS Name: ubuntu OS Version: 20.04 OS Platform: Linux RID: ubuntu.20.04-x64 Base Path: /usr/share/dotnet/sdk/3.1.401/

Host (useful for support): Version: 3.1.7 Commit: fcfdef8d6b

.NET Core SDKs installed: 2.1.809 [/usr/share/dotnet/sdk] 3.1.401 [/usr/share/dotnet/sdk]

.NET Core runtimes installed: Microsoft.AspNetCore.All 2.1.21 [/usr/share/dotnet/shared/Microsoft.AspNetCore.All] Microsoft.AspNetCore.App 2.1.21 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.AspNetCore.App 3.1.7 [/usr/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 2.1.21 [/usr/share/dotnet/shared/Microsoft.NETCore.App] Microsoft.NETCore.App 3.1.7 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

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

Visual Studio Code Extensions
Extension Author Version
azure-account ms-vscode 0.9.2
csharp ms-dotnettools 1.23.2
debugger-for-chrome msjsdiag 4.12.10
gitlens eamodio 10.2.2
material-icon-theme PKief 4.2.0
remote-containers ms-vscode-remote 0.134.1
vscode-docker ms-azuretools 1.5.0
vscode-firefox-debug firefox-devtools 2.9.1
vscode-solution-explorer fernandoescolar 0.3.11
vsliveshare ms-vsliveshare 1.0.2740
vsonline ms-vsonline 1.0.2739

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Comments:6 (3 by maintainers)

github_iconTop GitHub Comments

1reaction
gregg-miskellycommented, Sep 4, 2020

Did you pick the dotnet process? If so, I don’t think that would be what you would want. Try the test.API process.

0reactions
MarcusOycommented, Sep 4, 2020

So I know what I’ve been doing wrong. Initially, I’ve been testing each and every process that showed up to see which process would actually load up the module properly, however after a while, I’ve been implementing multiple fixes from the internet surrounding this issue and have just been either testing the Docker preview config or just one of the process that relate to dotnet or the project in the entrypoint, not every process. So yes, with the abundance of fixes I’ve implemented, at least one of them had fixed a fundamental issue with my setup but the rest of the fixes did nothing as there was no further problem to fix other than my incompetence of selecting the right process since I was treating them as all the same. On top of this, my entrypoint used to contain the watch argument, which makes the process list even more convoluted with file pollers.

One conclusion I could make is that the current Docker preview for .NET may be broken as it is not selecting the right process. I may need to file an issue with their repo after some more investigation.

Thanks @gregg-miskelly for putting up with me!

Read more comments on GitHub >

github_iconTop Results From Across the Web

c# - Docker container - no symbols have been loaded for this ...
I already have my Visual Studio Code attached to my running container. It's a .Net Core WepApi. This is the link for the...
Read more >
docker - Why won't Visual Studio load symbols when attaching ...
Mouse over my breakpoint and see "The breakpoint will not currently be hit. No symbols have been loaded for this document." What else...
Read more >
Attach to vsdbg in docker container failing to load any symbols
Attached debugger using Omnisharp launch.js configuration; No symbols loaded -- Cannot debug -- cannot use breakpoints. A generic base docker ...
Read more >
"This breakpoint will currently not be hit. No symbols have ...
No symbols have been loaded for this document." What does this mean? I am debugging a C# Wpf program. It has been progressing...
Read more >
"The breakpoint will not currently be hit. No symbols have ...
If you are getting the "no symbols have been loaded" message, can you go to Modules window and find the symbol load information...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found