概述
下面是 ASP.NET Core的时间表和路线图. 注意日期和特性都可能更改.
作为.NET Core这么大的一个项目,很难准确预测每一个计划的是否有变动.
即便如此，我们还是计划公开和透明的实施，以便我们的用户可以有正确的期望值，
并为我们的用户自己在技术实施时有更好的打算和安排
发布时间表
| Release | 发布日志 |
|---|---|
| 1.1 | Q4 2016 / Q1 2017 |
| 1.2 | Q1 2017 / Q2 2017 |
Release 版本特性
1.1
- URL 重写中间件
- Response 缓存中间件
- 第三方DI支持的实现
- WebListener 服务器(Windows only)
- MVC filters中间件
- Tag Helpers
- View 预编译
- 基于Cookie的TempData provider 改进Azure
- App Service 启动时间改进
- App Service 日志provider
- Azure 密钥存储库 provider
1.2
- WebSockets
- SignalR 兄弟我等了两年了!(Linux不支持Websocket模式)
- Razor Pages (Views 不含 MVC controllers)
- Web API 安全
废除技术概述
虽然有一部分现有的.NET应用程序，尤其是基于ASP.NET MVC的应用程序将能够比较简单地迁移至.NET Core，但另一部分.NET应用在迁移过程中可能会遇到某些问题。有一些问题是显而易见的，例如从WinForms或WPF应用迁移至 Universal Windows Applications（UWP），而另一类些问题则更加微妙，这关系到.NET Framework核心功能中更底层的实现。
反射
反射API在.NET Core中产生了很大的变化。正如在WinRT中的应用方式一样，反射功能被分成一种轻量级的版本以及一种开销更大的版本。来自微软的Immo Landwerth写道：
在推出.NET Native时，我们利用了一种技术，它允许我们将应用与框架和第三方依赖进行静态链接。要使这种链接功能可行，它必须能够找出在你的应用没有使用的那部 分框架功能。对于其他技术，例如C++来说，这一过程并不复杂，因为这种系统并不具备反射这样的动态能力。当然，在.NET Native中仍然支持反射，但我们希望让这个平台尽可能地降低开销，也就是说不必为你所不需要的特性增加开销。这一点对于反射来说尤其明显，因为它对于 运行时以及编译器能够基于静态信息进行哪些操作施加了极大的限制。
因此，在理想的情况下，反射应当作为.NET Core中一个可选的组件，你可以选择在自己的应用中完全放弃使用它。麻烦在于，System.Object在进行Object.GetType()操作 时将对反射产生依赖。为了打破这种依赖，我们决定让System.Type不再展现整个反射类型信息，而仅仅展示类型的名称。这也意味着在.NET Core中的System.Type不再包括GetMembers()等API，但仍然会暴露Name等API。
通过一个名为GetTypeInfo的扩展方法，可以得到在一般情况下能够从Type对象中获取的信息。TypeInfo类所包含的信息没有原来那么丰富，但微软最近决定在.NET Core中重新引入一部分反射API，这部分变更是超出原先计划之外的。
为了使代码更容易进行移植，.NET 4.5及之后的版本提供了对TypeInfo的某种支持，它与在.NET Core中使用的版本相类似。
App Domain
App Domain在CoreCLR中得以实现，但没有在.NET Native中实现。由于对App Domain的实现需要大量的运行时特性支持，因此目前还没有任何对它的支持计划。“对于代码的隔离，我们建议通过进程或容器实现。而对于程序集的动态加 载，我们建议使用新的AssemblyLoadContext类。”
Remoting
现如今，已经很少有开发者还能够记起Remoting库的存在，更不要说如何使用它了。即使还有人在使用，他们也一直在抱怨它的性能、高复杂性以及总体表现的脆弱性。
如今，多个.NET应用在同一台机器上的通信基本都被WCF所取代，后者能够带来更好的性能，可用于管道或内存映射文件。对于跨机器的通信，微软推荐“使用一种低开销的纯文本协议，例如HTTP”。因此，微软并没有在.NET Core中支持Remoting的计划。
序列化
.NET Core将支持大多数序列化器，例如数据契约序列化、XML序列化、JSON.NET以及protobuf-net。而一个被排除在外的重要角色是二进制序列化。
通过这十年来的经验，我们终于了解到序列化是一项非常复杂的任务，支持序列化的类型在兼容性方面要面对沉重的负担。因此，我们已经决定让序列化 成为一种协议，它将在可用的公开API的基础上实现。然而，二进制序列化的实现需要对类型本身的深入了解，因为这种方式可以对整个对象图进行序列化，甚至 包括私有的状态信息。
沙箱
从理论上说，沙箱是一种优秀的思想，它允许部分信任代码以安全的方式执行。但在实践中，要想正确地应用它非常困难，哪怕是一点点微小的错误，也会导 致安全性方面的漏洞。Immo Landwerth还表示，它“使实现变得更加困难，并且经常会给未使用沙箱的应用的性能带来负面影响。”
推荐的替代方案是使用独立的进程，通过一个具有有限权限的用户帐号运行这些进程。通过这种方式，运行时不必重复进行一些开销较大的权限检查工作，因为操作系统已经为你完成了这方面的任务。
其他组件
微软正考虑将下表中列举的组件进行开源，并移植到.NET Core。
-
System.Data。虽然它的基础层功能，即提供者模型与SQL client 已经成为了.NET Core的一部分，但某些特性目前仍不可用，例如对于schema、DataTable和DataSet的支持。
-
System.DirectoryServices。.NET Core目前并不支持通过该组件与LDAP或活动目录进行通信。
-
System.Drawing。虽然从严格意义上来说，它应该属于一种客户端API，但还是有大量开发者在服务端通过绘图API实现缩略图或水印的生成。我们目前还不支持在.NET Core中使用这些API。
-
System.Transactions。虽然ADO.NET支持事务，但并不包括对于分布式事务的支持，后者包括氛围事务（ambient transaction）及资源征集（enlistment）的概念。
-
System.Xml.Xsl与System.Xml.Schema。.NET Core支持XmlDocument以及由Linq引入的XDocument，包括XPath在内。不过，目前还不支持XSD（XmlSchema）及 XSLT（XslTransform）。
-
System.Net.Mail。目前还不支持在.NET Core中通过这些API实现电子邮件的发送。
-
System.IO.Ports。.NET Core目前还不支持与串行化端口的通信。
-
System.Workflow。Windows Workflow Foundation（WF）目前在.NET Core中尚不可用。
-
System.Xaml。在开发UWP应用时，开发者将使用WinRT XAML API。因此，.NET Core目前并不支持托管XAML框架，后者包括解析XAML、并实例化描述对象图的功能。
你是否有兴趣帮助我们移植某个组件？.NET Framework实现的部分源代码已经通过MIT许可进行了开源，作为Reference Source的一部分。我们正在设法让社区能够对我们的移植工作提供支持。如果你愿意参与这一项目，请发送邮件至immol@microsoft.com。