-1

I have a Visual Studio 2022 solution with eight existing projects: three "ASP.NET Core Web API" projects, three "xUnit Test" projects, one "Class Library" project, and one "React App" TypeScript project. The solution uses Docker Compose for its container orchestration (so that I can include a database container, a message queue container, and an NGINX frontend container). All the existing projects work fine at this point.

I added one new "ASP.NET Core Web API" project to the solution and added some initial testing code. When I try to build the project, all the other containers continue to work, but the new container just reports:

The command could not be loaded, possibly because:
  * You intended to execute a .NET application:
      The application '' does not exist.
  * You intended to execute a .NET SDK command:
      No .NET SDKs were found.

Note the '' application name in the error message. Both the Dockerfile and the docker-compose.yml file specify proper entrypoints (dotnet project .dll) with the correct application name and the container works when launched manually; it's just when launched through the Visual Studio Docker Compose launch profile that it fails.

I found a reference to the obj/Docker/docker-compose.vs.debug.g.yml file, where I found the direct cause:

      com.microsoft.visualstudio.debuggee.arguments: " --additionalProbingPath /.nuget/packages --additionalProbingPath /.nuget/fallbackpackages  \"\""

What causes this and how can it be resolved within Visual Studio (as opposed to just editing the generated file)?

Addendum I tried modifying that obj/Docker/docker-compose.vs.debug.g.yml file; it didn't work, and as soon as i cleaned the solution in preparation for another build, that file disappeared. so it's obviously generated from other information.

Addendum 2 Based on the MSBuild properties for container projects, I also tried adding a <DockerDebuggeeArguments> tag to the project file, but that had no effect.

Addendum 3 Based on https://stackoverflow.com/a/77390842/11543023, I created a docker-compose.vs.debug.yml and debug-compose.vs.release.yml file in the same place as the docker-compose.yml file. I put the corrected com.microsoft.visualstudio.debuggee.arguments label in those files (in the proper services: hierarchy of course), and when that had no effect, I also added the rest of the labels from the generated file into the manual file. Still no change to the generated file, which still includes an empty application path.

Addendum 4 It turns out I had entered a typo when creating these override files, which caused them to not be considered valid YAML. Once I identified and corrected the typo in both files, the overrides worked and the container now starts.

So my remaining questions are:

  1. Why is Visual Studio generating an invalid com.microsoft.visualstudio.debuggee.arguments configuration in the first place?
  2. How can I tell Visual Studio to generate the correct configuration without having to use a manual override file?
3
  • Look at this answer from 2 years ago, does this help: stackoverflow.com/a/77390842/11543023 Commented Oct 30 at 15:26
  • That helps as a workaround, but I was hoping there's a more official way to do this, and an answer as to why Visual Studio is generating an invalid docker-compose.vs.debug.g.yml file in the first place Commented Oct 31 at 5:18
  • @djmonki i tried following the instructions in that answer and the generated file still includes \"\" for the application path. Thanks for the pointer in any case! Commented Oct 31 at 16:15

1 Answer 1

0

This is a partial answer to provide the work-around for anyone else who encounters this. It does not address the underlying issue of why the automatically generated docker-compose files are not correct, and thus I am not accepting my own answer. :)

Based on https://stackoverflow.com/a/77390842/11543023 and https://github.com/MicrosoftDocs/visualstudio-docs/blob/main/docs/containers/docker-compose-properties.md#overriding-visual-studios-docker-compose-configuration, creating files in the same place as the docker-compose.yml file called docker-compose.vs.debug.yml and docker-compose.vs.release.yml and populating them with the override for the invalid label in question allowed the container to run.

  1. Right-click the docker-compose project and select "Add New Item". Name the item docker-compose.vs.debug.yml and populate it with the following, replacing DOCKER_COMPOSE_SERVICE_NAME and VISUAL_STUDIO_PROJECT_NAME with the actual values, and replacing net9.0 with the framework specified when the project was created:
    services:
      DOCKER_COMPOSE_SERVICE_NAME:
        labels:
          com.microsoft.visualstudio.debuggee.arguments: " --additionalProbingPath /.nuget/packages --additionalProbingPath /.nuget/fallbackpackages  \"/app/bin/release/net9.0/VISUAL_STUDIO_PROJECT_NAME.dll\""
    
  2. Do the same for the item docker-compose.vs.release.yml but with the following simpler application path:
    services:
      DOCKER_COMPOSE_SERVICE_NAME:
        labels:
          com.microsoft.visualstudio.debuggee.arguments: " --additionalProbingPath /.nuget/packages --additionalProbingPath /.nuget/fallbackpackages  \"/app/VISUAL_STUDIO_PROJECT_NAME.dll\""
    
  3. Clean your solution, then rebuild and the container should start the application.
Sign up to request clarification or add additional context in comments.

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.