Dotnet-docker: Remove unncessessary ASP.NET Core 2.1 Dockerfile step 'RUN dotnet restore'

Created on 3 Jun 2018  路  2Comments  路  Source: dotnet/dotnet-docker

ASP.NET Core 2.1 sample Dockerfile has a uneccessary step, that also fails for other solution projects added to the solution, like a test project.

RUN dotnet restore

dotnet restore documentation states:

Starting with .NET Core 2.0, you don't have to run dotnet restore because it's run implicitly by all commands that require a restore to occur, such as dotnet new, dotnet build and dotnet run

It is uncessessary because a publish/build command is later run, obviously. : P

It fails for other projects because they have not been copied to the ./aspnetapp/ folder. You might think; "but add the other project with Copy", no, one does not always want to do so! Like for test projects which should not be built as part of the Dockerimage. Instead i want to only build the actual deployed aspnetapp.dll.

By removing the "RUN dotnet restore" step we make sure only the neccessary projects is restored.

Most helpful comment

@Andrioden - The pattern used in the sample Dockerfiles that performs an explicit restore is designed to avoid the overhead of restoring each time the Dockerfiles are built. This is advantages for development scenarios where you are making changes and rebuilding the Dockerfiles numerous times. See Docker's documentation on build cache.

In practice this means that when you first build the sample Dockerfile, the layers that correspond to each instruction are produced. Now suppose you make a code change to a .cs file. The restore layer is able to be reused when you docker build. As a result your docker build will be faster (much faster if you have a bunch of NuGet dependencies).

The dotnet sample Dockerfile shows this pattern in use with multiple projects. Notice that the tests are built and run as part of the Docker build process. Obviously this is a single sample and therefore may not meet your particular needs/desires. We are open to feedback and want to hear usage patterns people find useful.

All 2 comments

@Andrioden - The pattern used in the sample Dockerfiles that performs an explicit restore is designed to avoid the overhead of restoring each time the Dockerfiles are built. This is advantages for development scenarios where you are making changes and rebuilding the Dockerfiles numerous times. See Docker's documentation on build cache.

In practice this means that when you first build the sample Dockerfile, the layers that correspond to each instruction are produced. Now suppose you make a code change to a .cs file. The restore layer is able to be reused when you docker build. As a result your docker build will be faster (much faster if you have a bunch of NuGet dependencies).

The dotnet sample Dockerfile shows this pattern in use with multiple projects. Notice that the tests are built and run as part of the Docker build process. Obviously this is a single sample and therefore may not meet your particular needs/desires. We are open to feedback and want to hear usage patterns people find useful.

@MichaelSimons - Thank you for this detailed answer, I did not know that the build cache corresponds to each instruction! I am changing my Dockerfile and closing this issue.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

galvesribeiro picture galvesribeiro  路  7Comments

dapalmi picture dapalmi  路  4Comments

agr picture agr  路  3Comments

MichaelSimons picture MichaelSimons  路  5Comments

girishgouda picture girishgouda  路  7Comments