3 ms·

Yeah I read that paragraph and don't get what they are talking about. I don't understand what problem they are solving. I build docker images for my .NET web ap

Yeah I read that paragraph and don't get what they are talking about. I don't understand what problem they are solving. I build docker images for my .NET web app multiple times a day and it works fine. You do a publish and then in Dockerfile do: COPY bin/Release/net5.0/publish . It works fine. WTF are they talking about a mismatch between explicit definition and the .NET build process?

teh_klev 4y ago
I appreciate your comments. Maybe time for me to update my docker chops and see what this brings brings to the table, if anything.
FridgeSeal 4y ago
The cynic is me would say that this is a MS attempt to take ownership and mindshare over a piece of “commodity” tooling so that devs in the ecosystem become more familiar with that than the original system, add MS/dotnet specific features and push their own system. A modern variation of “embrace, extend, extinguish”. I doubt MS has the power or desire to extinguish containers, but getting a foot in to the deployments space would be a win for them “use dotnet because it deploys better than other solutions”.
- teh_klev 4y ago
  I kinda tire of this sort of comment. I lived/worked through the EEE phase of MS back in the 90's, for good or for bad, but ultimately every large scale vendor wants to own the current "hot" space with their vendor specific tooling. No corporation is your friend.
cpuguy83 4y ago
.net knows what version it is, it knows what deps your project has, etc. Instead of declaring this effectively twice (once for .net and once for Docker), .net is handling everything.
- PretzelFisch 4y ago
  I also see the big call out to cases where the dockerfile and project are not in the same directory, This looks like a more straight forward improvement.
  - deleted 4y ago
    [deleted]
Merad 4y ago
Look at the example dockerfile farther down in the article. They're performing the build inside of a dotnet sdk container then creating the application container. It sounds like you're performing the build outside of a container and just packaging the artifacts.
- petilon 4y ago
  Right. I have Visual Studio installed. I don't need a container to build the application, I only need it for deployment.
  - crescentfresh 4y ago
    Container to build is nice in CI pipelines, then you don't need msbuild installed on CI runners.
chusk3 4y ago
Mainly what I was getting at here is that there are often repo-level files that are part of the .NET build process that are easy to forget to include in your build context/as part of the initial COPY command that most folks to do to a package restore before build to take advantage of Dockerfile layer caching. Right now as a user you have to be aware of the repo/file layouts and get your build contexts right if you build inside of a multi-stage Dockerfile. IMO for a significant part of the user base there's no reason to have to manage that at all - .NET is capable of cross-targeting enough to not need to perform the build inside of a container. That keeps the user in the 'build context' that they are used to, and we can use all of that context to still end up at the ideal result - a correct container, with all of their app dependencies.
jhaygood86 4y ago
Many people want the build to be in Docker to. I personally don't -- I publish on the host build agent and just Dockerize the publish directory

teh_klev 4y ago

I appreciate your comments. Maybe time for me to update my docker chops and see what this brings brings to the table, if anything.

FridgeSeal 4y ago

The cynic is me would say that this is a MS attempt to take ownership and mindshare over a piece of “commodity” tooling so that devs in the ecosystem become more familiar with that than the original system, add MS/dotnet specific features and push their own system. A modern variation of “embrace, extend, extinguish”. I doubt MS has the power or desire to extinguish containers, but getting a foot in to the deployments space would be a win for them “use dotnet because it deploys better than other solutions”.

teh_klev 4y ago
I kinda tire of this sort of comment. I lived/worked through the EEE phase of MS back in the 90's, for good or for bad, but ultimately every large scale vendor wants to own the current "hot" space with their vendor specific tooling. No corporation is your friend.

cpuguy83 4y ago

.net knows what version it is, it knows what deps your project has, etc. Instead of declaring this effectively twice (once for .net and once for Docker), .net is handling everything.

PretzelFisch 4y ago
I also see the big call out to cases where the dockerfile and project are not in the same directory, This looks like a more straight forward improvement.
- deleted 4y ago
  [deleted]

Merad 4y ago

Look at the example dockerfile farther down in the article. They're performing the build inside of a dotnet sdk container then creating the application container. It sounds like you're performing the build outside of a container and just packaging the artifacts.

petilon 4y ago
Right. I have Visual Studio installed. I don't need a container to build the application, I only need it for deployment.
- crescentfresh 4y ago
  Container to build is nice in CI pipelines, then you don't need msbuild installed on CI runners.

chusk3 4y ago

Mainly what I was getting at here is that there are often repo-level files that are part of the .NET build process that are easy to forget to include in your build context/as part of the initial COPY command that most folks to do to a package restore before build to take advantage of Dockerfile layer caching. Right now as a user you have to be aware of the repo/file layouts and get your build contexts right if you build inside of a multi-stage Dockerfile. IMO for a significant part of the user base there's no reason to have to manage that at all - .NET is capable of cross-targeting enough to not need to perform the build inside of a container. That keeps the user in the 'build context' that they are used to, and we can use all of that context to still end up at the ideal result - a correct container, with all of their app dependencies.

jhaygood86 4y ago

Many people want the build to be in Docker to. I personally don't -- I publish on the host build agent and just Dockerize the publish directory