New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Generated Dockerfile does not copy .dcproj into the container #87
Comments
Hi @natemcmaster, Sorry for butting in, but I'm encountering MSB4236 while not building within a docker container. I'm just trying to build on the host system. Also, VS Code says "Unknown project type" for *.dcproj files. Here's my
So questions for you:
|
You're hitting a separate issue from this one. MSB4236 happens on any project beginning with You can workaround it by adding a dummy set of targets to your SDK. (see https://github.com/Microsoft/DockerTools/blob/master/Sdk.props and https://github.com/Microsoft/DockerTools/blob/master/Sdk.targets). These targets are effectively a no-op when building in anything but Visual Studio, so it's just a workaround, not a real solution.
|
OK. I guess I'll take a look at 2.1.300. Thanks! |
@natemcmaster I think maybe this can be closed now...? I just tried adding Docker support to both a Console App and a Web Application with VS 15.7.2, and the Dockerfiles switched from using the Console App
Web Application
|
Yes, the Visual Studio team fixed this by changing the way Dockerfiles are generated. For anyone who generated the file with an older version of Visual Studio, they will need to update manually. I recommend resolving the MSB3202 warning instead of suppressing it, and upgrading to .NET Core 2.1, which has support for the .dcproj file. |
The current VS tooling generates a Dockerfile that looks like this:
This file does not copy the .dcproj into the container, even though the .sln file references the .dcproj. This was done to workaround a different error,
error: MSB4236: The SDK 'Microsoft.Docker.Sdk' specified could not be found
which happens when the .dcproj is present. However, this means the project setup is malformed.-nowarn:MSB3202
was added to suppress a legitimate warning about the malformed project setup. As we experienced between the 2.1.4 and 2.1.101 update, NuGet by default no longer coerces MSB3202 from an error to a warning, so-nowarn:MSB3202
does not preventdotnet restore
from failing.Suggestion
Change the generated Dockerfile to include the .dcproj file when building inside the container, and let's find a way to solve the issue with
MSB4236
. Obviously, this needs more discussion as there are a few ways to do this, and we need to consider the impact of all them on the dotnet CLI, VS, Docker, etc.The text was updated successfully, but these errors were encountered: