Repository navigation
Upgrade from net9.0 to LTS (or STS) image tag #56293
Description
The following Dockerfile(s) target a .NET version that's no longer supported.
This is an auto-generated issue, detailed and discussed in dotnet/docs#22271.
| Target version | End of life | Release notes | Nearest LTS TFM version |
|---|---|---|---|
net9.0 |
November, 10 2026 | net9.0 release notes | net10.0 |
- docs/core/diagnostics/snippets/resource-monitoring-with-manual-metrics/Dockerfile
- docs/core/diagnostics/snippets/resource-monitoring-with-manual-metrics/Dockerfile
- docs/core/diagnostics/snippets/resource-monitoring-with-manual-metrics/Dockerfile
- docs/core/diagnostics/snippets/resource-monitoring-with-manual-metrics/Dockerfile
Consider upgrading Dockerfile images to either the Standard Term Support (STS) or Long Term Support (LTS) versions.
If any of these Dockerfile(s) listed in this issue are intentionally targeting an unsupported version,
you can optionally configure to ignore these results in future automation executions.
Create a (or update the) dotnet-versionsweeper.json file at the root of the repository and
add an ignore entry following the
globbing patterns detailed here.
{
"ignore": [
"**/path/to/Dockerfile"
]
}
Activity
ShyneChikwapulo commentedon Oct 10, 2026
Hi, I'd like to contribute to this issue. Is it still open for community contributions? I can update the Docker image tags and check whether the sample's target framework needs to be updated as well. I'll keep the changes scoped to this sample.
BillWagner commentedon Oct 13, 2026
Thanks @ShyneChikwapulo
I'll watch for a PR.
ShyneChikwapulo commentedon Oct 13, 2026
Hi @BillWagner, I've opened PR #56393 for this issue. It updates the Dockerfile image tags (runtime and sdk 9.0 -> 10.0) and the project target framework (net9.0 -> net10.0).
While validating the change, I noticed the sample's Dockerfile references
ResourceMonitoring/ResourceMonitoring.csproj, but the project in this folder isresource-monitoring-with-manual-metrics.csproj, and there is noResourceMonitoring/subfolder. As a result,docker buildfails at the firstCOPYstep. This was already the case before my change (that line is unchanged frommain), so I've kept PR #56393 limited to the version upgrade.Would you like me to open a separate issue and PR to fix the Dockerfile paths afterward?