Skip to content
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

Closed
natemcmaster opened this issue Mar 15, 2018 · 5 comments
Closed

Generated Dockerfile does not copy .dcproj into the container #87

natemcmaster opened this issue Mar 15, 2018 · 5 comments

Comments

@natemcmaster
Copy link

The current VS tooling generates a Dockerfile that looks like this:

FROM microsoft/aspnetcore-build:2.0 AS build
WORKDIR /src
COPY HelloWorld.sln ./
COPY HelloWorld/HelloWorld.csproj HelloWorld/
RUN dotnet restore -nowarn:msb3202,nu1503

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 prevent dotnet 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.

@rsaltrelli
Copy link

rsaltrelli commented Apr 11, 2018

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 dotnet --info:

$ dotnet --info
.NET Command Line Tools (2.1.104)

Product Information:
 Version:            2.1.104
 Commit SHA-1 hash:  48ec687460

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  16.04
 OS Platform: Linux
 RID:         ubuntu.16.04-x64
 Base Path:   /usr/share/dotnet/sdk/2.1.104/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.6
  Build    : 74b1c703813c8910df5b96f304b0f2b78cdf194d

So questions for you:

  1. Is the VS Code issue related to MSB4236?
  2. Unless I'm misunderstanding something, it seems like the solution should be to use SDK 2.1.104, but I am and still seeing the error. Did I miss something? What should I do?

@natemcmaster
Copy link
Author

natemcmaster commented Apr 11, 2018

You're hitting a separate issue from this one. MSB4236 happens on any project beginning with <Project Sdk="Microsoft.Docker.Sdk"> cannot build with dotnet.exe because Microsoft.Docker.Sdk is only supported from msbuild.exe, not dotnet.exe. This will be fixed in the 2.1.300 SDK update (currently in preview).

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.

mkdir -p /usr/share/dotnet/sdk/2.1.104/Sdks/Microsoft.Docker.Sdk
curl https://raw.githubusercontent.com/Microsoft/DockerTools/master/Sdk.props -o /usr/share/dotnet/sdk/2.1.104/Sdks/Microsoft.Docker.Sdk/Sdk.props
curl https://raw.githubusercontent.com/Microsoft/DockerTools/master/Sdk.targets -o /usr/share/dotnet/sdk/2.1.104/Sdks/Microsoft.Docker.Sdk/Sdk.targets

@rsaltrelli
Copy link

OK. I guess I'll take a look at 2.1.300. Thanks!

@alexvy86
Copy link

alexvy86 commented Jun 2, 2018

@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*.sln file to using the *.csproj files directly, so the issue of the *.dcproj file not being there became a non-issue going forward, right? This is how the Dockerfiles look right now.

Console App

FROM microsoft/dotnet:2.1-runtime AS base
WORKDIR /app

FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ConsoleApp1/ConsoleApp1.csproj ConsoleApp1/
RUN dotnet restore ConsoleApp1/ConsoleApp1.csproj
COPY . .
WORKDIR /src/ConsoleApp1
RUN dotnet build ConsoleApp1.csproj -c Release -o /app

FROM build AS publish
RUN dotnet publish ConsoleApp1.csproj -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "ConsoleApp1.dll"]

Web Application

FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 60030
EXPOSE 44369

FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY WebApplication3/WebApplication3.csproj WebApplication3/
RUN dotnet restore WebApplication3/WebApplication3.csproj
COPY . .
WORKDIR /src/WebApplication3
RUN dotnet build WebApplication3.csproj -c Release -o /app

FROM build AS publish
RUN dotnet publish WebApplication3.csproj -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "WebApplication3.dll"]

@natemcmaster
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants