When C# Dev Kit extension is installed, while adding Dockerfiles to a .NET project, a warning is shown that the user is likely to stumble over

[bwateratmsft]

If the user selects "Yes", then our containerized debugging will not work.

Workaround: Do "Containers: Add Docker Files to Workspace..." again, but this time select "No" to the above dialog.

[bwateratmsft]

Related to #161. We need to work with the C# extension team to add a way to suppress that warning.

[WardenGnaw]

We should discuss how to get vscode-containers to work with C# Dev Kit's Dynamic Configurations.

[bwateratmsft]

@WardenGnaw do those dynamic configurations work for users who are not subscribers to C# Dev Kit? If not, then we'll have to keep doing it the way we're currently doing it--we can't lock container debugging behind a subscription when it hasn't been up to this point.

[WardenGnaw]

You could do something like this to switch between using the C# Extension configurations launch and build vs C# Dev Kit Dynamic Configurations.

https://github.com/dotnet/vscode-csharp/blob/ff6e65a14cedf55fe930f36e685564a4d5780086/src/utils/getCSharpDevKit.ts#L13

[bwateratmsft]

That makes sense. How is the build triggered, in that case? Is there an implicit VSCode task for it or do you have to run a command?

We use tasks and currently just use "dependsOn": [ "build" ] to cause the .NET build to happen before the container image build.

[WardenGnaw]

There is a generic dotnet: build task that runs a build on the solution.

However, this can be improved to make the .NET Docker scenario have a better integration with C# Dev Kit. This would be something we need to work with to improve the Aspire Scenarios with Docker.

[bwateratmsft]

Just to make sure I'm clear, is this an implicit build task (which does not exist in .vscode/tasks.json), or an explicit one (which DOES exist in .vscode/tasks.json)?

[WardenGnaw]

Yes. It's provided via a vscode.TaskProvider instead of existing in a task.json file.