 英文原文：Making it easier to port to .NET Core 在前篇文章中我提到了如何移植 .NET Core，并邀请使用者们不吝啬的回报您的使用经验和改进意见。 这项措施带动起了非常多使用者之间的讨论。 根据这些讨论的重点和我们与第一与第三方伙伴合作的经验，我们决定把核心 API 跟其他 .NET 平台，主要是 .NET Framework 和 Mono/Xamarin，做一次整合，借此来大幅简化移植 .NET Core 的功夫。 在此篇文章中，我会介绍我们的计划、我们将会如何达成这个目标、预计的上市时间，以及这对现在 .NET Core 使用者的意义。 回顾 .NET Core .NET Core 平台 起始于微软对于开发者们想要研发一个现代化、模组化、app-local、并且能够跨平台的 .Net stack 所推出的产品。这项产品背后的商业目标是希望可以提供一个整合的 stack 给全新的应用程式(例如：触控型 UWP 程式) 或者现代跨平台程式(例如：ASP.NET Core 网站与服务)。 在我们即将推出的 .NET Core 1.0 中，我们成功的开发了一个强大的跨平台开发 stack。.NET Core 1.0 开创了把 .NET 推行到所有平台的先河。 虽然 .NET Core 在我们所制定的情境中运行良好，但不能否认的是它相较于其他市场上的 .NET 平台来说，可兼容的程式较少。相较于 .NET framework 时此情况尤其明显。一部分是因为不是所有东西都是以跨平台做为目标的情况下开发的，另一部分也是因为我们把一些我们认为不必要功能给删除了。 种种原因之下，我们了解到如果想要学习并使用 .NET Core，现役的 .NET 开发者必须花费很长一段时间来移植它。 当然，直接重新编一个新的 API 给新的客户也是一个不错的方案，但是这种作法彷彿变相的惩罚了长年以来一直使用微软 API 与技术的忠实客户。我们是想要把 .NET 平台变得更加强大，并推广给更多的开发者，但是我们并不能漠视现有使用者的权益。 Xamarin 在这一点上就做得非常好。他们使 .NET 开发者们轻松地在 iOS 和 Android 手机上开发行动程式。让我们来看看 iOS，iOS 其实跟 UWP 有许多的相似之处，例如对终端使用者经验的高度重视和对静态编译的要求。Xamarin 跟 .NET Core 不同的地方在于， Xamarin 并没有重新构想 .NET Stack。 Xamarin 把 Mono 整套搬过来，删去了应用程式模型元件 (Windows.Forms, ASP.NET)，加入了 iOS 的元件，再改动了一些细节使其适用为内嵌使用。由于 Mono 和 .NET framework 本质上非常相似，经过这种处理方式之后的 API 是非常容易被现役 .NET 使用者学习与接受的，并且使移植现有的代码到 Xamarin 更为轻松。 当初在构想 .NET 的时候，我们最重要的核心理念就是希望可以使开发者更有生产力以及协助他们撰写更严谨的代码。我们设计 .NET 能在更丰富的领域和情境中帮助开发者，从桌面和网站应用程式，到微服务、行动应用程式、甚至游戏的研发。 为了实现我们的核心理念，开发出一个统一的核心 API，并使其可以在任何条件下使用是必要的。一个统一的核心 API 可以使开发者们简单的实现代码共享横跨不同的工作量，使每一位开发者的专长可以得到最好的发挥 ──写出最好的服务与使用者体验。 .NET Core 的展望 在 Build 2016, Scott Hunter 即展示了下列投影片:
我们想要展现给各位的理念是： 不论您是想要写桌面应用、行动 App、网站，又或者是微型服务，您都可以使用 .NET 来帮您达成您的目标。也因为我们提供统一的 BCL，代码共享将会是一件非常简单的事情。作为一个开发人员，您可以专注在功能与技术对应至您选择的使用者体验与平台。 我们想要这样实现这些理念：我们将会为以核心基础类别库 Base Class Libraries （BCL）为目标的应用程式提供原始码和二进位码相容性（binary compatibility）， 并保证在所有平台上运作方式的一致性。基础类别库（BCL）就是那些存在在 mscorlib、System、System.Core、System.Data、System.Xml，而这并不限定特定的应用程式模型和作业系统实作。 不论你将目标放在 .NET Core 1.0 的 surface（以 System.Runtime 为基础的 surface），还是在即将释出有扩充 API （以 mscorlib 为基础的 surface）的 .NET Core 版本，你目前的代码都将可以继续使用。 我们承诺简化将现有代码移植，也将同样保证在函式库与 NuGet 套装软体上。当然包含可携式类别函示库 （portable class libraries）无论他们使用的是 mscorlib 或是 System.Runtime。 这裡有几个有关这次新增的例子可以让你使用 .NET Core 起来更为顺手：
可以到我们 corefx GitHub 的套件库查看更完整的计划新增名单。 对 .NET Core 的意义 从我们跟社群的对话当中我们瞭解到他们的疑虑，使用者们担心这些新增的 API 功能会使得 .NET Core 体验大打折扣，这完全是个误解。我们对 .NET Core 绝大多数的投入， 不论是能以 app local 的方式推出，还是 XCOPY deployment, 又或者是我们的 AOT 编译器工具链，其开源与跨平台的理念是不变的。这同样适用于所有额外的功能和我们对效能的改进，例如新的网路组件 – Kestrel。 一开始当我们在设计 .NET Core 时，就强调模组化以及付费使用的概念，这表示您只需要消耗最终使用之功能的磁碟空间。我们相信我们仍然可以实现这些目标而不会对相容性问题造成太大的影响。 最初，我们仰赖将功能分割在微小的函式库中来最小化程式的磁碟利用率，而我们也知道用户喜欢这一点。现在，我们将提供一个比其他手动程序还要更为精确、更好的储存空间的链接工具。这是类似于 Xamarin 开发者现已使用的方式。 时程与流程 在我们推出 .NET Core 1.0 RTM 后，我们将开始着手扩充 .NET Core 的 API 介面。如此，持续追踪 .NET Core 的你们即可部署至生产环境。 在未来几周，您可以在我们的 corefx GitHub 看到更多详细资讯与计划。首先我们会做的就是释出一系列 API references，列出我们将会推出的 API，那么当您在移植代码时，您就可以有所依循来决定是否要跳转到 .NET Core 1.0 或是等待即将推出的 APIs。同时，我们也会宣布哪些 API 我们不打算推出，我们希望能为我们的用户提供一个看板，以查询专案的状态与目标。 这次将会是对我们为 .NET Core 1.0 做准备所遵循的流程的一大改善，前次发表因为内部流程分享不够公开而造成的不圆满，将在这次修正。 最后，我们计划在 NuGet 上推出更多的 .NET Core API 更新。这些更新会是渐进式的，亦即是我们将会扩充现有的 API 功能，并同步推出更多的 API。这样一来，使用者们可以得到好处，不用等到 API 完全更新结束才开始使用。这同时也可以让我们把各位对于运作方式的意见与回馈加入我们的更新中。 在接下来的几周内，我们将会在 corefx 套件库公布更多的资讯。你可以在这个部落格讨论相关状态以及所有的重大决策。 |
