虽然 .NET 8 为新的应用程序和应用程序模式提供了显著优势，但对于许多现有方案，.NET Framework 将继续是一个不错的选择。
将现有应用程序直接迁移到 Windows Server 容器
你可能希望仅使用 Docker 容器来简化部署，即使未创建微服务。 例如，你可能想要使用 Docker 改进 DevOps 工作流—容器可以提供更好的隔离测试环境，并且还可以在迁移到生产环境时消除因缺少依赖项而导致的部署问题。 在此类情况下，即使部署整体应用程序，对当前 .NET Framework 应用程序使用 Docker 和 Windows 容器也有意义。
在大多数情况下，不需要将现有应用程序迁移到 .NET 8;可以使用包含传统 .NET Framework 的 Docker 容器。 但是，建议的方法是在扩展现有应用程序时使用 .NET 8，例如在 ASP.NET Core 中编写新服务。
使用第三方 .NET 库或 NuGet 包不适用于 .NET 8
第三方库快速采用 .NET Standard，使代码在所有 .NET 风格（包括 .NET 8）之间共享。 使用 .NET Standard 2.0 及更高版本，不同框架之间的 API 图面兼容性已显著增加。 更重要的是，.NET Core 2.x 和较新的应用程序还可以直接引用现有的 .NET Framework 库（请参阅支持 .NET Standard 2.0 的 .NET Framework 4.6.1）。
此外， Windows 兼容性包 扩展了适用于 Windows 上的 .NET Standard 2.0 的 API 图面。 此包允许将大多数现有代码重新编译到 .NET Standard 2.x（几乎没有修改）在 Windows 上运行。
但是，即使自从 .NET Standard 2.0 和 .NET Core 2.1 及更高版本以来取得了显著进展，在某些情况下，某些 NuGet 包仍然需要通过 Windows 运行，并且可能不支持 .NET Core 或更高版本。 如果这些包对应用程序至关重要，则需要在 Windows 容器上使用 .NET Framework。
使用不适用于 .NET 8 的 .NET 技术
某些 .NET Framework 技术在 .NET 8 中不可用。 其中一些可能在更高版本中可用，但其他版本不适合 .NET Core 面向的新应用程序模式，可能永远不会可用。
以下列表显示了 .NET 8 中未提供的大多数技术：
ASP.NET Web 窗体。 此技术仅在 .NET Framework 上可用。 目前没有计划将 ASP.NET Web 窗体引入 .NET 或更高版本。
与工作流相关的服务。 Windows Workflow Foundation （WF）、工作流服务（WCF + 单个服务中的 WF）和 WCF 数据服务（以前称为 ADO.NET 数据服务）仅在 .NET Framework 上可用。 目前没有将其引入 .NET 8 的计划。
除了官方 .NET 路线图中列出的技术外，其他功能还可以移植到新的 统一 .NET 平台。 可以考虑参与 GitHub 上的讨论，以便听到你的语音。 如果认为缺少某些内容，请提交 dotnet/runtime GitHub 存储库中的新问题。
使用不支持 .NET 8 的平台或 API
某些Microsoft和第三方平台不支持 .NET 8。 例如，某些 Azure 服务提供尚未在 .NET 8 上使用的 SDK。 大多数 Azure SDK 最终应移植到 .NET 8/.NET Standard，但有些可能不是出于多种原因。 可以在 Azure SDK 最新版本 页中看到可用的 Azure SDK。
同时，如果 Azure 中的任何平台或服务仍不支持 .NET 8 及其客户端 API，则可以从 Azure 服务或 .NET Framework 上的客户端 SDK 使用等效的 REST API。
将现有 ASP.NET 应用程序移植到 .NET 8
.NET Core 是 .NET Framework 向前迈出革命性的一步。 它提供许多优势，优于 .NET Framework，从生产力到性能，以及从跨平台支持到开发人员满意度。
