移植到.NET Core，整合各平台更简单

  • Article

[原文发表地址]:  Making it easier to port to .NET Core

[原文发表时间]: May 27, 2016

 

在我的上一篇文章中，我谈到了关于移植到.Net Core， 并且也恳请大家能给我们一些关于他们的经历和我们有待提高的方面的一些反馈。

这点燃了我们用户的交流热情。

基于这些讨论以及我们与第一和第三方伙伴合作的经验，我们已经决定要通过统一与其它.NET平台的核心API来简化移植工作，尤其是对于.NET框架和Mono/Xamarin之间。

在这篇博客，我将会谈到我们的计划，包括怎样开始以及何时会开始这项工作，以及这些对已有的.NET核心用户的意义。

 

回顾.NET Core

.NET Core平台从希望建立一个现代化、模块化、本地应用程序和跨平台的.NET stack进化而来。促使该业务目标产生的动力在于为全新的应用程序类型（例如 触控式UWP应用程序）或现代的跨平台应用程序（例如ASP.NET core web站点和服务）提供一个整合的stack。

我们即将发布.NET Core 1.0，同时我们已经成功开发了一个功能强大的和跨平台开发stack。.NET Core 1.0开创了把.Net 推行到所有平台的先河。

虽然.NET Core在我们所制定的情境中运行良好，但它只提供了相对于其他.NET平台较少的技术，尤其是相对于.NET Framework来说。其一是因为不是所有东西都是以跨平台做为目标来开发的，其二是我们把一些我们认为不必要功能给删除了。

我们也清楚如果要学习并使用.NET Core，这需要.NET开发人员去花费大量的时间来进行移植。

为用户提供一个全新的API肯定是不错的，但是这种作法彷彿变相的惩罚了长年以来一直使用微软 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的展望

在2016的开发者大会上，Scott Hunter 展示了如下的幻灯片：

01

我们想要展现给各位的理念是：

无论你需要创建一个桌面应用程序、手机应用程序、一个网站，还是一个微服务：你都可以依靠 . NET来试下。代码共享是很容易的，因为我们提供了一个统一的BCL。作为一个开发人员，你只需专注于特定的用户体验和你的开发平台上的那些功能和技术。

 

我们想要这样实现这些理念:我们将为应用程序提供跨所有平台的核心基类库（BCL）的源代码和二进制的兼容性。核心基类库包括mscorlib, System, System.Core, System.Data, 和System.Xml，以及那些不依赖特定的应用程序模型和不依赖特定的操作系统执行的类库。

无论你是面向.NET Core1.0的surface（基于System.Runtime的surface），还是即将发布的包含扩展API的.NET Core版本（基于mscorlib层面），现有的代码都会继续运行。

使现有代码便捷地扩展到库和NuGet包中。不论所使用的是mscorlib还是System.Runtime，都包括便携式类库。

下面是几个新增功能的例子，可以使你应用.NET Core的时候更容易些：

  • 反射会与.NET Framework里的相同， 不需要用GetTypeInfo(),可以再次使用.GetType()真是太好了
  • Types将不再会缺少因为清理原因而已经删除的成员，（Clone()，Close()，Dispose(),旧的APM API）
  • 二进制序列化（BinaryFormatter）将会再次可用

我们的corefx GitHub仓库里有计划新增的完整列表。

 

这对.NET Core意味着什么呢？

从与我们在社交媒体社区里的讨论中了解到，似乎有人担心这些增加的API会对.NET Core的体验大打折扣。事实并非如此。我们给.NET Core的绝大多数投入，使它可以被本地流行的应用程序，XCOPY配置所采用，也使我们可以有一个超前（AOT）的编译器工具链，同时使开源代码和跨平台保持不变。对于那些附加功能和性能改进方面的情况也是一样的，比如那个新的Kestrel网络组件体验也很好。

最初，我们设计.NET Core时，我们谈过关于模块化和付费使用的话题，这意味着在停止使用产品时，必须清空磁盘空间。我们相信我们可以在不严重损害兼容性的情况下实现这些目标。

起初，我们计划在小的类库中通过手动划分功能的过程来实现最低限度的磁盘空间使用，我们知道，用户也喜欢这样。现在，我们将会提供一个更明确链接工具，提供比任何手动过程所提供的更好的存储方式，这与Xamarin开发人员当前的使用方式是类似的。

 

时间表和进程

扩展.NET Core API的工作将会在我们发布.NET Core 1.0之后进行。这样的话，那些使用.NET Core开发的产品将能够顺利部署完。

在接下来的几周， 你会在我们corfx GitHub资源库中看到我们发布的更多的计划及细节。我们首先要做的事情之一就是发布一组API的参考，列出我们计划提供的API。这样在代码移植时，你可以决定你是否想要使用.NET Core 1.0还是会等待新的API的来临。我们也会列出我们不打算提供的API。目的是为我们的用户提供一个控制板以方便检查项目的状态和目标。

这是相比于我们跟进.NET Core 1.0进程方面一个很大的改进了，因为那时我们公布很多的内部进程。

最后，我们计划在 NuGet上推出更多的 .NET Core API 更新，这些更新会是渐进式的。这样的话，你不用等待所有的API完成以后再使用它们。同时，这也使得我们可以结合你的反馈信息来更好的进行兼容。

在下一周我们将会在Corefx资源库上发布更多的细节。也许你会在本博客里看到一些状态的交流和一些关键性进展。

敬请期待我们更多的信息吧！