这有道理吗？
算是吧。我会一点一点解释的。
我们现在有3.1、5和6版本的产品，并且安装了所有.NET版本，最高可达6。
管理层要求我.删除.NET 6。
他们没有要求你删除3.1或5。只有6。这将是一个问题，删除这些其他项目，如果有现有的应用程序仍在使用它们。
如果有一个应用程序仍然针对6，那么删除6将有问题，但这可能与更新这些应用程序有关。这对开发人员来说是一个很容易的更新-实际上不需要从6到8的代码更改。只需安装新的SDK，在项目文件中进行一行配置更改，然后重新构建它。（在.NET 5之前，情况并非如此，从Framework升级到3.1或5是一件痛苦的事情。但目前Core更稳定一些。）
.假设你所有的依赖也支持新版本。这可能会给工作带来麻烦。然而，库作者经常对beta和候选版本进行测试，以便在正式发布后很快获得支持。
在你的鞋子里，我会确保开发团队也意识到这个管理指令，并尽快安装8，然后推迟几周删除步骤，以确保他们有时间更新应用程序。
据我所知，我们仍然需要在这些服务器上运行旧版本的.NET，以便在旧的.NET级别上运行NuGet依赖项。
如果一个应用程序的目标是.NET 6，并且依赖于一个只支持.NET 5的NuGet包，应用程序将无法构建.你只需要担心开发团队实际针对的.NET版本。他们使用的任何NuGet包要么支持该版本的.NET，要么他们需要找到另一个NuGet包才能完成应用程序的构建步骤，更不用说将其部署到服务器了。
这是免费软件，我看不出安装它有什么坏处。
当然有：比如磁盘大小，这也会影响备份大小和恢复时间。还有环境复杂性。但最大的问题是安全问题，因为.NET 3.1和5正式结束了生命周期（不再接收安全补丁！）
有没有人能确认跳过或删除.NET 6或7，只在Web服务器上运行.NET 8是否有任何风险？
跳过7没有风险，但如上所述，过快删除6有风险。
这难道不会潜在地破坏需要旧版本运行的产品吗？
是的，但大多数情况下，这些更新都是快速、简单的更新。只要开发团队知道这个命令，你给予他们合理的时间来调整，并且你以一种允许合理变更管理的方式解释管理指令，你就可以做到这一点。
在管理层看来，我们应该删除所有旧版本，只安装最新版本。在我看来，这似乎是一个风险。
我同意存在风险。最新的版本有时会有问题。我也同意管理层的观点。自从Core（与Framework不同）以来，.NET的生命周期现在很短，你应该很快地跟踪每个新的当前（或长期支持/LTS）版本。我希望看到的是，在每个新版本发布之后，在进入新版本之前，有6到8周的开发测试滞后。
这意味着你还需要一个真实的QA环境.实际上，至少有两个独立的QA环境：一个模拟生产环境，这样你就有一个地方可以测试“常规”应用程序更新，另一个允许与生产环境不同，你可以测试.NET版本升级和打包部署/更改。

我扩展我的答案，因为我不能粘贴到上面的评论部分的图像

这是一个非常流行的软件包，它只支持.net core 5.0。我们正在迁移到.net core 8，这将不受Swashbuckle NuGet软件包的支持。

[注意，在依赖项选项卡中有.net core 7依赖项。]

我想感谢你们所有人的伟大讨论。
我认为这是一个非常重要的主题，但没有多少人在谈论它。
微软的这篇文章似乎建议删除旧的NET版本是安全的，或者跳过它们：
x1c 0d1x的数据
https：//dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core#：~：text= After%20support%20ends%2C%20we%20tool，and%20computing%20environment%20at%20risk。
虽然微软说保留旧版本有风险，但他们没有评论跳过级别的风险。
我认为删除一个版本实际上就等于跳过它。
我不希望从微软所说的话中推断出我的答案，我更希望微软真的写了一个明确的答案。
但有推论总比没有强...
你们觉得怎么样？