Include better defaults for .NET containers about vscode-dev-containers HOT 12 CLOSED

@JohnGalt1717 Can you be specific with the problem you are running into? Ports do not need to be opened for the debugger to attach. Once you're connected to a container, launch.json is setup as it is normally, which is why there is nothing specific on that.

There are also test projects for each that do work with debugging, so it would be good to understand what dependencies you feel are missing.

from vscode-dev-containers.

Create a .NET Core 2.2 web app, open it with Remote Containers. (in the devcontainer.json I also opened the port)
Create the default launch point for .net Core web app in the launch.json file using vs code's tools, and just fill in the dll naming and version info.

Hit F5.

Build will occur and you can see it running in the build terminal. (Looks like it's running remotely)
But the debugger just sits spinning waiting for a connection and never actually executes the built files.

Here's an example that works perfectly locally but doesn't work in a remote container:

		{
			"name": "Api (Local)",
			"type": "coreclr",
			"request": "launch",
			"preLaunchTask": "build",
			// If you have changed target frameworks, make sure to update the program path.
			"program": "${workspaceFolder}/CADLearning.Api/bin/Debug/netcoreapp2.2/CADLearning.Api.dll",
			"args": [],
			"cwd": "${workspaceFolder}/CADLearning.Api",
			"stopAtEntry": false,
			"launchBrowser": {
				"enabled": false
			},
			"internalConsoleOptions": "neverOpen",
			"externalConsole": true,
			"env": {
				"ASPNETCORE_ENVIRONMENT": "Development"
			},
			"sourceFileMap": {
				"/Views": "${workspaceFolder}/CADLearning.Api/Views"
			}
		},

task.json:

{
			"label": "build",
			"command": "dotnet",
			"type": "process",
			"args": [
				"build",
				"${workspaceFolder}/CADLearning.Api/CADLearning.Api.csproj",
				"-c",
				"Debug"
			],
			"problemMatcher": "$msCompile",
			"group": {
				"kind": "build",
				"isDefault": true
			}
		},

Also note that in vs code the launch options don't change until you tell it to rebuild the container. It should be live updates just like it is if you're working locally.

from vscode-dev-containers.

@JohnGalt1717 launch.json changes do not require a container rebuild. These purely tell the debugger how to attach.

The problem is you are using externalConsole which is not supported. Are you using VS Code stable or insiders?

We did get a report that externalConsole caused a hang instead of an error, so you might be hitting this: microsoft/vscode-remote-release#723

from vscode-dev-containers.

There was no error reported anywhere, but changing the setting made it work. This should be in the documentation so that people don't run into it and not know what's going on.

I'm on the stable version. And if I for example add a launch.json profile or change the name of one, the drop down for debug in the debug panel does not update with the updated names or new options like it does if you edit the launch.json locally. The only way I can get the list to update is to rebuild the container.

from vscode-dev-containers.

BTW, there are a ton of other gotchas that need to be documented with all of this stuff too:

1. .net core self-signed certs and trusting them from the remote instance. (this applies to anything) Perhaps a better way to share it between instances? (Just exporting the cert in chrome and then importing it into the personal cert store in windows doesn't work)
2. Server authentication using .net is the recommended method for Azure Keyvault as an example but this requires that you install the az login into the container. (got this working)
3. Nodejs in .net dev container.

etc.

And that's just what I've run into so far.

from vscode-dev-containers.

@JohnGalt1717

There was no error reported anywhere, but changing the setting made it work

Got it, yes, there should be an error appearing here. This is bug microsoft/vscode-remote-release#723.

.net core self-signed certs and trusting them from the remote instance. (this applies to anything) Perhaps a better way to share it between instances? (Just exporting the cert in chrome and then importing it into the personal cert store in windows doesn't work)

This is something the .NET (and Omnisharp) team is aware of and I know are looking into. One of the fixes being put in place this iteration is microsoft/vscode-remote-release#1115, which allows auto-forwarding of applications running on 0.0.0.0 to help with defaults. We have not heard about this specific problem outside of .NET yet, but that may simply be a byproduct of how this is managed in other communities.

Server authentication using .net is the recommended method for Azure Keyvault as an example but this requires that you install the az login into the container. (got this working)

Nodejs in .net dev container.

These containers are intended to be starting points. The goal is that the installation steps are built out once for a repository, then persisted with the repository for repeatability. We could certainly add more to the .NET base containers like Node.js, but there is a lot of variety in what people need to do by default.

I can find the right person from the .NET team to loop into the discussion. I could see Node.js making sense given its prevalence in web development. The Azure CLI I am less confident in since that is Azure specific, but not opposed. Either way, they could also get added in either commented out, or with a note to remove if not needed.

from vscode-dev-containers.

@Chuxel Thanks for the above. Even if it's not added direclty to the image, then the documentation needs to be added with these common scenarios. Getting Az cli installed was not trivial as an example. Same with the gotchas. While everyone is working on stuff to make this work better, documentation would go a long way to making sure that people us this and don't get frustrated.

from vscode-dev-containers.

//cc: @richlander

from vscode-dev-containers.

@richlander I put together a PR to address the requests above. See if you think it covers the variations well enough and whether installing Node.js by default makes sense given its use in ASP.NET scenarios.

from vscode-dev-containers.

This looks good.

The only thing that it doesn't handle is the self-signed certs.

In a perfect world the local version would be exported into a file and then imported and used by .net core within the docker environment automatically.

Then it would be transparent for devs.

from vscode-dev-containers.

@JohnGalt1717 I just created a forked issue (#141) for the self-signed certs topic since the PR I mentioned is now merged.

Thanks for the feedback!

from vscode-dev-containers.

Thanks! I'm watching it!

from vscode-dev-containers.