移植到。NET Core 不是一个不可低估的任务。在将任何源代码移植到。NET Core，您应该努力理解您的代码库、它的体系结构以及您拥有的所有依赖项。然后你需要分析是否移植到。NET Core 会给你任何好处，如果有，你打算如何利用它们。只有在这个初始阶段之后，你才能确定哪些部分的代码应该或者不应该被移植，甚至哪些部分的代码可以完全重写。NET 核心。的 RTM 版本。NET Core 将具有以下应用程序模型:

• ASP.NET 核心应用和服务
• 通用视窗平台(UWP)应用程序
• 控制台应用程序

让我们看看。NET 团队为每种工作负载推荐。我们将介绍移植的原因以及确定好的或坏的移植候选者的指标。

ASP.NET Core app and service:迁移现有 ASP.NET 应用的主要原因是为了跨平台运行。ASP.NET 核心最好的基础是一个使用 MVC、网络应用编程接口或两者兼有的网站，而不太合适的候选是所有那些使用网络表单构建的网络应用程序，因为在 ASP.NET 核心不支持 WinForms。

Universal Windows Platform Apps: 你想把你的应用移植到 UWP，因为它统一了视窗设备系列，从个人电脑到平板电脑、平板电脑、手机和 Xbox。它现在还包括无头物联网(IoT)设备。但是，如果您的应用程序是一个利用 Windows 窗体或 WPF 的丰富桌面应用程序，它将不是理想的，因为这两种技术都不支持。NET 核心。另一方面，如果你的目标是 Windows 8 或 Windows Phone 8.1，你已经完成了:这些都是。NET 核心应用程序。如果你维护 Windows Phone Silverlight 应用程序，你就相当接近了。Silverlight 应用程序应该是一个很好的候选，因为 API 集在很大程度上基于 Silverlight 中可用的内容:大多数 API 要么在中可用。NET Core 还是成为了 WinRT APIs。

Console Applications: 你应该考虑使用的最大原因之一。用于控制台应用程序的 NET Core 是因为它允许瞄准多个操作系统(Windows、OS X 和 Linux)。另一个强有力的理由是。NET Native for console 应用程序最终将支持以最小的依赖关系生成独立的单文件可执行文件。几乎任何控制台应用程序都是移植的好选择；它只取决于你的依赖。

那个。NET 团队一直在非常努力地向。NET Core 尽可能无缝。正因为如此，他们不断为自己的工作提供见解。您可以阅读更多关于移植到。在这里和在 CoreFx GitHub 存储库上可用的官方文档上。