High level docs - .net debug, docker file override, nuget restore tokens

[bigredmachine]

Hi,

been trying to wrap my head around how this extension works for building and debugging a .net core project.

Initially was trying to work out where the build was occurring, as I pass in a PAT token to the dockerfile, but noticed that it wasn't getting to the step where it restored the packages.
And getting warning
"[Warning] One or more build-args [****] were not consumed"
I can now see this is done outside of the container.

I've got some clues from these other discussions
#3273
#2729
with the volume mounts being set.

And looking at the code/behaviour when "enableDebugging" is set.

I'm wondering when "enableDebugging" is enabled, what's the logic used to run the initial part of the dockerfile, before then restoring to mounting the location of the application built in debug mode off disk?
Does it run to a specific stage/--target?
Before overriding the logic to use the files of the volume mounts?

I can see when "enableDebugging" isn't set, then runs all the way through the docker file.
I was then looking how to spin up the container in release mode, having built the image and restored the packages. inside the docker file.
If I try to do CTRL+F5/Run without debugging, get error
"starting container process caused: exec: "/remote_debugger/vsdbg": stat /remote_debugger/vsdbg: no such file or directory: unknown"
{ "name": "Docker .NET Core Launch", "type": "docker", "request": "launch", "preLaunchTask": "docker-run: release", "netCore": { "appProject": "${workspaceFolder}/test.csproj" } }

I can change the launch to start chrome instead, but it doesn't terminate the container on stop.
{ "name": "Launch Chrome", "request": "launch", "type": "pwa-chrome", "url": "https://localhost:8080/", "webRoot": "${workspaceFolder}", "preLaunchTask": "docker-run: release" },
Or I can just trigger the build "docker-run: release", and launch the container manually, and launch a browser from the container.

Is it supported to launch a container without debugging, built in release mode (without the debugger volume), with this extension?

In Summary, looking for some high level docs.
-Where the build occurs, where the nuget packages are restored. (what's occurring inside docker, what's occurring outside)
-how the dockerfile is overridden when "enableDebugging" is set, docs around the volume mappings for the debugger to work.
-how to launch a release build without debugging (if this extension supports this)

I think this would have helped me understand where I needed to configure the nuget package sources for the debug releases. And help demystify how the debug configuration is overriding the docker file.

[bwateratmsft]

Is it supported to launch a container without debugging, built in release mode (without the debugger volume), with this extension?

Yes--but the way is using the docker-run: release task as you mentioned, along with an "Open in Browser" (or, manually running a docker run command to do the same thing). You could set up a debug configuration that did not actually attach, and had docker-run: release as a preLaunchTask, but IMO it's simpler to just run the task directly.

For .NET apps, the docker-build: debug task only builds the first stage of the Dockerfile, named base, which (intentionally) does nothing as a container when started--it just sits there. This is so that (in conjunction with volume mapping of vsdbg, NuGet folder, and the app binaries) vsdbg can be launched directly within the container, and the app itself launched thereafter by vsdbg. In comparison on the other end of the spectrum is an attach configuration--which attaches to the app after it has started, which basically means you can't debug startup code.

As for how to configure NuGet, for debugging it should be volume mapping in your NuGet folder; for true release builds it will need the NuGet config with the PAT copied in just after the .csproj in the Dockerfile, and it will perform a nuget restore during the build process.

All of this is the same as how Visual Studio does .NET debugging in Docker. However, VS additionally supports debugging in Release mode, which does the full Docker build within the container.

@ucheNkadiCode do we have any docs or wikis for either VSCode or VS that describe this process in greater detail?

[ucheNkadiCode]

Hey @bigredmachine, do either of these two links help you?
Do either of these two links help you?

• https://code.visualstudio.com/docs/containers/debug-common
• https://code.visualstudio.com/docs/containers/reference

Other than that, @ghogen are there any other docs I may be missing dealing with the topics below

In Summary, looking for some high level docs.
-Where the build occurs, where the nuget packages are restored. (what's occurring inside docker, what's occurring outside)
-how the dockerfile is overridden when "enableDebugging" is set, docs around the volume mappings for the debugger to work.
-how to launch a release build without debugging (if this extension supports this)

[bigredmachine]

Thanks, yep been reading those docs lots of times, I think each time I look I see something extra.

That's good to know about it running just the "base" stage, and same as Visual Studio. (Maybe I was missing this understanding, as Visual Studio was already authenticated with the nuget sources)

Also worked out/explains why need the "build" task to restore the nuget packages, and the "docker-build" to depend on the "build" task, so the packages are there before it runs. Was getting odd errors with dotnet exiting when trying to start the container, when had omitted this.

I've got the answers I wanted.
Think just a question on if some extra high level docs exists/could be added?
Or if this discussion is that documentation, if so happy to mark the 1st response as the answer.

[ucheNkadiCode]

I'm glad we were able to help! I'll wait on @ghogen response, but to my knowledge these are the best docs I could find

[ghogen]

@bigredmachine @bwateratmsft @ucheNkadiCode
I agree that the best reference for the tasks and properties is here:
https://code.visualstudio.com/docs/containers/reference

Would that have answered your question, or do you think something should be added there?