提问人：user5855178 提问时间：11/13/2023 最后编辑：marc_suser5855178 更新时间：11/14/2023 访问量：167
Web 服务器上是否需要 .NET 6、.NET 7 和 .NET 8？
.NET 6, .NET 7, and .NET 8 required on webservers?
问：
我工作场所的 Web 服务器目前为 .NET 6。
管理层要求我在 .NET 8 可用时安装 .NET 8 并删除 .NET 6...而不是安装 .NET 7。
我们现在有 3.1、5 和 6 编译的产品，并且所有 .NET 版本都安装到了 6 级。
这有意义吗？
据我了解，我们仍然需要这些服务器上的旧版本的 .NET 才能在较旧的 .NET 级别上运行 NuGet 依赖项。
它是免费软件，无论如何我都看不出安装它有什么坏处。
任何人都可以确认跳过或删除 .NET 6 或 7 并且仅在 Web 服务器上运行 .NET 8 是否存在任何风险？
这难道不会破坏需要旧版本才能运行的产品吗？
在管理层看来，我们应该删除所有旧版本，只安装最新版本。在我看来，这似乎是一种风险。
答：
6赞
Joel Coehoorn
11/13/2023
#1
这有意义吗？
算是吧。我会一点一点地解释。
我们现在有 3.1、5 和 6 编译的产品，并且所有 .NET 版本都安装到了 6 级。
管理层要求我......删除 .NET 6。
他们没有要求你删除 3.1 或 5。只有 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 并且仅在 WebServer 上运行 .NET 8 是否存在任何风险？
跳过 7 没有风险，但如上所述，过快删除 6 有风险。
这难道不会破坏需要旧版本才能运行的产品吗？
是的，但这些旨在在大多数情况下快速、轻松地进行更新。只要开发团队知道任务，你给他们合理的时间来调整，并且你以一种允许合理的变更管理的方式解释管理指令，你就可以做到这一点。
在管理层看来，我们应该删除所有旧版本，只安装最新版本。在我看来，这似乎是一种风险。
我同意有风险。最新版本有时会出现问题。我也同意管理层的观点。由于 Core（与 Framework 不同），.NET 生命周期现在很短，您应该相当快地关注每个新的当前（或长期支持/LTS）版本。我希望看到的是，在进入新版本之前，每个新版本都有 6 到 8 周的延迟进行开发测试。
这意味着您还需要一个真正的 QA 环境......实际上，至少有 2 个独立的 QA 环境：1 个用于模拟生产环境，因此您有一个准备好测试“常规”应用程序更新的地方，另一个允许与生产环境不同的环境，您可以在其中测试 .NET 版本升级和打包部署/更改等内容。
评论
1赞
Alexander Zaldostanov
11/14/2023
根据我的理解，有旧的 Nuget 包（在每个项目中）仍然引用 .net core 3.1 和 5 版本，它们将不起作用，始终建议具有向后软件兼容性，如果我错了，请纠正我。
1赞
Alexander Zaldostanov
11/14/2023
（尽管可能存在运行时问题。=>这是我关心的问题
2赞
Joel Coehoorn
11/14/2023
我的理解是 NuGet 包必须设置它们支持的 .Net 版本（可以是多个版本），而 .Net 构建系统将验证这一点。诀窍是定义通常是“X 版本或更高版本”，理论上 X+1 版本可以发布并打破这一点。然后，仍然允许构建，并且问题直到运行时才会显示。但这就是我们测试并进行 QA 的原因。
1赞
Alexander Zaldostanov
11/14/2023
你能看看我下面的帖子和图片吗？
2赞
Alexander Zaldostanov
11/14/2023
#2
我正在扩展我的答案，因为我无法将图像粘贴到评论中 以上部分
这是一个非常流行的包，它仅支持 .net core 5.0。我们正在迁移
到 .net core 8，Swashbuckle NuGet 包不支持该版本。
[请注意，依赖项选项卡中有 .net core 7 依赖项]
评论
1赞
Joel Coehoorn
11/14/2023
不要个人使用此标记，但如果将鼠标悬停在顶部的蓝色 .NET 5.0 标记上，则会显示“.NET 5.0 或更高版本”（与 .NET Core 3.0 相同）。包也可能不再维护，后来的 .Net 版本引入了重大更改，但包上的兼容性设置表明它应该允许生成。
1赞
Joel Coehoorn
11/14/2023
此外，当您查看“依赖项”选项卡时，.NET 7 下的列表并不意味着包依赖于 .NET 7。这意味着，“当你使用 .NET 7 时，这些是包将引入的依赖项。没有 .NET 8，因为 .NET 8 尚未完全发布，但我希望该包在发布后不久更新为 .NET 8 的部分。
0赞
user5855178
11/14/2023
#3
我要感谢大家的精彩讨论。
我认为这是一件非常重要的事情，但没有多少人在谈论它。
Microsoft的这篇文章似乎表明删除较旧的NET版本或跳过它们是安全的：
尽管Microsoft表示保留旧版本存在风险，但他们没有评论跳过级别的风险。
我认为删除一个版本实际上与跳过它相同。
我宁愿不必从 MS 所说的话中推断出我的答案。我宁愿Microsoft真的写出一个明确的答案。
但有推论总比没有好......
你们怎么看？
评论
0赞
user5855178
11/14/2023
另一个有趣的细节是：如果你安装一个新的NET关卡，安装程序不会删除旧的关卡。如果不需要旧级别，那么为什么 MS 不隐式删除它？如果您升级到更高的次要 NET 级别版本，MS 甚至不会删除相同的运行时级别。我在 7.0.401 上安装了 7.0.403.。MS 只是允许它们并排安装。如果不需要旧版本，为什么允许这样做？如果不需要更早的级别，为什么 Microsoft 允许并行安装？
1赞
Joel Coehoorn
11/14/2023
“如果不需要旧级别，那么为什么MS不隐含地删除它？”因为新版本的安装程序不知道任何可能正在使用旧版本的应用程序（复数）。您可以让应用程序在同一系统上同时运行两个版本。事实上，这很常见，因为当新版本发布时，组织通常会一次更新、测试和部署一个应用程序。在这种情况下，您需要保留旧的 .NET 版本，直到每个应用程序都迁移完毕。
1赞
Joel Coehoorn
11/14/2023
补充：请记住，.NET 不会作为应用程序的一部分嵌入，应用程序也不会以任何方式向 .NET 运行时注册。但是，应用程序被编译为需要特定版本的 .NET。（可以将 NuGet 库配置为支持一系列版本，但应用程序会编译为特定版本）。因此，当您安装或更新 .NET 时，它无法了解系统上可能仍需要以前版本的任何其他内容。
1赞
Joel Coehoorn
11/14/2023
正确的是，您需要 .NET 3.1 来运行 3.1 应用程序，需要 .NET 6 来运行 6 应用程序等，但同样：期望您了解正在运行的应用程序，并且您花时间更新它们以使用新版本，而不是继续运行（并保留）旧版本。再说一遍：为此所需的代码更改很少甚至没有。只需在生成计算机上安装新的 SDK，更新项目文件中的一行，然后重新生成应用即可。这很重要，因为旧版本现在停止获取安全更新的速度要快得多。
1赞
Joel Coehoorn
11/14/2023
月份？也许几周。而且，如果到目前为止没有任何使用它，您绝对仍然可以省略 7 并直接转到 8。这里真正要带回家的另一件事是，仍然使用 3.1 或 5 是不行的，因为它们代表了潜在的安全问题。但你并不是唯一一个在这方面落后的人。对 Core 的更改代表了应用程序支持生命周期的整个理念的改变，而这种理念尚未被所有地方所吸收。
评论