Closed VeselovAndrey closed 1 year ago
This issue is caused by a bug in underlying Common Project System (CPS) API used in Docker Tools. Opened an internal bug against CPS. Will update once the CPS bug is fixed.
The fix will be in 17.4 Preview 1.
Is this something that is implemented in VS for Mac? and is it supposed to work there or be broken?
I'm asking because I'm looking for guidance authoring Dockerfiles for projects with central package management.
Thanks.
From some quick testing it appears to work with a couple of caveats. I had an issue where I had to unload/reload the project the first time I added a PackageReference to a project that references a package from Directory.Pacakges.props for VS for Mac to be able to build a project
Another issue is that when building a docker project in Release mode, the dockerfile that we scaffolded does not copy the Directory.Packages.props file. If you manually add the line COPY Directory.Packages.props .
right before the Run dotnet restore <project>.csproj
line it should work.
I am getting the following error with the central package management: /root/.nuget/packages/microsoft.visualstudio.azure.containers.tools.targets/1.18.1/build/Container.targets(97,5): error : Docker is not installed or is not in the current PATH.
Our host app references the microsoft.visualstudio.azure.containers.tools.targets nuget in order to get the docker GUI in Visual Studio (the Build Docker Image menu command). We are using the "container fast mode" (https://aka.ms/containerfastmode) and our dockerfile includes:
... RUN dotnet build "MyApp.csproj" -c Release -o /app/build ...
Apparently including microsoft.visualstudio.azure.containers.tools.targets includes also microsoft.visualstudio.azure.containers.tools.targets/1.18.1/build/Container.targets which contains the ContainerVerifyDockerInstallation target. This target attempts to execute "docker --version" inside the docker container where the build is running, which of course fails since there is no "docker inside docker" and the entire build fails as a result.
One solution would be to not reference the nuget, but then it'll be a lot less convenient to work with. Why does "dotnet build" run this target? Is it intended?
Currently, I had to include this indo my dockerfile as a workaround:
RUN rm -r "/root/.nuget/packages/microsoft.visualstudio.azure.containers.tools.targets/1.18.1/build/"
This deletes all the targets/props files from this nuget and lets the build succeed.
@jimm98y , Since the original issue of not working with central package managment has now been resolved in 17.6, I'm going to close this issue. Looking at our targets what you are describing shouldn't happen by default. Can you please open a new issue with an sample solution and we can look into.
Create default ASP.NET Core Web API project
Run (debug) app in Docker - Succeed
Switch to use central package management (re-start Visual Studio)
Run (debug) app in Docker - Failed with message
The NuGet package 'Microsoft.VisualStudio.Azure.Containers.Tools.Targets' is required by Visual Studio Tools for Containers. Should it be installed now?
Clicking "YES" does nothing and debug session fails.