.NET Core Docker images will move to multi-arch based tags about announcements HOT 13 OPEN

@leecow @MichaelSimons @richlander

from announcements.

that simplifies image management and deployment!

from announcements.

Just wonder why WindowsServer Core images are not being published anymore, but good start! 😃

from announcements.

@galvesribeiro, The only .NET Core images we are producing for Windows is on Nano Server. The only .NET full framework images we are producing is on Windows Server Core. Nano Server is much lighter and thus provides the best docker experience for running your .NET Core apps on Windows.

from announcements.

@MichaelSimons hummm I may be wrong, but I could swear I saw windowsservercore images before. There are legitimate reasons on why you would use Windows Server Core over NanoServer even with .Net Core. For example, one would need PInvoke a Win32 API or a 3rd party native library which depends on it and that API would not be available on NanoServer.

I'm all up to use NanoServer, in fact I am using it. But I have cases where native code is required and NanoServer don't work with it...

from announcements.

@galvesribeiro can still get the 5GB server core based images if that's your bag https://hub.docker.com/r/microsoft/windowsservercore/

from announcements.

@galvesribeiro What do you mean? The lastest windowsservercore image was published just a 7 days ago. Are you referring to the .NET Framework images and windowsservercore not yet moving to 4.7? The full .NET Framework images were pushed just yesterday. We are still researching how moving the latest tag to 4.7 would affect users.

from announcements.

Oh I see. Yes, @benaadams is right. You can always copy and paste layers from our nanoserver Dockerfile that install .NET Core and add them to a Dockerfile that uses the windowsservercore base image.

from announcements.

@galvesribeiro - you are correct in that we had .NET Core images based on windowsservercore for a short period while we were experimenting what made the most sense for everyone. These were removed under dotnet/dotnet-docker#129.

from announcements.

@benaadams I'm not saying it is impossible, I'm just saying it should be in the list of supported pre-baked .Net Core images. And it is not a matter of "my bag", it is a legitimate use-case where people with .Net Core applications must run it on Windows Server Core due to the bigger (native) API surface in it.

@kendrahavens Hey, I was saying that it should be on the list of .Net Core images since it is a valid scenario.

@MichaelSimons sure, I just saw that PR as well. Although I don't agree with the rationale that "it is better to use full framework with Server Core" I respect the decision. 😄

It was just a thought, don't want to make this a big case, just remember that almost everyone in corporate world that is migrating from .Net (full) Framework to .Net Core depends on that API to work and that would help migration paths.

Anyway, kudos for @kendrahavens on the announcement. Good work team!

from announcements.

two things

1. Could announcements at dotnet/announcements get a separate thread on different repo, and have conversations in this repo get locked? Personally, I enjoy subscribing to announcements, but I'm not sure I want to be emailed for every comment, and reply.

2. While I would personally never consider running windows server. I'd think it would make sense to publish a servercore aspnetcore dockerfile. I work at a large e-commerce company, and I see many teams that want to move their existing apps to core. They like the programming model, and prefer the unified controllers. They want to eventually get off windows server, but parts of the API are still missing, or they are still dependent on other packages not yet core ready. Many of those missing api's are making a return in netstandard 2.0 (yuge kudos btw).

I think for many enterprises there is a transitory period, where an existing app is re-written ontop of mvc core, targeting full framework. They keep it on full framework, because much of their existing code relies on it. Then eventually the full framework training wheels are removed. I think it would make sense to provide a docker image for such a story, however its understandable if it seems unnecessary.

I do agree with @galvesribeiro thoughts, but as previously mentioned. We can easily roll our own.

from announcements.

Moving conversation to dotnet-docker issue to clean up notifications for the announcement repo.

from announcements.

Reopening according to process.

from announcements.