Set RestoreUseSkipNonexistentTargets=false in the 2.0 image to workaround changes between the 2.1.4 and 2.1.101 SDK

[natemcmaster]

Workaround microsoft/DockerTools#87.

Addresses #388

FYI @glennc @nkolev92 @Eilon

[muratg]

👍

[alexvy86]

@natemcmaster do you know if there are any plans to implement the same workaround in the dotnet-docker images?

[natemcmaster]

No immediate plans. Why do you ask?

We chose to put this here as a targeted workaround because the Visual Studio tooling generates a reference to microsoft/aspnetcore-build. We'd like to minimize number of places that have workarounds.

[alexvy86]

In the Dockerfile that VS tooling adds to console app projects, the build stage is based on microsoft/dotnet:2.0-sdk, thus my question. In my case the broken CI builds are for console apps. I went to the dotnet-docker images repo and didn't see any issues/PRs like yours there, so I was wondering if the fixes were particular to ASP .NET Core projects for any reason.

[natemcmaster]

Oofta, I don't think anyone pointed that out. I'll use my internal email powers to forward this along.

[natemcmaster]

@alexvy86 in the meantime, you can always add ENV RestoreUseSkipNonexistentTargets false to your own file to workaround, or change any calls to dotnet-restore to dotnet restore -p:RestoreUseSkipNonexistentTargets=false

[alexvy86]

Yes, I did find those two solutions and already applied one, thanks!

[AceHack]

@alexvy86 It's my understanding that dotnet:2.1-sdk is replacing the aspnet-build image. Can this fix or a better fix be applied? Thanks.

[alexvy86]

@AceHack not for me to decide, I don't work at Microsoft :). The fix @natemcmaster suggested is for our projects' Dockerfiles though, so you can still do either of those.

I did notice that the 2.1-sdk image doesn't have the same workaround as the 2.0-sdk image, but I've since become of the opinion that copying the *.csproj files and running dotnet restore on those instead of the *.sln (which is when you might encounter this issue) is a better approach. Feel free to open an issue in the images repo if you'd like to see the same workaround from this PR in the 2.1-sdk image.

[AceHack]

@alexvy86 I have several csproj files and this just feels like a hack. It would be nice to just be able to copy everything and have it ignore the dcproj inside the docker container.

[alexvy86]

Are they independent csproj files? As in, different executables/applications? If it's a single application that depends on class libraries defined in separate projects,, you only need to call dotnet restore on the main csproj. You can still copy everything (*.sln and *.dcproj included, if you want) into the container if that's easier, the change would only be that instead of doing RUN dotnet restore (on the folder of the *.sln), you do RUN dotnet restore <path-to-main-csproj>.

I actually don't consider it a hack because in my mind the *.dcproj is not part of my application and it has no need to live in the container, even if it doesn't hurt anything.

[alexvy86]

In fact, the latest version of Visual Studio generates Dockerfiles that do just that, call dotnet restore directly on the main *.csproj file (and only the main one; if you have class libraries, it copies their csproj files as well because it needs them to restore their NuGet dependencies, but just one call to dotnet restore is needed, as you can see below):

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

[natemcmaster]

This is not a change we plan to port to the 2.1 images for three reasons:

1. This was added as a workaround to un-break people who were using Visual Studio's generated Dockerfiles. These files were not generated using MSBuild best practices, but enough customers were broken that we needed to provide a quick fix.
2. As @alexvy86 pointed out, Visual Studio fixed the way it generates Dockerfiles for new projects
3. In 2.1, the .NET Core SDK now supports 'Microsoft.Docker.Sdk.' You should be able to copy both .csproj .NET Core projects and .dcproj files, and call 'dotnet restore' on your .sln.