Built-in container support for the .NET SDK
devblogs.microsoft.com
Built-in container support for the .NET SDK
1–10 of 30 posts
Re: Built-in container support for the .NET SDK
#2What problem is this solving? I have been building containerized .NET applications for a couple of years now. It is super easy to use docker command to build x86 Linux and ARM docker images. I don't think I'll switch to Microsoft's half-assed solution since the docker command works just fine.
Here's the problem Microsoft should be solving instead: Once a docker image is built, how can my customer (not me) deploy it to Azure using their Azure account? I would like to provide a "Deploy to Azure" button similar to Heroku's "Deploy to Heroku". My customer should be able to deploy a web application using my docker image with a single click, using their Azure subscription. Heroku even provisions a Postgres database in the process. And it was all free until a couple of days ago.
Re: Built-in container support for the .NET SDK
#3What problem is this solving? I have been building containerized .NET applications for a couple of years now. It is super easy to use docker command to build x86 Linux and ARM docker images. I don't think I'll switch to Microsoft's half-assed solution since the docker command works just fine. Here's the problem Microsoft should be solving instead: Once a docker image is built, how can my customer (not me) deploy it t…
Can you explain what's "half-assed" about this solution?
Re: Built-in container support for the .NET SDK
#4What problem is this solving? I have been building containerized .NET applications for a couple of years now. It is super easy to use docker command to build x86 Linux and ARM docker images. I don't think I'll switch to Microsoft's half-assed solution since the docker command works just fine. Here's the problem Microsoft should be solving instead: Once a docker image is built, how can my customer (not me) deploy it t…
Can you explain what's "half-assed" about this solution?
Does it support docker running on MacOS M1, or Raspberry Pi? I need both of those. What about the dozens of features supported by Dockerfile? If you need even one of those features (for example, VOLUME), then you're back to writing Dockerfiles. And there's nothing wrong with writing Dockerfiles to begin with. You really don't need something coming in between, it's only going to get in the way.
Re: Built-in container support for the .NET SDK
#5Earlier quoted context omitted.
Can you explain what's "half-assed" about this solution?
Does it support docker running on MacOS M1, or Raspberry Pi? I need both of those. What about the dozens of features supported by Dockerfile? If you need even one of those features (for example, VOLUME), then you're back to writing Dockerfiles. And there's nothing wrong with writing Dockerfiles to begin with. You really don't need something coming in between, it's only going to get in the way.
> Does it support docker running on MacOS M1, or Raspberry Pi?
Not at the moment, from the article:
"We have focused on the Linux-x64 image deployment scenario for this initial release. Windows images and other architectures are key scenarios we plan to support for the full release, so watch out for new developments there."
So, ignoring that, this seems like a first cut.
The rational for this seems to be streamlining docker builds when working with dotnet:
"This Dockerfile works very well, but there are a few caveats to it that aren’t immediately apparent, which arise from the concept of a Docker build context. The build context is a the set of files that are accessible inside of a Dockerfile, and is often (though not always) the same directory as the Dockerfile. If you have a Dockerfile located beside your project file, but your project file is underneath a solution root, it’s very easy for your Docker build context to not include configuration files like Directory.Packages.props or NuGet.config that would be included in a regular dotnet build. You would have this same situation with any hierarchical configuration model, like EditorConfig or repository-local git configurations.
This mismatch between the explicitly-defined Docker build context and the .NET build process was one of the driving motivators for this feature. All of the information required to build an image is present in a standard dotnet build, we just needed to figure out the right way to represent that data in a way that container runtimes like Docker could use."
Why is this a problem in your opinion? I'm not trying to catch you out, but as someone who's not using docker for .net builds/deployments I'm trying to understand why you're dismissing this feature.
Re: Built-in container support for the .NET SDK
#6Earlier quoted context omitted.
Does it support docker running on MacOS M1, or Raspberry Pi? I need both of those. What about the dozens of features supported by Dockerfile? If you need even one of those features (for example, VOLUME), then you're back to writing Dockerfiles. And there's nothing wrong with writing Dockerfiles to begin with. You really don't need something coming in between, it's only going to get in the way.
> Does it support docker running on MacOS M1, or Raspberry Pi? Not at the moment, from the article: "We have focused on the Linux-x64 image deployment scenario for this initial release. Windows images and other architectures are key scenarios we plan to support for the full release, so watch out for new developments there." So, ignoring that, this seems like a first cut. The rational for this seems to be streamlining…
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 .
Re: Built-in container support for the .NET SDK
#7Earlier quoted context omitted.
> Does it support docker running on MacOS M1, or Raspberry Pi? Not at the moment, from the article: "We have focused on the Linux-x64 image deployment scenario for this initial release. Windows images and other architectures are key scenarios we plan to support for the full release, so watch out for new developments there." So, ignoring that, this seems like a first cut. The rational for this seems to be streamlining…
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?
I appreciate your comments. Maybe time for me to update my docker chops and see what this brings brings to the table, if anything.
Re: Built-in container support for the .NET SDK
#8Earlier quoted context omitted.
> Does it support docker running on MacOS M1, or Raspberry Pi? Not at the moment, from the article: "We have focused on the Linux-x64 image deployment scenario for this initial release. Windows images and other architectures are key scenarios we plan to support for the full release, so watch out for new developments there." So, ignoring that, this seems like a first cut. The rational for this seems to be streamlining…
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?
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”.
Re: Built-in container support for the .NET SDK
#9What problem is this solving? I have been building containerized .NET applications for a couple of years now. It is super easy to use docker command to build x86 Linux and ARM docker images. I don't think I'll switch to Microsoft's half-assed solution since the docker command works just fine. Here's the problem Microsoft should be solving instead: Once a docker image is built, how can my customer (not me) deploy it t…
Honestly having .NET figure out what is needed for the image, the build context, etc. is a much better way to build and it doesn't require having the extra tooling.
Full disclosure: Engineer at Microsoft (and previously Docker) not at all involved in .NET. I work on moby (aka docker project) and internal builds of docker and CNCF related projects.
Re: Built-in container support for the .NET SDK
#10Earlier quoted context omitted.
> Does it support docker running on MacOS M1, or Raspberry Pi? Not at the moment, from the article: "We have focused on the Linux-x64 image deployment scenario for this initial release. Windows images and other architectures are key scenarios we plan to support for the full release, so watch out for new developments there." So, ignoring that, this seems like a first cut. The rational for this seems to be streamlining…
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?
.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.