How to use dotnet restore properly in Dockerfile
When adding docker support to a ASP.NET Core project VS (15.9.2) will add a default Dockerfile that does restore, build and publish. But instead of just copying all files into the Docker build container it first copies just the proj-files, does the restore and then copies the rest before it builds. I was wondering why this is done like this? In what way is that different from just copying all files directly and then doing the restore?
The problem with this approach is that all proj-files in the solution will need to be copied separately and if the project is really big with projects being added and removed from time to time it's a bit hard to keep the Dockerfile in synch with this. I just like to know why this is done like this and if it would be just as ok to copy everything instead?
FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ["Temp2/Temp2.csproj", "Temp2/"]
COPY ["Temp3/Temp3.csproj", "Temp3/"]
RUN dotnet restore "Temp2/Temp2.csproj"
COPY . .
WORKDIR "/src/Temp2"
RUN dotnet build "Temp2.csproj" -c Release -o /app
or
FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY . .
RUN dotnet restore "Temp2/Temp2.csproj"
WORKDIR "/src/Temp2"
RUN dotnet build "Temp2.csproj" -c Release -o /app
asp.net-core dockerfile
add a comment |
When adding docker support to a ASP.NET Core project VS (15.9.2) will add a default Dockerfile that does restore, build and publish. But instead of just copying all files into the Docker build container it first copies just the proj-files, does the restore and then copies the rest before it builds. I was wondering why this is done like this? In what way is that different from just copying all files directly and then doing the restore?
The problem with this approach is that all proj-files in the solution will need to be copied separately and if the project is really big with projects being added and removed from time to time it's a bit hard to keep the Dockerfile in synch with this. I just like to know why this is done like this and if it would be just as ok to copy everything instead?
FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ["Temp2/Temp2.csproj", "Temp2/"]
COPY ["Temp3/Temp3.csproj", "Temp3/"]
RUN dotnet restore "Temp2/Temp2.csproj"
COPY . .
WORKDIR "/src/Temp2"
RUN dotnet build "Temp2.csproj" -c Release -o /app
or
FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY . .
RUN dotnet restore "Temp2/Temp2.csproj"
WORKDIR "/src/Temp2"
RUN dotnet build "Temp2.csproj" -c Release -o /app
asp.net-core dockerfile
add a comment |
When adding docker support to a ASP.NET Core project VS (15.9.2) will add a default Dockerfile that does restore, build and publish. But instead of just copying all files into the Docker build container it first copies just the proj-files, does the restore and then copies the rest before it builds. I was wondering why this is done like this? In what way is that different from just copying all files directly and then doing the restore?
The problem with this approach is that all proj-files in the solution will need to be copied separately and if the project is really big with projects being added and removed from time to time it's a bit hard to keep the Dockerfile in synch with this. I just like to know why this is done like this and if it would be just as ok to copy everything instead?
FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ["Temp2/Temp2.csproj", "Temp2/"]
COPY ["Temp3/Temp3.csproj", "Temp3/"]
RUN dotnet restore "Temp2/Temp2.csproj"
COPY . .
WORKDIR "/src/Temp2"
RUN dotnet build "Temp2.csproj" -c Release -o /app
or
FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY . .
RUN dotnet restore "Temp2/Temp2.csproj"
WORKDIR "/src/Temp2"
RUN dotnet build "Temp2.csproj" -c Release -o /app
asp.net-core dockerfile
When adding docker support to a ASP.NET Core project VS (15.9.2) will add a default Dockerfile that does restore, build and publish. But instead of just copying all files into the Docker build container it first copies just the proj-files, does the restore and then copies the rest before it builds. I was wondering why this is done like this? In what way is that different from just copying all files directly and then doing the restore?
The problem with this approach is that all proj-files in the solution will need to be copied separately and if the project is really big with projects being added and removed from time to time it's a bit hard to keep the Dockerfile in synch with this. I just like to know why this is done like this and if it would be just as ok to copy everything instead?
FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ["Temp2/Temp2.csproj", "Temp2/"]
COPY ["Temp3/Temp3.csproj", "Temp3/"]
RUN dotnet restore "Temp2/Temp2.csproj"
COPY . .
WORKDIR "/src/Temp2"
RUN dotnet build "Temp2.csproj" -c Release -o /app
or
FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY . .
RUN dotnet restore "Temp2/Temp2.csproj"
WORKDIR "/src/Temp2"
RUN dotnet build "Temp2.csproj" -c Release -o /app
asp.net-core dockerfile
asp.net-core dockerfile
asked Nov 24 '18 at 16:11
Andreas ZitaAndreas Zita
3,05732984
3,05732984
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
When Docker builds an image, it maintains a build cache:
When building an image, Docker steps through the instructions in your Dockerfile, executing each in the order specified. As each instruction is examined, Docker looks for an existing image in its cache that it can reuse, rather than creating a new (duplicate) image.
Importantly, the ADD
and COPY
instructions get special treatment:
For the
ADD
andCOPY
instructions, the contents of the file(s) in the image are examined and a checksum is calculated for each file. The last-modified and last-accessed times of the file(s) are not considered in these checksums. During the cache lookup, the checksum is compared against the checksum in the existing images. If anything has changed in the file(s), such as the contents and metadata, then the cache is invalidated.
When building a .NET Core solution, we can be sure that after running dotnet restore
, the result of running dotnet restore
again will only change if the .csproj
file has changed (e.g. a new package is added or a version is changed).
By copying the .csproj
files into the image separately, we can take advantage of Docker's build cache, which means that so long as the .csproj
file hasn't changed, the dotnet restore
step will not be re-executed unnecessarily each and every time the image gets rebuilt.
Thanks for coming back to accept this one. I remember the question from when you first asked it but I didn't know the answer at the time. I stumbled across something similar yesterday and thought I'd bring the explanation here. :)
– Kirk Larkin
Feb 23 at 20:23
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53460002%2fhow-to-use-dotnet-restore-properly-in-dockerfile%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
When Docker builds an image, it maintains a build cache:
When building an image, Docker steps through the instructions in your Dockerfile, executing each in the order specified. As each instruction is examined, Docker looks for an existing image in its cache that it can reuse, rather than creating a new (duplicate) image.
Importantly, the ADD
and COPY
instructions get special treatment:
For the
ADD
andCOPY
instructions, the contents of the file(s) in the image are examined and a checksum is calculated for each file. The last-modified and last-accessed times of the file(s) are not considered in these checksums. During the cache lookup, the checksum is compared against the checksum in the existing images. If anything has changed in the file(s), such as the contents and metadata, then the cache is invalidated.
When building a .NET Core solution, we can be sure that after running dotnet restore
, the result of running dotnet restore
again will only change if the .csproj
file has changed (e.g. a new package is added or a version is changed).
By copying the .csproj
files into the image separately, we can take advantage of Docker's build cache, which means that so long as the .csproj
file hasn't changed, the dotnet restore
step will not be re-executed unnecessarily each and every time the image gets rebuilt.
Thanks for coming back to accept this one. I remember the question from when you first asked it but I didn't know the answer at the time. I stumbled across something similar yesterday and thought I'd bring the explanation here. :)
– Kirk Larkin
Feb 23 at 20:23
add a comment |
When Docker builds an image, it maintains a build cache:
When building an image, Docker steps through the instructions in your Dockerfile, executing each in the order specified. As each instruction is examined, Docker looks for an existing image in its cache that it can reuse, rather than creating a new (duplicate) image.
Importantly, the ADD
and COPY
instructions get special treatment:
For the
ADD
andCOPY
instructions, the contents of the file(s) in the image are examined and a checksum is calculated for each file. The last-modified and last-accessed times of the file(s) are not considered in these checksums. During the cache lookup, the checksum is compared against the checksum in the existing images. If anything has changed in the file(s), such as the contents and metadata, then the cache is invalidated.
When building a .NET Core solution, we can be sure that after running dotnet restore
, the result of running dotnet restore
again will only change if the .csproj
file has changed (e.g. a new package is added or a version is changed).
By copying the .csproj
files into the image separately, we can take advantage of Docker's build cache, which means that so long as the .csproj
file hasn't changed, the dotnet restore
step will not be re-executed unnecessarily each and every time the image gets rebuilt.
Thanks for coming back to accept this one. I remember the question from when you first asked it but I didn't know the answer at the time. I stumbled across something similar yesterday and thought I'd bring the explanation here. :)
– Kirk Larkin
Feb 23 at 20:23
add a comment |
When Docker builds an image, it maintains a build cache:
When building an image, Docker steps through the instructions in your Dockerfile, executing each in the order specified. As each instruction is examined, Docker looks for an existing image in its cache that it can reuse, rather than creating a new (duplicate) image.
Importantly, the ADD
and COPY
instructions get special treatment:
For the
ADD
andCOPY
instructions, the contents of the file(s) in the image are examined and a checksum is calculated for each file. The last-modified and last-accessed times of the file(s) are not considered in these checksums. During the cache lookup, the checksum is compared against the checksum in the existing images. If anything has changed in the file(s), such as the contents and metadata, then the cache is invalidated.
When building a .NET Core solution, we can be sure that after running dotnet restore
, the result of running dotnet restore
again will only change if the .csproj
file has changed (e.g. a new package is added or a version is changed).
By copying the .csproj
files into the image separately, we can take advantage of Docker's build cache, which means that so long as the .csproj
file hasn't changed, the dotnet restore
step will not be re-executed unnecessarily each and every time the image gets rebuilt.
When Docker builds an image, it maintains a build cache:
When building an image, Docker steps through the instructions in your Dockerfile, executing each in the order specified. As each instruction is examined, Docker looks for an existing image in its cache that it can reuse, rather than creating a new (duplicate) image.
Importantly, the ADD
and COPY
instructions get special treatment:
For the
ADD
andCOPY
instructions, the contents of the file(s) in the image are examined and a checksum is calculated for each file. The last-modified and last-accessed times of the file(s) are not considered in these checksums. During the cache lookup, the checksum is compared against the checksum in the existing images. If anything has changed in the file(s), such as the contents and metadata, then the cache is invalidated.
When building a .NET Core solution, we can be sure that after running dotnet restore
, the result of running dotnet restore
again will only change if the .csproj
file has changed (e.g. a new package is added or a version is changed).
By copying the .csproj
files into the image separately, we can take advantage of Docker's build cache, which means that so long as the .csproj
file hasn't changed, the dotnet restore
step will not be re-executed unnecessarily each and every time the image gets rebuilt.
answered Feb 22 at 17:29
Kirk LarkinKirk Larkin
21.7k64059
21.7k64059
Thanks for coming back to accept this one. I remember the question from when you first asked it but I didn't know the answer at the time. I stumbled across something similar yesterday and thought I'd bring the explanation here. :)
– Kirk Larkin
Feb 23 at 20:23
add a comment |
Thanks for coming back to accept this one. I remember the question from when you first asked it but I didn't know the answer at the time. I stumbled across something similar yesterday and thought I'd bring the explanation here. :)
– Kirk Larkin
Feb 23 at 20:23
Thanks for coming back to accept this one. I remember the question from when you first asked it but I didn't know the answer at the time. I stumbled across something similar yesterday and thought I'd bring the explanation here. :)
– Kirk Larkin
Feb 23 at 20:23
Thanks for coming back to accept this one. I remember the question from when you first asked it but I didn't know the answer at the time. I stumbled across something similar yesterday and thought I'd bring the explanation here. :)
– Kirk Larkin
Feb 23 at 20:23
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53460002%2fhow-to-use-dotnet-restore-properly-in-dockerfile%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown