Add .NET Framework latest to 3.5 images

[richlander]

We've been creating images for .NET Framework latest. It stands to reason that the 3.5 images should include .NET Framework latest as well. It enables users to use the 3.5 image if they want all .NET versions to work in one image. This also applies to the .NET Framework builder image.

This is currently only a problem for the LTSC-2016 images.

[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.

[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?

[lavahot]

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

[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.