Include Files in Above Directories Without Copying

[wsugarman]

While build settings like DockerComposeBaseFilePath allow relative paths that navigate to directories above the one containing the dcproj file, I cannot seem to figure out how to reference files as items (e.g. None) into my project that are located in above directories. Absolute and relative paths do not seem to work, like <None Include="..\..foo.yml" />. However, if you use the Visual Studio GUI and include an existing file into your project via the right-click menu, it simply copies the file into the project directory!

[ucheNkadiCode]

Hey @wsugarman, thanks for your feedback. We were wondering, what is your scenario for needing to use a link file here? We do recognize this as a bug. But is there any reason by the "Add" option is not viable?

[wsugarman]

@ucheNkadiCode - It was really about sharing docker-compose.yml files inside a repository, especially a mono-repo. I was trying to share a common set of services defined in a docker-compose.yml file, and I wanted to include as an item in both dcproj files. However, with the current limitation, it requires a very specific folder structure without having copies of this file in the repository (i.e. the common files need to be within the same directory sub-structure).

[NCarlsonMSFT]

@wsugarman have you tried using AdditionalComposeFilePaths?

[wsugarman]

@NCarlsonMSFT - Oh, that works for including them in the composition, but those files unfortunately don't show up in the Visual Studio file explorer, to my knowledge, without explicitly including them as items. So it may be non-obvious to other developers which files are being used in the docker-compose up command

[ucheNkadiCode]

Thanks for this suggestion @wsugarman I can see how this would be an issue. Understandably, you're just expecting files you link and share between various services in a mono-repo to be easily visible in Visual Studio.

@dbreshears I think we should do this.

[wsugarman]

Perhaps alternatively, or even additionally, the file listed as the DockerComposeBaseFilePath could be included as an MSBuild item automatically. Each of the DockerComposeBuildArguments could be too, but maybe they could be DependentUpon the DockerComposeBaseFilePath element. That would alleviate the typical boilerplate in a dcproj file, at least based on our own usage and the usage I see in examples.

[flcdrg]

I'd also like this as I want to push the .dcproj file out of the way into a subdirectory so that there's only the .sln file at the root (so you can still do dotnet build and not get an error about multiple project file being found).

[NCarlsonMSFT]

@flcdrg feel free to move the .dcproj to subdirectory. Just be sure if you move the compose files you update any relative paths in them (by default this would be each service's build context).

[flcdrg]

Yeah, I've done this but had to leave the compose files down a level. As a workaround I've linked the docker-compose.yml etc as solutions items (so at least they can be edited in VS).

[ggirard07]

@NCarlsonMSFT Tried exactly that, with updating DockerComposeBaseFilePath to point to parent folder with ../docker-compose. This results in following error:

docker-compose  -f "C:\MyRepo\docker-compose.yml" -p my-services --ansi never config
The Compose file is invalid because:
Service service-api has neither an image nor a build context specified. At least one must be provided.

Also now files included as None in project are marked as "deleted" in solution explorer. Use case here is just as @flcdrg to only have *.sln at root for dotnet related commands, while keeping docker-compose.yml also at root for discoverability purpose (especially for team members working outside of Visual Studio, like VS Code).

[NCarlsonMSFT]

@ggirard07 The None items marked as deleted is most likely b/c you didn't update the paths in the .dcproj (they would need a ..\ prepended). Note that if you fix that the items will not be visible in the VS UI as per this bug.

The compose issue appears to be specific to your compose file as I just tried moving only the project to a sub folder locally and outside the unfortunate UI bug everything worked fine. Can you verify if your service definition for service-api looks like:

  consoleapp28:
    image: ${DOCKER_REGISTRY-}consoleapp28
    build:
      context: .
      dockerfile: ConsoleApp28/Dockerfile

[ggirard07]

@NCarlsonMSFT looks like context was the issue as it was omitted from our docker-compose.yml (we were running docker compose up/down manually up until now, which never complained... maybe a difference between docker-compose and docker compose?).
But looking at compose spec, it is marked as mandatory anyway!

[EniacMlezi]

Just running into the visual bug now and would be great to see a fix for this. Any news here?

[patverb]

@EniacMlezi As of Visual Studio 17.4 linked items in the .dcproj should be shown properly. If you are having another issue, could you please open a new issue and give us the details?