微软在2014年5月12日的TechEd大会上宣布将会发布下一代ASP.NET框架ASP.NET
vNext的预览。此次发布的ASP.NET框架与以前相比发生了根本性的变化，凸显了微软“云优先”（cloud-first）的新战略思想。微软员工Scott Hanselman发布博客对ASP.NET vNext进行了简要介绍。以下为其博客的翻译。
原文：http://www.hanselman.com/blog/IntroducingASPNETVNext.aspx
译文发布地址：http://blog.csdn.net/cheng_tian/article/details/25708445
转载请注明出处。
近来微软的ASP.NET以及Web工具团队正在搞一些很酷的玩意儿。在过去几年，我们疯狂“压榨”了微软的员工们，而现在，我们的疯狂蔓延到了.NET核心团队，以及其他更多领域。
今天我们发布了运行于服务器上的下一代.NET的预览（也就是alpha版本）。
你也许曾在早些时候的Build大会上听到过以下这些产品的发布：
- .NET Native - 提前编译.NET代码。一切都变得更快了。
- .NET编译器平台（Roslyn） - 崭新的C#以及VB编译器，新的语言特性，编译即服务（compiler-as-a-service），以及，它是开源的。
- Nextgen JIT - 为最新处理器优化的崭新的即时编译器（Just-in-time-compiler）
而ASP.NET vNext的出现，将会把一切推上更高层次。今天，你用来运行ASP.NET的通用语言运行库（CLR）与桌面应用所使的是完全相同的。但是我们正在做的事情是：增加针对云计算环境进行优化的CLR版本。优化时考虑的场景包括“低内存消耗”以及“高吞吐量”等等。
ASP.NET vNext 使得你能够为每一个应用部署定制化的.NET框架。一个使用新版本代码库（library）的应用不会让部署在同一服务器上使用该代码库的不同版本的应用悲剧。不同的应用甚至可以有不同优化侧重点的个性化CLR。CLR以及针对云环境优化的代码库都成为了可自由选择和搭配的NuGet包。
从下面这张截图你可以看到，418号版本与420号版本的新框架（注意它们占用了很少的空间）都在我的包目录中。这些NuGet包包括了完整的“核心CLR”以及针对云环境优化的.NET框架。你可以把你的应用和其依赖的定制化CLR以及.NET框架一同部署成为一个NuGet包。
我可以在VisualStudio里运行ASP.NET vNext应用，当然，还有IIS服务器上。另外我还可以非常便捷地把ASP.NET
vNext应用托管在命令行里或者我自己的应用里（译者注：原文说法为“self-host”）。我们发布的这个alpha版本包括了用来运行和管理ASP.NET vNext应用的命令行工具。
“kvm”命令让我能够控制我的运行环境（environment）。我可以执行“kvm list”来查看有哪些版本的ASP.NET
vNext可供使用。我可以在不同版本的ASP.NET vNext间自由切换，并且每个运行环境都可以有自己的版本配置。
C:\>kvm list
Active Version Runtime Architecture Location
------ ------- ------- ------------ --------
0.1-alpha-build-0418 svr50 x86 C:\Users\scottha\.kre\packages
* 0.1-alpha-build-0418 svrc50 x86 C:\Users\scottha\.kre\packages
0.1-alpha-build-0420 svr50 x86 C:\Users\scottha\.kre\packages
0.1-alpha-build-0420 svrc50 x86 C:\Users\scottha\.kre\packages
我可以使用“kvm useversion”来设置当前使用版本（active version）。这里我打开了两个命令行控制台进行设置，每个控制台可以有自己独立的CLR和.NET版本。
这里我让同一应用运行了两次，每个命令行控制台各一次。我让420号版本的应用监听5420号端口，让418号版本监听5418号端口。
下面可以看到，这个小小的应用会显示当前在运行的ASP.NET vNext的版本号。请注意，我这里是在同一时间、同一机器运行着使用不同版本ASP.NET框架的同一应用。
项目组织管理（projectsystem）也在起变化——我们将packages.config，NuGet配置（nuspec）以及项目文件（csprojs）合并成为统一的项目依赖配置，并将这个配置呈现在一个
project.json文件里。
NuGet包以及类库被认为是没有区别的。你将会在project.json文件里得到完整的智能提示（见下图），而NuGet包会被自动地、透明地下载到环境中。另外还有更好的消息：让我们假设NuGet包Foo.Bar有一个bug，而你在本地项目里创建一个名为Foo.Bar的文件夹并在这个文件夹里使用“git
clone”将Foo.Bar的源代码复制到本地，那么本地版本的Foo.Bar就会覆盖（override）NuGet所控制的版本，使得你可以使用自己修复的Foo.Bar，而非默默等待Foo.Bar的开发者发布新版本。当一个修复了bug的新版本Foo.Bar出现在NuGet服务器上时，你可以简单地更新版本号并删除本地版本以使用新版本。
另一个亮点是类似node.js或者ruby on rails的“无编译”（no compile）。你只需要修改代码然后刷新去查看修改后效果。通过下一代ASP.NET，你可以同时得到.NET运行时（runtime）的吞吐能力以及“Roslyn”编译即服务所带来的“无编译”执行。这就意味着在开发中，你可以修改你的C#类，然后轻轻按下浏览器的刷新键来查看修改效果。这将是结合.NET开发优势与“刷新，然后走你”（refresh-and-go）动态特性的开发体验。
注意：这不是ASP.NET网站或者Razor视图（View）编译的方式——这里，所有的一切都在内存里编译并存储。你可以使用Visual
Studio或者Sublime来开发，甚至可以丧心病狂地使用记事本来开发。（当然，如果你想让编译生成的文件出现在硬盘上，你也可以做到。）
请看下面，看到我的Web应用的bin文件夹没？里面根本没有编译生成的文件，因为它们不会出现在你的硬盘上。在内存中完成所有工作可以使编译器更高效、更容易地完成任务。这种方式使得你不需要读入源代码，输出动态链接库（DLLs），然后再载入动态链接库。
如果你愿意，当你构建可以用于部署的Web项目时，你可以将它们构建成为NuGet包。你将你的项目发布后，所有该项目的依赖项都会自动随之被部署。
你可以将ASP.NET vNext部署到已有服务器上，或者任何托管平台上，当然，还有Azure云服务上。
你可以启用或者禁用针对云环境优化的框架来保证兼容性。下一个版本的ASP.NET是模块化的，以给你最大限度的选择自由度。你可以自由选择框架、自由选择运行时（runtime）、自由选择操作系统、自由选择文本编辑器。
总结一下，ASP.NET vNext是：
- 针对云环境和服务器环境进行了优化
- ASP.NET MVC以及WebAPI被统一到了同一个编程模型（programming model）中
- “无编译”（no-compile）开发体验
- 自带依赖注入（Dependency Injection out of box）
- “并存”（side by side）——每个应用都有自己的运行时（runtime）以及框架随之部署
- 一切都来自NuGet——即使是运行时（runtime）也一样
- 完全通过.NET Foundation开源，并且接受外部开发者的贡献
哦，对了
- ASP.NET vNext（还有Roslyn）可以在Mac和Linux上的Mono平台上运行。虽然Mono不是微软自己的项目，我们仍会与Mono团队合作。另外Mono会被加入到我们的测试矩阵（test
matrix）里。我们的目标是——“能用”（“just work”）。
后面几个月还会陆续有新的信息和细节放出。
微软下一代云环境Web开发框架ASP.NET vNext预览