Add .NET Framework latest to 3.5 images about dotnet-framework-docker

[Silvenga]

I think this would be very useful. For example, the WIX installer requires .Net 3.5 to be installed. Even if we are just creating installers for .Net 4.7.2, we still need .Net 3.5 installed. Installing .Net 3.5 is a pain on its own.

[MichaelSimons]

After discussing this we settle on the following going forward.

1. Use a new tagging scheme which clearly indicates which .NET versions are contained within the 3.5 images. e.g. 4.8-3.5
2. Continue to produce 3.5 tagged images to make it easy for existing customers to migrate to newer versions of Windows.

Based on these decisions we will product the following tags for the upcoming release of Windows,

4.8-3.5-20200211-windowsservercore-2004, 4.8-3.5-windowsservercore-2004, 4.8-3.5, 3.5

[mthalman]

Is this implemented?

No, it will be implemented in the upcoming release for Windows Server, version 2004. Note that the implementation is strictly a tagging update as stated here: #70 (comment).

[MichaelSimons]

After pondering this for a while, I am leaning towards retagging the 3.5 images to more accurately depict what they contain.

1. Retag the 3.5 builder images to 4.7.1-3.5. Continue to produce the 3.5 tag with patches but no longer document it in the readme.
2. Retag the 3.5 runtime image to 4.7.1-3.5. Additionally the base image should be changed to 4.7.1 so that the 4.7.1 ngen cache layer can be shared. Continue to produce the 3.5 tag with patches but no longer document it in the readme.
3. Add a 4.71-3.5-windowsservercore-ltsc2016 runtime image based on the 4.71-windowsservercore-ltsc2016 runtime image. Given the 4.7.1 runtime image is more frequently used this will increase the likelihood of sharing layers.

The following would be the resulting tag documentation

Runtime Tags

Windows Server, version 1709 amd64 tags

• 4.7.1-windowsservercore-1709, 4.7.1, latest (4.7.1-windowsservercore-1709/runtime/Dockerfile)
• 4.7.1-3.5-windowsservercore-1709, 4.7.1-3.5 (4.7.1-3.5-windowsservercore-1709/runtime/Dockerfile)

Windows Server 2016 amd64 tags

• 4.7.1-windowsservercore-ltsc2016, 4.7.1, latest (4.7.1-windowsservercore-ltsc2016/runtime/Dockerfile)
• 4.7.1-3.5-windowsservercore-ltsc2016, 4.7.1-3.5 (4.7.1-3.5-windowsservercore-ltsc2016/runtime/Dockerfile)
• 4.7-windowsservercore-ltsc2016, 4.7 (4.7-windowsservercore-ltsc2016/runtime/Dockerfile)
• 4.6.2-windowsservercore-ltsc2016, 4.6.2 (4.6.2-windowsservercore-ltsc2016/runtime/Dockerfile)
• 3.5-windowsservercore-ltsc2016, 3.5 (3.5-windowsservercore-ltsc2016/runtime/Dockerfile)

Builder Tags

Windows Server, version 1709 amd64 tags

• 4.7.1-20180213-windowsservercore-1709, 4.7.1-windowsservercore-1709, 4.7.1-20180213, 4.7.1, latest (4.7.1-windowsservercore-1709/build/Dockerfile)
• 4.7.1-3.5-windowsservercore-1709, 4.7.1-3.5-20180313, 4.7.1-3.5 (4.7.1-3.5-windowsservercore-1709/build/Dockerfile)

Windows Server 2016 amd64 tags

• 4.7.1-20180213-windowsservercore-ltsc2016, 4.7.1-windowsservercore-ltsc2016, 4.7.1-20180213, 4.7.1, latest (4.7.1-windowsservercore-ltsc2016/build/Dockerfile)
• 4.7.1-3.5-windowsservercore-ltsc2016, 4.7.1-3.5-20180313, 4.7.1-3.5 (4.7.1-3.5-windowsservercore-ltsc2016/build/Dockerfile)

Thoughts?

[MichaelSimons]

@richlander - What are your thoughts on the tagging impact of this change? This is a potentially impacting change that would warrant a new tag.

[richlander]

Ya. You are right. We don't need to provide all the intervening versions, but if we provide a 4.7.1 variant, we still need to allow people to get back to the 4.6.2 variant. I'm wondering which should be the default. If adding 4.7.1 came with no associated size increase, it would be an easy choice.

My instinct is to do the following:

• 4.7.1-3.5-windowsservercore-ltsc2016
• 3.5-windowsservercore-ltsc2016, 3.5

This approach partially mitigates the size increase. The idea is basing the 4.7.1-3.5 image on the 4.7.1 image. If you already have that image, then pulling this image is much cheaper than it otherwise would be. It also reduces the significant discontinuity that exists with the 3.5 image, today. If ASP.NET had a scenario that needed 3.5, then they would depend on this new tag and it would align with their other scenarios pretty well.

[MichaelSimons]

Would like to get community feedback before proceeding with this proposal. If anyone has a scenario that would benefit from this, please let us know.

[MrSapps]

I am trying to use this containers to build apps that use tlbimp from an older sdk which requires .net 3.5 while the most of the code base is actually targetting 4.7.1.

If the 3.5 image doesn't include the latest framework how about providing instructions on how to get .net version X.Y.Z into a container so people can create a container with whatever strange mixture of framework that they require?

[NasAmin]

I have a similar scenario where majority of our projects are using dotnet framework 4.x but some projects require 3.5.

Either an image with 3.5 and the latest frameworks or instructions on how to install the latest.net framework in a 3.5 Container

Regards

Nas

[vgpopescu28]

I also have a scenario where I have a big solution and some of the projects(2-3 out of ~30) use 3.5. An image with 4.7.1 containing also 3.5 would be life saving. Any ideas of workarounds on this untill then?

[MichaelSimons]

@LemonJuice281 - The workaround would be to build your own image. You can easily do this by starting with the microsoft/dotnet-framework:3.5 image and then add 4.7.1 in your own Dockerfile (or vice versa). You can simply copy the 4.7.1 ltsc2016 Dockerfile and change the base image to the microsoft/dotnet-framework:3.5 image.

[MichaelSimons]

I would like to call out that the 3.5 builder images support both 3.5 as well as 4.7.1. Additionally the 3.5-windowsservercore-1709 runtime image supports 4.7.1 because it is based on 1709. 1709 comes with the 4.7.1 runtime.

As noted in the original description, this is only an issue for the ltsc2016 runtime.

[lavahot]

Any progress on this? I'd kill for a 3.5/4.6.2/4.7.1 container.

[MichaelSimons]

@richlander - let's chat about this and make a decision.

[noaksx3]

We are currently in the process of containerizing a bunch of WCF apps. Unfortunately, they are running on .NET 3.5, so if there is anyway to include 3.5 in a server image that would be awesome.

[mthalman]

We are currently in the process of containerizing a bunch of WCF apps. Unfortunately, they are running on .NET 3.5, so if there is anyway to include 3.5 in a server image that would be awesome.

@noaksx3 - Are you specifically asking for WCF images for .NET Framework 3.5? If so, that's a separate issue from this one (feel free to log it). Otherwise, it's not clear to me what you're asking for and how it relates to this issue.

[noaksx3]

Perhaps I don't understand the issue then. I thought this thread was pertaining to adding .NET Framework 3.5 to Windows Server Docker images.

[mthalman]

@noaksx3 - No, it's about adding additional .NET Framework versions to the 3.5 images we already do have. When you say "Windows Server" Docker images, what are you referring to exactly? We already do have 3.5 images for Server Core: https://hub.docker.com/_/microsoft-dotnet-framework-runtime. Or are you wanting this for the full Windows images: https://hub.docker.com/_/microsoft-windows?

[noaksx3]

I believe this may be what I am needing: https://hub.docker.com/_/microsoft-dotnet-framework-runtime

Thank you for your quick replies.

[sijoxavier89]

Is this implemented?