Skip to content

Debug with docker containers #185

Closed
Closed

Description

@galvesribeiro

What is the proper way to install the debugger on a dotnet image and get it debugging from VSCode?

Currently there are multiple (messy) ways to work with old project.json and containers like for example, that bunch of scripts generated by yo docker.

Is there any guidance on how to create a debug container for .net apps?

Thank you

Activity

  1. MichaelSimons commented on Jan 27, 2017

    @MichaelSimons
    Member

    @galvesribeiro, Good question. The yo docker experience is definitely out of date. We currently don't have any guidance on this. Let me dig around a little and see what I can come up with.

  2. galvesribeiro commented on Jan 27, 2017

    @galvesribeiro
    MemberAuthor

    Thanks @MichaelSimons I appreciate that. I'm struggling to get it to work here. Even if I use VS2017 which has that Add Docker Support function, it works, but there is no docs on how that works whatsoever so I can't try reproduce it on VSCode. Looking forward to hear from you, thanks!

  3. MichaelSimons commented on Jan 27, 2017

    @MichaelSimons
    Member

    For my own exercise, I went through the yo docker experience. Even though it was out of date, I was able to get it working with a few tweaks.

    1. mkdir DockerDebugApp
    2. cd DockerDebugApp
    3. dotnet new -t Console1.1
    4. yo docker (used defaults)
    5. Ignore project.json file does not exist error
    6. Open DockerDebugAdd in VSCode
    7. add the following to the csproj
            <ItemGroup>
        <None Update="Dockerfile">
          <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
        </None>
        <None Update="Dockerfile.Debug">
          <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
        </None>
        <None Update="docker-compose.yml">
          <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
        </None>
        <None Update="docker-compose.debug.yml">
          <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
        </None>
      </ItemGroup>
      
    8. Update the two Dockerfiles to reference the appropriate base images
      a. microsoft/dotnet:1.1-sdk-msbuild
      b. microsoft/dotnet:1.1-runtime
    9. Update the Dockerfile.debug to install unzip before the GetClrDbg logic
          RUN apt-get update \
          && apt-get install -y --no-install-recommends \
              unzip \
          && rm -rf /var/lib/apt/lists/*
      
    10. Set the $framework variables of the dockerTask script to match your csproj
      a. netcoreapp1.1
    11. dotnet restore -r debian.8-x64
    12. Build
    13. Set breakpoint in program
    14. F5
  4. galvesribeiro commented on Jan 27, 2017

    @galvesribeiro
    MemberAuthor

    Was about to ping you... I did similar thing and it work :)

    However, that is not close to what we have with VS2017, where you can run/debug multiple projects using the solution-level docker-compose files...

  5. MichaelSimons commented on Jan 31, 2017

    @MichaelSimons
    Member

    I moved this to microsoft/generator-docker#130 since the underlying issue is not specific to the Docker image rather it is with the broken yo docker experience.

  6. dasMulli commented on Jan 31, 2017

    @dasMulli
    Contributor

    @MichaelSimons most of the fuss is about downloading clrdbg into the containers. Does it make sense to create a public image that already includes the correct debugger? (e.g. microsoft/dotnet:1.1-sdk-msbuild-debug).

  7. galvesribeiro commented on Jan 31, 2017

    @galvesribeiro
    MemberAuthor

    @dasMulli if you look at simple apps with a single container yes, people don't know that the SDK doesn't come with the debugger. However, when you have multiple containers (i.e. docker-compose based projects) the problem goes far from just that. Look at the new issue @MichaelSimons just created.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions