sdk: VS2017 Docker-Compose Project breaks build on command line

@DamianEdwards @shanselman Sorry to include you two on this issue but we haven’t received feedback on this issue for some time now and we are looking for help. More and more people are coming to this issue as well as the closed PR that would have fixed it.

Reopening this issue since it hasn’t been resolved yet. I think not being able to build a solution that contains a dcproj without hacks is a significant blocker.

@dazhao-msft - any updates on https://github.com/dotnet/cli/pull/6180

@livarcocc I propose that this issue be re-opened since there is no fix currently in place except for manually copying SDK files.

After so many years of generating frustration it seems that Visual Studio still takes priority to having a working/proper CLI. It seems that having a strong CLI that always works is much more useful than having a slow running IDE that either way should not be installed on the CI machine. But for the sake of having this single IDE more click-friendly you are willing to break something so foundational as platform independence.

I was looking through the eShopOnContainers. I was so happy to have dotnet, docker and Mac working together. I wanted to start with the WebMonolithic solution. But I cannot even dotnet restore.

You’ve put a lot of effort in making dotnet core a good platform for the current times. Is it a bad idea to make sure that whatever feature is added it is working first on the CLI and then see what can be done for VS?

The fix (copying VS Docker SDK to dotnet sdk) does not seem to work for 2.0.0-preview2. I get this error: C:\Program Files\dotnet\sdk\2.0.0-preview2-006497\Sdks\Microsoft.Docker.Sdk\build\Microsoft.VisualStudio.Docker.Compose.targets(80,45): error MSB4022: The result “” of evaluating the value “$(DockerBuildTasksAssembly)” of the “AssemblyFile” attribute in element <UsingTask> is not valid. [C:\repos\WebApplication1\docker-compose.dcproj]

Any solutions for this?

Just to summarize the steps I had to perform to make it work on Windows and Linux (Ubuntu):

1. Copy the Microsoft.Docker.Sdk folder from C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Sdks (Only the Sdk subfolder. Do not copy build and tools subfolders).
2. Then paste it on C:\Program Files\dotnet\sdk\2.0.0\Sdks on Windows or /usr/share/dotnet/sdk/2.0.0./Sdks on Linux (Ubuntu) Then dotnet build SolutionName.sln will work fine.

These steps will fix both errors:

• error MSB4236: The SDK ‘Microsoft.Docker.Sdk’ specified could not be found.
• error MSB4022: The result “” of evaluating the value “$(DockerBuildTasksAssembly)” of the “AssemblyFile” attribute in element is not valid.

This is still broken after .NET Core 2.0 release. Can anyone comment on the state of affairs?

I’ve tried to do a dotnet build ./MySolution.sln on a solution which contained a project with enabled Docker (linux) support.

dotnet build .\Cluster.sln
D:\Checkout\netcore20ACS\cluster-seed-svc\docker-compose.dcproj : error MSB4236: The SDK 'Microsoft.Docker.Sdk' specified could not be found.
D:\Checkout\netcore20ACS\cluster-seed-svc\docker-compose.dcproj : warning NU1503: Skipping restore for project 'D:\Checkout\netcore20ACS\cluster-seed-svc\docker-compose.dcproj'. The project file may be invalid or missing targets required for restore. [D:\Checkout\netcore20ACS\cluster-seed-svc\Cluster.sln]
Microsoft (R) Build Engine version 15.3.409.57025 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

D:\Checkout\netcore20ACS\cluster-seed-svc\docker-compose.dcproj : error MSB4236: The SDK 'Microsoft.Docker.Sdk' specified could not be found.
  Cluster.InternalApi -> D:\Checkout\netcore20ACS\cluster-seed-svc\src\Cluster.InternalApi\bin\Debug\netcoreapp2.0\Cluster.InternalApi.dll

Build FAILED.

D:\Checkout\netcore20ACS\cluster-seed-svc\docker-compose.dcproj : error MSB4236: The SDK 'Microsoft.Docker.Sdk' specified could not be found.
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:00:04.44

@dmitry606 It looks like that you copied the Microsoft.Docker.Sdk folder from VS 15.3 Preview, under which there are 3 folders: build, Sdk, tools. Please delete build and tools and only keep Sdk.

Manually copying the files also worked for me, but I also suggest to reopen this issue, as it is indeed an issue until the files are distributed with the CLI.

@jgreene In the short term, you just need to copy the appropriate files from the VS 2017 installation (C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Sdks\Microsoft.Docker.Sdk) to where dotnet expects to find them (C:\Program Files\dotnet\sdk\1.0.1\Sdks\Microsoft.Docker.Sdk on Windows, /opt/dotnet/sdk/1.0.1/Sdks/Microsoft.Docker.Sdk on *nix). Longer term hopefully the SDK will be open sourced and these files can be distributed…

As another workaround, one could run dotnet sln MySolution.sln remove docker-compose.dcproj to remove the project reference.

This is what I do in my VSTS build definition.

@rainersigwald Not on my Linux CI build agents I can’t 😃

Right, completely understand that. By adding the docker-compose project feature to a solution completely breaks running dotnet restore and dotnet build on a solution file. Since the dcproj is a VS2017 feature, I dont expect dotnet to build it, but perhaps ignore it.

The microsoft/aspnetcore-build:1.0-1.1 docker image has “fixed” this by adding the SDK in the dotnet path. Howerver, I hope this is a temporary workaround.

root@8ca61219426a:/usr/share/dotnet# find / -xdev 2>/dev/null -name "Microsoft.Docker.Sdk"
/usr/share/dotnet/sdk/1.0.1/Sdks/Microsoft.Docker.Sdk

For all the watchers here: dotnet/cli#8416 should fix this one. I’ve just bumped it to see if there’s anything blocking it.

Will this ever be fixed?

@livarcocc Can we please have an update on this issue?

How is this issue closed? dotnet restore is still broken for me with a dcproj file in the solution. Why are these projects not simply ignored?

Just for any others needing a workaround in their linux CI agents: Use something like dotnet sln remove $(dotnet sln list | grep .dcproj) and you’re good

ping @richlander ?

now Linux .net core 2.0 sdk doesn’t support docker? I got docker-compose.dcproj : error MSB4236: The SDK 'Microsoft.Docker.Sdk' specified could not be found.

For all those trying to get the docker image (microsoft/aspnetcore-build) working see: https://github.com/aspnet/aspnet-docker/issues/299

Apparently there is also a microsoft/aspnetcore-build:1.0-2.0 image that comes with the Microsoft.Docker.Sdk.

Finally my build is working again thanks to @natemcmaster who provided that solution.

@livarcocc @dazhao-msft @eerhardt Can we please have an update on this? Even a “we are working on it…” would be helpful. More and more people are coming to this issue as well as the closed PR that would have fixed it.

So no fix?

With vague apologies for the self-promotion, having put together a whole pipeline of .NET Core 1.1, Visual Studio 2017 and Docker on TeamCity, I wrote a blog post for work on it - hopefully it will help anyone else trying to do this.

@philcontrolf1 thank you for the solution, this worked for me

@SeWieland - I also have the same problem. As this one is closed I have opened issue https://github.com/dotnet/sdk/issues/35134

3.0.100-preview8-013656 still broken. @livarcocc can you reopen this?

I hadn’t even noticed that feature!

I always use the “basic” Docker support (i.e. no .dcproj), and add docker-compose files manually as required.

If I want to debug a containerized app with its dependencies running in Docker as well (which rarely happens), I start all dependencies using docker-compose before debugging the actual app, and expose their ports on the host. In this setup, the application can resolve its dependencies using host.docker.internal as host name. It’s requires a few more manual steps and works only for a debugging a single container, but it saves me all the .dcproj headache you’ve mentioned.

A workaround to this - if you’re using teamcity, change your build script to execute the commands in your docker-compose file…

Replace: docker-compose docker-compose docker-compose.ci.build.yml up

With: dotnet restore mysolution.sln dotnet publish mysolution.sln -c Release -o ./obj/Docker/publish

removes the dependency on Microsoft.Docker.Sdk…

hope it helps someone!

Any ETA on fix?

@philcontrolf1 thanks for checking. It’s confirmed that this is a mistake, I built some vsts build agents for different purposes of testing, some of them don’t have docker installed. and the agent I used and occurred this problem just doesn’t have. Now everything is working perfectly.