振奋人心啊

2019-12-09 16:19 来源:未知

这两天看到的.NET的新闻都好振奋人心啊!微软北美技术大会带来了好多好消息!

原文:

看到一篇博客园的文章,感觉太棒了。摘录下来。原文链接:

 

图片 1

  Part of the ASP.NET vNext initiative, ASP.NET MVC 6 represents a fundamental change to how Microsoft constructs and deploys web frameworks. The goal is to create a host agnostic framework that eliminates the dependencies on the legacy System.Web infrastructure.

英文原文:The Next Generation of .NET – ASP.NET vNext     

  ASP.NET MVC 6作为ASP.NET vNext解决方案的一部分,体现了一个根本性的改变——微软如何构建和部署web应用。它的目标是:创建一个宿主无关的框架,以便消除对传统的System.Web程序集的依赖。

感谢 中奖啦 和 白文 的激情翻译。

 

在微软北美技术大会(TechEd North America)上,我们宣布了下一代 .NET 的技术创新点。这其中最重要的就是 ASP.NET vNext。我们一直在对 .NET 的核心技术进行优化,尤其是在上个月举行的 Build 大会上发布的 .NET Native 预编译器和 .NET Next Generation JIT (“RyuJIT”)。

  Microsoft feels that System.Web needs to be removed because it is actually quite expensive. A typical HttpContext object graph can consume 30K of memory per request. When working with small JSON-style requests this represents a disproportionately high cost. With MVC 6 new design, the pre-request overhead drops to roughly 2K.

在上个月的 Build 大会上,我们宣布了 .NET 基金会。现在,我们正和超过 25 家基于社区的 .NET 项目和组织沟通,邀请他们加入该基金会。大家对 .NET 基金会的兴趣远超我们的预期,这是一个不错的开始。

  微软认为System.Web需要被移除,因为它在实际使用中相当昂贵。在每次请求中,一个典型的HttpContext对象图会占用30K内存。这与使用JSON通信相比,造成不成比例的高成本。MVC 6力求将“预请求”的开销下降到大约2K。

同样在 Build 大会上发布的还有 .NET Compiler Platform ("Roslyn") 。它包括一个全新的 C# 和 VB 的编译器以及一些将要添加到C# 6 中的新特性。该项目是一个托管在 codeplex 上的开源项目,并且已经接受了一个来自社区的 pull request。

 

Visual Studio 2013 Update 2 现在已经提供下载了,这次更新给使用 Visual Studio 的开发者带来了多个意义非凡的新特,包括针对 Window Phone 8.1 和通用的 Window 程序的工具。

  Included in MVC 6 is Web API and Web Pages, allowing Microsoft to remove a lot of the overlap between the three frameworks. One result of this change means that MVC will be self-hosting just like Web API 2 and SignalR 2.

在我们向前发展的同时,也要关注一下 .NET 当前的优势。目前,.NET 大约有 18 亿个有效安装。无论从哪方面来说,这都是一个非常大的数字,同时这也为你的程序提供了一个广阔的运行平台。

  MVC6中包含Web API,Web Pages,微软移除了框架中重复的部分,这种变化意味着MVC 6将是自托管的,如同Web API 2和SignalR 2。

TechEd 中 .NET 的公告

 

下面是我们在 TechEd 中分享的一些关于 .NET 的公告。

  In order to make deployment easier and more reliable, “vNext will support true side-by-side deployment.” Rather than being installed in the GAC, each MVC library needed for a given web site will be referenced like a normal developer-created DLL. “That means you can update your app without affecting other applications on the same server.”

  • .NET vNext
  • ASP.NET vNext (MVC, Web API and Web Pages 6; EF 7; SignalR 3)
  • .NET Framework 4.5.2
  • .NET Native Developer preview 2 – x86 support
  • .NET Next Generation JIT CTP 4 – supported on Windows 7
  • Better support for Xamarin in .NET PCL NuGet Packages
  • ApiPort API Portablity Analyzer
  • Client Libraries for Office 365 REST APIs

   为了使部署更容易和可靠,vNext将支持真正的并行部署。使用MVC 6构建网站时,站点依赖的程序集不会安装在GAC中而是和开发者创建的DLL类似。这意味着你可以更新你的应用,而不会影响同一服务器上的其他应用。

.NET vNext

 

.NET vNext 作为 .NET Framework 的下一个重要的发布版本,第一次被我们在 TechEd 上提及。我们在 TechEd 和 Build 大会上分享了下一个发布版本中的多个新特性和组件。 你可以使用 Roslyn compilers 来编译 C#6 和 VB,将 ASP.NET vNext 程序部署在服务器或者云端,使用 .NET Native 预编译器来编译你 Windows Store 上程序,并且可以享受由 Next Generation JIT 带来的更快的服务端或桌面程序。

Pay As You Go (现收现付)

  MVC 6 is built on a “pay as you go” philosophy. Each feature that you wish to use has to be explicitly turned on in the application startup routine. Even serving up static files requires calling IBuilder.UseStaticFiles.

  MVC 6的设计体现了“现收现付”理念。你希望使用的每一个功能都会在应用启动程序中开启。甚至提供静态文件需要调IBuilder.UseStaticFiles。

 

  The way this works is that each website needs to have a class named Startup and this class must have a method called “void Configure (IBuilder app)”. Inside this method you can call functions such as “app.UseServices” to enable features such as MVC.

  其工作原理是:每个站点都需要有一个名为Startup的类,这个类有一个方法“void Configure (IBuilder app)”方法。在该方法中可以调用你需要的功能方法,如“app.UseServices”,以便启动某些特性如MVC。

 

  Routing is also setup in the Configuration method. MVC 6 routes are similar, but not identical, to MVC 5 routes. For example, a question mark can be added to a fragment to make it optional in MVC 6. In MVC 5 you would use the UrlParameter.Optional value for the same effect.

  路由也在配置方法中进行设置。 与MVC 5的路由相比,MVC 6有些相似,但不完全相同。例如,在MVC 6中可以通过追加问号表示可选参数,而在MVC 5中,需要将其默认值定义为UrlParameter.Optional来达到相同的效果。

 

针对现在比较常见的服务端优先和移动端优先的开发需求,我们对 .NET 做了专门的优化。用户对移动端和云端 APP 有更高的性能需求,并且这些程序都运行在专门的硬件或虚拟环境下。我们为 Windows Store 程序提供了 .NET Native 预编译器,为云端程序开发了一个云端优化模式。

Azure and PowerShell Based Deployments (Azure部署和基于PowerShell的部署)

  Microsoft is still heavily pushing Azure as the standard way to deploy websites. But they have realized that developers are leery of publishing websites directly from Visual Studio. So instead they will generate PowerShell deployment scripts by default. These can then be edited inside Visual Studio, which now has basic tooling support for PowerShell.

  微软仍在很大程度上推动让Azure部署成为网站部署的标准方式。但他们已经意识到,开发者们都不愿意直接从Visual Studio发布网站。所以,作为替代,默认情况下会生成PowerShell脚本。在新版Visual Studio中,已经包含了一些PowerShell的基本工具,以便用户能够在Visual Studio里编辑那些生成的脚本。

 

.NET vNext 有一个专门为云端环境优化过的模式,该模式允许你在部署程序的时候连同他们所用到的 .NET Framework 的相关库一同部署(译者注:没有用到的库不会添加到里面)。由于 .NET 的运行时和框架中的库部署在了程序基础(app-basis)上。所以在同一台机器上,每一个程序可以运行不同版本的 .NET vNext,并且可以单独升级,互不影响。这些库已经被显著的优化、精简以便减少框架占用的空间,并且将会使用 NuGet 来发布。在这种模式下,和 WPF 以及 Window Forms 相关的一些库已经被移除了。

The Build Process Doesn’t Build (在生成过程中不会构建程序集)

  In ASP.NET vNext the build process does not actually build anything. No binaries are generated, it merely runs the type checker to ensure you don’t have any errors or warnings that need to be addressed. Instead the code is compiled on the fly in an as-needed basis, much like we already see with ASP.NET Web Pages. This allows for faster iterations, especially over large websites.

  实际上,ASP.NET vNext在生成过程中并没有构建任何东西。不生成任何二进制文件,它只是运行类型检查,以发现你代码的编译时错误和警告。作为代替,代码会在其被需要时,快速地被编译,这种按需编译代码的方式,很像我们所熟知的ASP.NET中的动态编译机制。这允许更快的迭代,尤其是在大型网站中。

 

  If you want actual binaries to be deployed on a server you need to run the package and publish command. Eventually this will offer several options from source code only, which will continue to compile on the fly, all the way up to natively compiled. The latter should have better performance, but could entail a much longer build process.

  如果你想将二进制的程序集部署在服务器上,需要使用发布功能。这种方式将有更好的表现,但也意味着更长的构建时间。

 

我们始终以跨平台的思想来开发这个模式,在开发过程中我们和 Xamarin 积极合作,以确保经过云端优化过的 .NET 程序可以运行在装有 Mono 运行时的 Mac 和 Linux 上。.NET 和 ASP.NET 的巨大生产力可以提供给那些使用混合开发环境的团队。

Many APIs Will Be Moved or Removed (一些API将被移动和删除)

  As mentioned before, they are reducing the size of HttpContext from roughly 30K per request to 2K per request. This isn’t free, the cost of that is a significantly reduced set of methods on that object and its children. And by the time they are done it is probably not going to be the only API trimmed down in size.

  正如前面提到的,既减少HttpContext的大小从大约每个请求30K到2K。这不是免费得来的,其代价是减少该对象及其子对象中的方法。当他们完成时,可能改变的不仅仅是大小。

 

  In order to make this transition less painful, they intend to develop an FxCop like tool that will detect when legacy APIs calls are being made. While it won’t be able to automatically rewrite your code, it can at least tell you what needs to be changed before migrating to ASP.NET vNext and MVC 6.

  为了使技术过渡更为平滑,微软打算开发一个类似FxCop的工具,用于检测遗留的API调用。虽然它不能自动重写你的代码,它至少可以告诉你需要迁移到ASP.NET vNext和MVC 6前要改变什么。

 

  Sometimes the change will just involve calling a different method from an optional package or library. Other times the code will need to be significantly rewritten. Since the product is still in alpha a complete list of these changes is not yet available.

  有时,变化仅仅是调用新的程序集或包中的方法。而其它时候,代码可能需要大量重构。由于该产品仍然处于alpha阶段,这些变化的具体内容尚不可知。

 

ASP.NET vNext

Full Framework vs Cloud Optimized Framework (完整的Framework VS 云优化的Framework)

  The above warnings come into play because they are removing their dependency on System.Web but otherwise stay on the full .NET Framework. If you take the next step and go with what they are calling the “Cloud Optimized Framework” then you lose access to even more APIs. In the Channel 9 Q&A session they mentioned System.Drawing as an example of what you can’t use.

  上述警告开始发挥作用,即使消除对System.Web的依赖,但仍然保持着对.NET Framework的依赖。如果你采取更进一步的行动,依赖“云优化的Framework”,那么,你将无法使用很多.NET Framework的API方法,例如在Channel 9 Q&A session中提到的System.Drawing。

 

  The advantage of using the Cloud Optimized Framework is that you can include a copy of the Core (or Mono) CLR with your website. You no longer have to upgrade .NET on the entire machine for the sake of one website. You can even have different versions of the CLR for different websites running side by side.

  利用云优化的Framework的好处是,你的站点可以包括Core CLR或Mono的副本。你不必再为某个网站而升级设备软件,你甚至可以有不同版本的CLR并行地运行不同的站点。

 

图片 2

  The Core CLR is also supposed to be tuned with a “high resource-efficient optimization”. Exactly what that means has not yet been revealed.

  Core CLR也应该被“资源优化”过。但具体内容,尚未透露。

 

ASP.NET  vNext 是我们在 TechEd 上的一个重大发布。我们已经更新了 ASP.NET 的诸多方面,使 ASP.NET 的程序更容易构建并且在性能方面表现的更好。对于这些网站和服务,我们分别考虑了访问量少的情况和访问量超多的情况。我们开辟了新的场景,这些场景之前是不会在 ASP.NET 中发生的。

Libraries vs Packages (库 vs 包)

  Under the .NET vNext model, projects don’t reference individual libraries anymore. Instead they reference NuGet Packages. As you probably know, packages can contain multiple versions of a library divided by target platform. ASP.NET vNext can leverage this to decide at runtime whether to load the Full .NET, Mono, or Core CLR version of a given library.

  在vNext中,项目不引用单个类库,而是引用NuGet包。正如你可能知道的,包可以包含同一类库的多个版本。ASP.NET vNext可以利用这个来决定在运行时是否加载某个类库的Full .NET、Mono或Core CLR版本。

 

  If this doesn’t sound palatable to you, there will also the option to use Portable Class Libraries. Though it isn’t ready yet, they plan on creating a PCL profile for the Cloud Optimized Framework.

  如果这听起来不吸引你,你也可以使用“可移植类库”。尽管它还没有准备好,微软计划为云优化的Framework创建PCL切面。

 

我们设计 ASP.NET 的时候考虑了一些关键性的设计原则,如下所示:

Mono is a Supported Platform (支持Mono)

  In the past the support story for Mono was essentially “we hope it runs, but if it doesn’t then you need to talk to Xamarin”. Now Microsoft is billing Mono as the official cross-platform CLR for ASP.NET vNext. To that effect they are actively working with the Mono teams to ensure it has everything they need and will include Mono in their Continuous Integration testing.

  过去,对于Mono,我们常常听到:“我们希望它运行的很好,但如果它不那么尽如人意,你就只能求助于Xamarin了”。现在,为了实现ASP.NET vNext的跨平台性,微软官方正式发布支持Mono的CLR。微软将积极与Mono团队合作,以确保集成测试的覆盖率。

 

  That said, Microsoft isn’t offering official support for Mono via their paid support channels. They are only promising to maintain compatibility and that if a CI test fails they will work with the Mono teams to fix it.

  此外,微软没有在其支付渠道为Mono提供支持。微软只许诺维持兼容性,如果持续集成测试出现缺陷,他们将与Mono开发团队一起解决它。

 

  • 为云环境量身打造
  • 对网站和服务使用单一的编程模型
  • 低延时的开发者体验
  • 提供高性能、高效的 API 和模式——使得他们既可以单独使用,又可以在一个应用中组合使用
  • 可通过命令行工具和标准格式的文件进行细粒度控制
  • 使用 NuGet 交付
  • 通过 .NET Foundation 开源发布
  • 可以运行在 Mono,Mac 和 Linux 上

Cross Platform Development (跨平台开发)

  Not only is Microsoft planning for cross-platform deployment, they are also enabling cross-platform development. Batch files for the major platforms such as OS X and Linux will be provided so that you can package and deploy ASP.NET vNext projects without needing Windows and Visual Studio.

  微软不仅在计划跨平台开发,他们也在推动跨平台开发。微软会为诸如OS X和Linux等主要平台提供批处理文件,以便用户可以在不借助Windows平台和Visual Studio的情况下,打包和部署ASP.NET vNext项目。

 

  Part of this is the KPM or the “Katana Packaged Modules”, which were inspired by Node Packaged Modules. Katana was a research project for modularizing ASP.NET MVC for use on Owin. KPM will use the NuGet repository on the backend.

  其中之一就是KPM,KPM是受Node Packaged Modules启发得来的。Katana是一个研发项目,其目标借助Owin让ASP.NET MVC模块化。KPM的后台将使用NuGet。

 

ASP.NET  vNext 包括 MVC,Web API,Web Pages,SignalR 以及 EF 的更新版本。对这些框架所做的主要改进在于 MVC, Web API 和 Web Pages 已经被合并成了单一的编程模型。例如,现在控制器和路由的概念已经统一在了一起。对于同一个 HTTP 请求,你现在可以使用一个控制器来返回 MVC 视图和格式化过的 Web API 响应。

Trying it Out (尝试一下)

  The preview version of the ASP.NET vNext binaries are available now. Visual Studio support is expected to be available in three to four weeks.
  目前已经发布了ASP.NET vNext binaries的预览版。预计会在三至四周后使Visual Studio对其支持。

ASP.NET  vNext 程序是为云环境设计的。像会话状态和缓存这些服务,会根据程序的运行环境(云环境或普通的主机环境)来调整它们的行为,但是他们是以统一的 API 提供给开发者的。我们在底层使用了依赖注入的方法来让你的程序去适应不同的环境。由于我们修改了底层实现的代码,所以你可以在不修改代码的情况下很容易的将你的程序从内部部署移植到云环境中。

当你修改了 web 应用程序的代码之后,不用再去执行编译的步骤,直接刷新浏览器页面就能查看到修改后的效果。这项对提升生产力很有意义的改进得益于我们对底层 CLR 加载时间的优化以及新的 .NET 编译器平台("Roslyn")。

你可以在下面的图片中看到 ASP.NET vNext 实际工作时的情况。第一张图展示了一个托管在命令行中的 ASP.NET vNext 示例程序,你可以在浏览器中浏览。在 Visual Studio 中做的任何修改都会被自动编译,并且在下一次刷新浏览器的时候执行。该程序使用的就是 .NET vNext 的云端优化过的模式。

图片 3

你也可以像之前使用 Visual Studio 那样,按 F5 键,Visual Studio 会自动打开一个 web 服务器和浏览器窗口。下面这张图就使用的这种方法,但它的代码和上面的一样。 

图片 4

下面这张图中的程序已经为 .NET vNext 框架重新配置过,并没有使用云端优化过的模式。你只需要设置一下项目的属性,这个程序就可以使用 .NET 框架提供的所有的 API 了。同样,你只需要刷新一下浏览器就可以看到配置后的结果了。

 图片 5

下面这个表格列出了一些我们已经构建了的场景以及这些场景可以使用的地方。

Feature

.NET vNext

.NET vNext (Cloud Optimized)

Cloud Ready

*

*

Modular Design

*

*

Dependency Injection

*

*

Consistent Tracing / Debugging

*

*

Faster Development (browser refresh)

*

*

Open Source

*

*

Full Side by Side (runtime and framework                

deployed with application)

 

*

Faster startup, Lower memory / Higher throughput (best of class)

 

*

Uses a smaller set of framework libraries

 

*

Enabled on Mono, on Mac and Linux

 

*

ASP.NET vNext 将会以开源的形式贡献给 .NET 基金会(.NET Foundation)。大家不用为此感到意外,因为我们早已经把 ASP.NET Web stack 开源了。以后,所有和 ASP.NET vNext 相关的东西将会通过 NuGet 发布,保持开源,并欢迎大家贡献代码。

我们在 TechEd 上对 .NET vNext 和 ASP.NET vNext 所做的介绍只是一个开始,在我们发布最终版之前的这几个月里,我们会和大家分享更多相关内容。我们计划发布一个 pre-release 版本,以便收集大家的反馈。

.NET Framework 其他的一些升级和改进

最近,我们发布了 .NET Framework 4.5.2。 这包括对 ASP.NET,Windows Form 以及其他一些产品的做的显著改进。你现在可以在你的代码中使用 4.5.2 中的一些新特性了。

同时,我们还给 .NET Native 和 Next Generation JIT 添加了新的功能和使用场景。.NET Native 现在除了支持 ARM 和 x64 的程序之外,还支持 32 位的程序。Next  Generation JIT 现在支持 Windows 7 及以上的 x64 应用程序。 这些技术都是 .NET vNext 发展道路上的关键部分。期待在未来的几个月中听到更多关于它们的消息。

  • 下载 .NET Native Developer Preview 2
  • 下载 Next Generation JIT (“RyuJit”) CTP 4

针对多个平台

为了使程序和库的代码可以更容易的运行在多个平台上,我们已经花了多年的时间在这上面。一开始,我们使 Xamarin 可以使用我们的 PCL 程序集,Xamarin 随之也作出了改变,并将这件事向前推动了一大步。最近一段时间,我们一直与 Xamarin 紧密合作,来使我们的.NET NuGet 包可以更好和 Xamarin 的工具协作,以便可以更容易的把 .NET 程序运行在 iOS 和 Android 上。这还有很长的路要走,但是,我们已经取得了很多经验,并且会继续改进它。

在 TechEd,我们发布了一个新的可移植的统计分析工具——ApiPort。它为你提供了两项主要的数据:你代码可以运行的平台以及阻止你代码运行在其他平台上的相关依赖。

命令行工具为程序可移植性的统计分析结果生成了一个 Excel 格式的报告,该报告提供了两种视图方便你的查看。它为指定的平台提供了一个高级的、以颜色区分开来的视图,同时它还提供了一个详细的列表,列出了你的代码中所有类型的成员在各平台中的支持情况。考虑到报告是一个 Excel 文件,你可以很容易的过滤这个列表,构建数据透视表以及做进一步的分析。

下面的图片展示了可移植性分析结果的高级视图。只显示了一个程序集,但实际上是有多个的。你可以下载 可移植性分析样例 来看一下它的原始数据。

图片 6

该工具还有另一个功能,所有和依赖相关的数据(不包括程序集)会被上传到一个由 .NET 团队维护的 Azure 服务上。该工具上传的数据只是你代码所依赖的程序集和 API 的列表。我们不会记录数据的来源和使用者的信息,也不会上传你的代码和二进制文件。我们只是想要知道我们还需要为不同的平台提供些什么功能,以便使代码可以更容易的跨平台。

如果你发现很难转换至一个特定的平台,请投票选出你想要为运行你的 app 和 libraries 的特定平台上的工具集所附加的 APIs。在整个目录运行工具集是一件很容易的事。

首次释出的版本可能缺乏一些特性,目前我们正努力为它添加支持 。Xamarin/Mono 平台目前还缺乏一些工具集。还没有考虑引入 NuGet packages ,它可以使其它平台同样可以利用 .NET Framework APIs,可以把它们统计为缺失的 APIs。

  • 获得 ApiPort tool – 这个工具很快就会发布。

用于 Microsoft Service 的 Client Libraries

你很可能已经听说过 Microsoft 是一个“services first” 和“devices  first”的公司。这之间的关联便是 client libraries,它使得 apps 访问 Microsoft services 变得很容易。尽管用于 Microsoft Service 的 Client Libraries 并非最新的概念,但我们目前努力为它提供多平台支持。我们从提供 Office 365 services 开始,随着时间的推移我们打算添加更多的服务支持。

在 TechEd 在,我们发布了一个用于 Office 365、.NET 和 JavaScript 的预览版的 client libraries。你可以在 Office Developer Blog 上阅读最新的 Office 365 client libraries 授权声明。.NET Client  libraries 支持 WPF、 Windows Forms、Windows Store、Xamarin.iOS、Xamarin.Android 和 ASP.NET apps 以及 Portable Class  Libraries,通过 NuGet 传递消息。

  • Microsoft Office 365 Mail, Calendar and Contacts Library for .NET(.NET 用于 Microsoft Office 365 的邮件、日历和联系人库)
  • Microsoft Office 365 My Files Library for .NET(.NET 用于 Microsoft Office 365 的我的文件库)
  • Microsoft Office 365 Users and Groups Library for .NET(.NET 用于 Microsoft Office 365 的用户和用户组库)
  • Microsoft Office 365 Authentication Library for .NET (Windows Store, Windows Desktop)(.NET 用于 Microsoft Office 365 的身份验证库(Windows 商店、Windows 桌面))
  • Microsoft Office 365 Authentication Library for ASP.NET(ASP.NET 用于 Microsoft Office 365 的身份验证库)
  • Microsoft Office 365 Authentication Library for .NET (Android and iOS)(.NET 用于 Microsoft Office 365 的身份验证库(Android 和 iOS))

我们也提供了用 Visual Studio 增加 libraries 到你的 apps 中的集成体验。这些服务需要 apps 注册,权限选择和一个特殊平台用户验证过程。你也需要增加下正确的 client libraries 至你的 apps。 Visual Studio 会管理好你的一切数据,作为联系人服务管理的一部分,如下所示。

图片 7

你可以从 Office Developer blog 学习如何利用这项特性。这个项目我们使用StackOverflow 作为社区论坛,在 Office365APIs tag 上。请告诉我们你对 client libraries 和新版本 Visual Studio 集成的看法。敬请注意 Office  services 的用途,预览版本目前还不支持商业 apps。

总结

在 .NET 团队,我们非常乐意分享下一代的 .NET 技术。正如你从公告和我们在大会上发布的版本中看到的。我们组合了一些重要的技术、特性和应用场景,这些将成为 .NET vNext 的一部分,我们下一步的主要目标释出 .NET Framework 的源码。在这篇公告中,我们主要聚集于 ASP.NET vNext,下一代的 Web 技术和服务平台。

对 .NET vNext 而言,我们将在宣布重大版本之前广泛讨论主要的特性和寻求更多的反馈。我们一直积极与相应的专家和爱好者通过预览版和预发行版来沟通观点和发展趋势。这最终被证明是一个伟大的创举。反馈之多令人难以置信。非常感谢各位参与我们的 CTPs,开发者预览版,预发行版和其它我们收集反馈的项目。我们也在博客中收到了相当优质的反馈,这些反馈非常有用。敬请期待数月内的多平台的预览版,特别是 ASP.NET vNex,这将是一个历史性的时刻。

在 TechEd 上,接下来的幻灯片中,你可以看到这些技术是如何集成到单一的 NET Framework 版本中。开源也是我们计划中非常重要的一部分,你可以在 the .NET Foundation 上看到我们 ASP.NET  vNext 的贡献计划。 .NET 的未来是非常光明的。

TAG标签:
版权声明:本文由澳门mgm官网发布于新闻,转载请注明出处:振奋人心啊