Latest .NET 4.7.2 Images run into a tls error trying to install nuget

[lekxyy]

Describe the Bug

Since around the beginning of march 2024 (1-2 weeks ago), when I pull the latest .NET 4.7.2 image the following error is thrown:

No match was found for the specified search criteria
for the provider 'NuGet'. The package provider requires 'PackageManagement'
and 'Provider' tags. Please check if the specified package has the tags.

No changes were made in the dockerfile in the meantime.

Steps to Reproduce

Here is the dockerfile to reproduce the error from:

FROM mcr.microsoft.com/dotnet/framework/runtime:4.7.2

# install SQL-Server module
RUN powershell -Command \
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; \
Install-PackageProvider -Name NuGet -Force; \

Note: Tls1.2 is needed for it to work. - To be precise, it worked like that till 2 weeks ago.

Output of docker version

Client: Mirantis Container Runtime
Version: 20.10.0
API version: 1.41
Go version: go1.13.15
Git commit: 6ee42dc
Built: 03/11/2021 13:24:56
OS/Arch: windows/amd64
Context: default
Experimental: true

Server: Mirantis Container Runtime
Engine:
Version: 20.10.0
API version: 1.41 (minimum version 1.24)
Go version: go1.13.15
Git commit: 1e08f21e79
Built: 03/11/2021 13:23:32
OS/Arch: windows/amd64
Experimental: false

Output of docker info

Client:
Context: default
Debug Mode: false
Plugins:
app: Docker Application (Docker Inc., v0.8.0)
cluster: Manage Mirantis Container Cloud clusters (Mirantis Inc., v1.9.0)
registry: Manage Docker registries (Docker Inc., 0.1.0)

Server:
Containers: 62
Running: 1
Paused: 0
Stopped: 61
Images: 1128
Server Version: 20.10.0
Storage Driver: windowsfilter
Windows:
Logging Driver: json-file
Plugins:
Volume: local
Network: ics internal l2bridge l2tunnel nat null overlay private transparent
Log: awslogs etwlogs fluentd gcplogs gelf json-file local logentries splunk syslog
Swarm: inactive
Default Isolation: process
Kernel Version: 10.0 17763 (17763.1.amd64fre.rs5_release.180914-1434)
Operating System: Windows Server 2019 Standard Version 1809 (OS Build 17763.4974)
OSType: windows
Architecture: x86_64
CPUs: 8
Total Memory: 24GiB
Name: *******
ID: **********
Docker Root Dir: D:\dockerdata
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false

Questions

-Could you reproduce it?
-Did you find the cause of the behaviour?
-Is it a known bug?
-Is there a workaround?
-Is it known if/when it will be fixed?

[lbussell]

Hi @lekxyy, I took a quick look at your Dockerfile and I wasn't able to reproduce this issue. I tried with both mcr.microsoft.com/dotnet/framework/runtime:4.7.2-windowsservercore-ltsc2016 and mcr.microsoft.com/dotnet/framework/runtime:4.7.2-windowsservercore-ltsc2019. I'm able to confirm it's installed by running Get-PackageProvider -ListAvailable.

Since 4.7.2 is a multi-platform tag it would be good to confirm which image your build machine resolves, and make sure you pull the latest image. The multi-platform image that Docker picks differs based on your host operating system. You are running Server 2019 so you should get the ltsc2019 image mentioned above. Running ver in the container shows Version 10.0.17763.5576.

[lekxyy]

Hi @lbussell bussell, thank you for the quick answer! I'll look into it and give you an update of what happened.

[lekxyy]

Hi @lbussell I pulled the image with the latest tag - have tried that bevore, but didnt check the version in the container - and when i startet the container I got the following output:
Microsoft Windows [Version 10.0.17763.5576]

Dockerfile:
FROM mcr.microsoft.com/dotnet/framework/runtime:4.7.2-20240213-windowsservercore-ltsc2019

Then I tried to install nuget with the two commands i posted above and still got the same error.

---

But this doesnt mean that I'll get the same version when i use the 4.7.2 tag so I tested it.
Dockerfile: FROM mcr.microsoft.com/dotnet/framework/runtime:4.7.2
Container output: Microsoft Windows [Version 10.0.17763.5576]
Trying to install nuget, the error still occured.

---

Now the fact that it worked for you, made me think that maybe the problem lies within the host. So Im going to try it elsewhere as well.

[lbussell]

@lekxyy I would also try and see if you can reproduce this on the base image that we use for the runtime:4.7.2-windowsservercore-ltsc2019 image. It's mcr.microsoft.com/windows/servercore:ltsc2019-amd64 (Dockerfile). Since the 4.7.2 Runtime comes with Server 2019, we don't actually do much to the base image besides run ngen on the Runtime. If you can reproduce it there it's probably not an issue with the .NET Framework images but rather something might have changed in the base Windows Server image.

[lekxyy]

@lbussell Hi, I tried it with the mcr.microsoft.com/windows/servercore:ltsc2019-amd64 image and could reproduce the error.
That means that you're probably right and something changed in the base image. Is there a repo with old versions of the base image, where I could try the older versions, to see with which one it starts working, so that I can narrow down the search for the changes causing the error?

[lbussell]

@lekxyy, apologies as I thought I replied a few days ago. I recommend that you open an issue on the Windows-Containers GitHub repo: https://github.com/microsoft/Windows-Containers. The servercore repo on MCR also contains listings for old tags if you uncheck the "supported tags only" box: https://mcr.microsoft.com/product/windows/servercore/tags.

Also, we maintain a set of files with the versions and base images of all .NET container images we publish. This diff from our latest update should show you the old vs. new servercore image that we used - dotnet/versions@1793f8b#diff-996cead2bdecabe0a0763a0be97dd73a05415691f07da98004cdcd14e79c0e2eL612-R615 (you'll need to click "load diff" for it to jump to the correct line, or it's line 613-ish that you should be interested in if that doesn't work)

[lekxyy]

@lbussell thanks for the answer. I'll check the info provided, and if the problem remains, I'll open an issue on the Windows-Container repo.