博客堂从去年最后一天开始升级到Joycode.MVC Blog Engine上面来，现在基本上每两天会进行一个小型版本升级，目前已经完成了大约50%的前端功能，后端功能（管理端）仅完成10%。
本次升级的版本使用了ASP.NET MVC框架，并且准备在ASP.NET MVC正式发布会，将该博客引擎的所有源代码都进行开源。在这次改版当中，学习了Oxite， Subtext以及BlogEngine等开源的博客项目，借鉴了其中很多非常棒的设计亮点:比如在实体类设计、事件模型以及泛型使用上学习了BlogEngine，Controller以及Views方式学习了Oxite，而数据库架构借鉴了Subtext。感觉这段时间内获盈颇多。
当然，由于这次改版时间比较匆忙，肯定还是有很多Bug出现（昨天进行版本升级时，在后台管理系统部分就忘了增加关键代码，出现了一个所有用户均可以自由删贴的Bug，幸亏今早自己发现了）。如果您发现了Bug，并且在Codeplex上有帐号，可以直接去Codeplex提交Bug，当然，也可以在本随笔后方直接添加留言。如果有任何功能需求，也可以在本贴后提交。
非常感谢大家对于博客堂的支持。
（另，征集两个博客的管理员以及志愿翻译人员: http://blog.joycode.com/haacked 以及 http://blog.joycode.com/brada，如果您有意协助翻译这两个博客，请在留言中表明，并且进行一下简单的自我介绍，在博客堂升级结束后，我们会将随贴广告位以及侧边栏广告位移交给管理人员以及志愿翻译人员，以作收益)。
（另，所有注册用户的帐号都已经自动激活，本站注册用户功能也已经开放）
终于在2008年最后一天，将博客堂进行了更新。这次更新主要是使用了ASP.NET MVC重新进行了架构，由于目前ASP.NET MVC本身还处于Beta 阶段，而RC应该在下个月初发布，届时本堂还会进行相应更新。
请所有博客堂堂主重新使用Windows Live Writer更新帐号设置。在更新帐号结束后，就可以使用Windows Live Writer直接编写文章了（新建、更新以及删除），目前页面端的后台管理界面还在开发当中，应该在本周末可以发布。
非常抱歉这一年来让各位堂主受累了，由于工作繁忙，前期的改版半途而途，这次开心不会了。最后祝各位新年快乐. :)
Visual Basic 9.0 提供了一个新的功能XML Literals，它将使得对XML的编程更加简单方便，并且在很大程度上的减少了我们的代码量。实际上，XML Literals使得我们用Visual Basic去做XML变得如此简单，以至于很多C#开发者也开始趋向于在VB.NET中来进行XML相关工作！如果想要了解更多信息，请参看下面来自TechEd US的内容：
想玩Windows 7很久了，而且从网上的评论来看，大家对Windows 7的评论都非常正面。但因为没有参加PDC，没能得到带Windows 7的碟子。最近MVP的邮件列单上说有多余碟子赠送，就去信说想要一份，没想到很快就寄来了。在这里，要感谢微软中国MVP部门，特别是MVP Lead Sisley。
拿到碟子后，迫不及待地在Virtual PC上装了一份，但没有硬件加速，感觉不是很过瘾。
小孩的Dell机器（04年购置的）不久前被一个病毒所扰，修复后很多软件都无法用了，一直吵着要重新安装系统。我想，反正是重装，就装Windows 7，让小孩做beta测试人员吧。
安装比较顺利，而且好像安装的时间也比较短。但可惜，系统居然不认识上面的声卡。小孩说，没audio，那怎么成？
该声卡是Creative Labs的，驱动认出是Multimedia Audio Controller，但Windows 7安装不了驱动。用了Dell原来带来的驱动软件，即使设置了以XP兼容模式运行，也无法安装。在网上查了无数的文章和贴子，试验了很多法子，都没用。被折磨了N个小时后，决定放弃，从一个很老的闲置机器上拔了声卡出来，看是否可用，哈，Window 7居然认出来，安装了适当的驱动程序！
安装的版本是6801，好像是比较早的版本，感觉比较慢。每次使用Windows Explorer访问局域网上的共享文件，如果连不上，Windows Explorer就会死在那里，用Task Manager也杀不死，log off也死在那里，最后只能关机。
从网上的消息看，好像有人已经拿到比较新的版本，反映不错。微软好像在明年一月会开放beta测试，非常期待。
Composite Web Application Block是Web Client Software Factory中一个用来开发Web应用的框架，它能帮助程序员更方便的使用MVP模式。关于CWAB的更多信息，请参考这里。
当我们开发SharePoint界面的时候，比如，创建一个Web Part，如果你希望使用MVP模式，是可以引入CWAB的。在这个文档中解释了如何在SharePoint中使用CWAB，但文档里面的一些步骤，其实不一定是最好的。比如，文档中告诉你，将各个程序集放到Web Application的/bin目录中，但我的建议是仍然将它们部署到GAC里面，这样，你就不需要更改Web Application的web.config中的<trust>节点，将代码的默认信任等级提高了。
嗯，总之，我们可以使用CWAB来方便的基于MVP模式来开发Web Part，比如下图所示的项目结构：
上图中的“KBSample.SiteUser.Module”是CWAB中的一个Module项目，包含了与界面UI分离的业务模块。在“Views”目录中包含了定义View的接口和Presenter类：
在“Services”目录中包含了与业务操作相关的Service类：
而“KBSample.SiteUser”项目则是专门的SharePoint项目(你可以选择使用VSeWSS，或是其它你习惯的工具)，其中包含了用来定义Web Part界面的View的实现。
在下面所示的Service接口中，定义了用来真正和SharePoint Object Model交互以获取数据的Service：
在Module被初始化时，将上面的Service注册到Container中：
对View接口的定义：
在Presenter里面，通过[ServiceDependency]来注入所依赖的Service对象(CWAB通过ObjectBuilder来干这件事)，同时定义了当View被载入时的操作：
View是通过一个用户控件来实现的，它实现了View接口，通过[CreateNew]来将一个新的Presenter对象注入进来：
别忘记在View被载入时，也要执行一下Presenter中的载入方法：
如果你熟悉Web Client Software Factory的话，那么在SharePoint开发中引入CWAB应该不是一件困难的事情。不过，由WCSF提供的那些Template和Recipe都不能使用了，项目的结构，需要我们来手工维护(这样反而给了我们很大的自由度:)。
在Wikipedia上，对“Web Application Framework”的定义是：
一个Web Application Framework是一个设计为支持动态Web网站、Web应用程序和Web Services开发的软件框架。Web Application Framework的目标是减少在Web开发中，与常见的开发工作有关的问题。例如，许多框架都提供了诸如数据库访问类库、模板框架和会话管理，同时，框架通常都能促进代码复用。（注：http://en.wikipedia.org/wiki/Web_application_framework）
Wikipedia的定义虽然清晰明了，但未免过于宽泛。根据这个定义，实际上，我们可以再将Web Application Framework分成两种：
■ Web Application Infrastructure Framework
■ Web Application Building Framework
Infrastrcture Framework提供了用来构建Web应用最底层的各种基础框架，诸如HTTP请求的截取和分配、网站与页面处理框架、会话管理、缓存等等。ASP.NET、PHP、JSP就属于Infrastrcture Framework。
Building Framework则是基于Infrastrcture Framework而构建起来的层次更高的Web应用框架，它的目的包括：
■ 将Web应用开发人员的视角从最底层的网站与页面框架，拉到更上面的基于具体应用的业务功能上
■ 用来支撑大型复杂的Web应用，例如超过上千个网站、上万个页面的Web系统，而且提供对服务器场、负载平衡的支持
在.NET领域，DotNetNuke就是一个典型的Building Framework。有了Building Framework，Web开发人员就可以不用从最底层开始构建Web应用系统，而是可以基于Building Framework，开始构建所需要的应用功能组件。一个Building Framework通常会包含下列内容：
■ 成熟的网站与页面结构框架，使得开发人员不用再基于页面、目录来管理整个Web应用
■ 完善且可扩展的用户、角色与权限管理
■ 灵活的UI模型
■ 内置的数据和文件存储能力
■ 具备完善的功能模块封装型
■ 对必要的功能接口提供API
■ 其他…
对于Web应用的开发来说，从静态网站到动态网站，从Infrastructure Framework到Building Framework，几乎是必然的。随着Web应用越来越复杂，开发人员面临的挑战也越来越大：如何维护和管理上千个网站、上万个页面？如何使Web应用能部署到网络负载平衡的环境中？如何使后台的Services与前台Web请求分离？如何提供完善的系统备份与迁移方案？如果我们必须基于Infrastructure Framework来解决这些问题，那么我们可能得将大部分的项目开发周期，花费在解决这些“底层架构”框架之上（虽然有些开发人员确实更喜欢开发“框架”，而不是一个可用的业务系统）。
当基于Building Framework之上进行开发时，开发人员可以更关注业务需求和业务功能的实现。通常，每一种Building Framework都会有一套专门的对功能模块进行封装和打包的模型，开发人员可以基于这一套模型，将自己开发的功能模块以标准化的方式进行封包。一方面，这样可以使得功能模块的部署变得更简单（避免了基于文件的手工拷贝方式），另一方面，开发人员也更容易的将自己开发的功能模块共享给社区（社区中使用同一套Building Framework的开发人员，可以方便的将拿到的功能模块以标准化的方式部署到自己的环境中）。
待续…
前几天在客户那里安装SQL Server 2008 Active/Active Cluster的时候遇到一些小问题，这里总结一下，因为SQL Server 2008的Cluster安装方法已经和2005非常不同了，而且第一次安装的时候还没装成功，因为那个时候还是RC0的版本，产品组的人告诉我就根本装不上，所以这次安装的时候特别的小心。
SQL Server 2008安装的过程与之前的版本完全不一样了，提供了一个特殊的工具用于安装，因为之前的安装经常出现一些怪异的问题，尤其是在Cluster安装的时候。在前版本的Cluster安装只需要在一个节点安装一次就可以将一个SQL实例安装到多个节点上，这样随然看起来比较方便，但是安装的过程相对较慢，而且非常容易出错，主要是因为为了保证2个节点安装同时成功，需要启动MSDTC来提供事物保证，而在安装的过程中需要安装各种组件例如.net framework,native client ,MSXML等，这样多的组件中止要有一个出现问题都会产生影响，而且安装的时间也没有一个很好的评估。一般我都先分别在节点上装好需要的组件，然后在安装，而且安装的过程中不要包含那些不必要的组件，例如管理工具之类的。
在SQL Server 2008的Cluster安装中，安装的方法发生了变化，将原有的1次安装多个节点改为1次只安装一个节点，这样做得好处是将事物边界缩小，这样出错的概率会比较低(事物尽可能短小，是不变的真理），安装完成一个节点后，在安装另外一个节点的时候选择加入群集，就可以了。
在安装A/P Cluster的时候没有问题，但是在A/A的时候，会遇到一些小问题，这个问题已经有了明确的说明-bug，在SQL Server 2008 CU1中提供的修正。当你安装完成一个实例的Cluster后，在另外一个节点安装第2个实例，这次还是还是选择安装新的cluster节点，这个安装也不会遇到问题，当你在第一节点加入第2实例时，会遇到一个SKU Error，此时需要在第一节点安装CU1，然后再添加第2实例。
当安装完成后，还需要在2个节点上各安装一次CU1，否则实例中的SQL Server版本将不一样，以后应用的时候可能会有问题。
所以A/A Cluster安装会非常麻烦，安装4次SQL Server，安装3次CU1.
[原文发表时间] Friday, December 19, 2008 8:34 PM
在11月份的一篇博文中，我提到了一个叫做“快速搜索”的功能—Visual Studio 2010中关注代码的功能之一。在过去的岁月中我们在这一领域中已经有所滞后，而在Visual Studio 2010中，我们想专注于这方面并视其为关键。今天，我想分享更多关于我们关注代码开发方面的投资和功能的细节。
高亮引用（Highlight Reference）
高亮引用是一种看似简单却易于使用的方式，帮助我们快速理解一段代码并导航到相应的引用。这个功能在一小段延迟之后被自动激活 – 所有在鼠标指针下的引用都被高亮显示。只要按下Ctrl + Shift + UpArrow （或者DownArrow作反向导航），就可以轻松导航到下一个引用。在下面这个例子里，你可以看到该项功能的实际运作；你可能也注意到它推断出哪项重载绑定到当前的选择，而不是使用纯文本匹配的方式。
快速搜索
快速搜索是我先前提到过的专注于代码的功能。它作用于C++、C#和VB的所有符号，以及所有文件类型。它是一种非常轻量的作增量搜索的方式，可以很快的过滤结果并拥有诸如子字符串这样强大的启发式搜索。让我们简单的看一下我可能会怎样使用快速搜索。
假设我要寻找一个事件句柄，我已不太记得它的名字，但知道我使用了典型的命名规则，快速搜索可以帮上我的忙。我的第一步是在快速搜索中输入“Click”来寻找所有带有“Click”的方法签名。
这时候，我可能记得它还包含了“Enter”。我再输入一个字母“E”，我就能对所有同时包含“Click”和“E”的结果进行快速过滤。两次输入之间的空格被当作通配符搜索。现在我已经把结果缩减成一个很短的列表，我可以从里面选择我想要的结果。
快速搜索甚至还支持驼峰匹配。比如说，如果我输入大写的“SPF”，快速搜索会把结果过滤为那些驼峰匹配或者完全匹配的结果！
调用层次
我们关注的另一个场景是重审依赖关系。比方说，如果我对一个方法作了点改动，我可能会想知道调用这个方法的所有实例。在VS2010中，我们改进了C++中调用浏览器的使用体验，并为C#和VB添加了一个新的调用层次的工具。这些功能让调用方法和被调用方法之间的导航变得更容易（如下所示）。
调用层次工具还允许你察看一个方法的所有重载方法以及接口方法的任意一种实现。比如，如果我想看看谁实现了MakeSound()这个接口方法，我可以通过调用层次看到在Cat和Dog中一共有两个实现。
消耗先行的开发
在Visual Studio中有很多诸如智能感应和快速搜索的功能适用于用户消耗的API定义好之后。然而，我们注意到有很多时候你需要对一个还未完全定义好的API进行开发。比如，在测试驱动开发（TDD）中，我们可以看到测试先行的模式。因此，在VS2010中，我们使消耗先行的开发变得更简单。
我之前谈过关于“从使用中生成”的功能。该功能通过代码中的符号使用推断出各种类型、方法、属性和构造方法并生成一小段代码。在下面的截屏中，你可以看见“从使用中生成”这一功能的实际运作。
生成构造方法将会生成以下代码：
而且，我们为智能感应也开发了一套“消耗先行”的模式，从而使你可以轻松的触发智能感应中的功能。在现在的Visual Studio中，你可能已经有这样的经历，IDE会自动完成一个标示符，但其实你并不想让它这样做的，因为它还并不存在（考虑一下范式方法返回类型）。在下面的例子里，如果你输入“Puzzle”，智能感应为预先选择“PuzzleTest”。敲击空格或回车键将会插入“PuzzleTest”。
取而代之的，通过敲击Ctrl + Alt + 空格键，你将能触发“消耗先行”的模式。现在，当你输入“Puzzle”，列表中仍然包含了“PuzzleTest”，但却不会主动选择它。你真正输入的内容才是会被插入的内容。
这些是我们在Visual Studio 2010中所作的工作的一些例子。我们的工作旨在让你的工作更简单更高效。
Namaste!
[原文发表地址] Lab Management in VSTS 2010
[原文发表时间] Friday, December 12, 2008 5:30 PM
Visual Studio Team System 2010的其中一个重要-组件是实验室管理（Lab Management）。我们在最近的PDC会议上-对此有说到，我们也看到很多客户为这-个功能感到非常的兴奋。
很明显地，对于我们软件开发人员和测试人员来说，他们所开发和测试的应用程序面临复杂性的加速增长。对于我们微软内部以及-其它业界的软件人员来说，这-同样也是一个问题。
我们在开发VSTS2010时，希望能够有一个好的工具来开发最高质量的软件。我们发现开发速度以及在整个开发-软件生成-实施-测试当中的可扩展性，以及如何应用新技术-如虚拟化技术，就是其中的一个差距。我们在实验室管理方面的投入就是特意为了来解决这个差距。
开发人员对于太多软件瑕疵（bugs）在他们以及他们的测试人员之间的“不断来回”而苦恼不已，并且在分布式的开发环境下感觉更棘手。测试人员缺少正确的工具，也没有得到足够的重视。他们在测试环境的配置方面花费了30-50%的时间，然后很多他们所汇报的软件瑕疵（bugs）已“无法重现”为由而被解决掉。
为了应对这些挑战，我们设立了一些基本的原则：a）配置环境应该只需要几分钟而不是几个星期b）开发人员和测试人员之间的障碍应该被消除c）自动化全面扩展至软件生成，环境的设置，软件安装以及测试d）消除软件瑕疵（bugs）“来回”现象。
实验室管理用户虚拟化技术与我们的整体应用软件的开发周期管理的深层次集成，以及系统中心虚拟机管理系统提供了对于这些原则的解决方案。该方案是用来加速设置/分割/恢复复杂的虚拟环境到一个干净的状态。我们允许测试人员写丰富的瑕疵报告，包括环境恢复点的链接，这样开发人员就可以用来重现该软件瑕疵被发现的环境，从而解决了软件瑕疵不可重现的问题。最后，我们把预设虚拟机，软件安装以及验证做成一个集成的方案，提升了软件生成的自动化程度。我们相信，这种方法可以使得团队更加有效的包容变化，在需求变化更多的情况下变得更加敏捷。
一下是一个该技术的更加具体的例子：
当一个测试人员在虚拟机环境下测试并找到一个软件瑕疵的时候，只用一个简单的点击就可以把整个环境的镜像点（多个虚拟机）记录下来。他可以把这个镜像点的链接，只有几个字节，作为附件自动内嵌在软件瑕疵报告中，同时可以选择包含更多的信息，比如带时间坐标的视频，操作记录，历史调试记录以及更多信息。
开发人员得到这个软件瑕疵报告之后，他能够从集成开发环境（IDE）里打开它，并且找到与这个瑕疵在该镜像点上所有相关的丰富信息。头一次，开发人员不需要询问测试者他/她到底做了什么以及重新设置瑕疵重现的环境。他们可以简单地双击链接，得到一个简单的实验室环境视图，其中可以包括多个虚拟机环境，他可以用一次点击就可以恢复所需的整个环境状态。然后，他就拥有了整个环境，包括历史环境下的调试工具，来回卷他们的代码，找到导致软件瑕疵的事件发生的顺序，或者程序的流程，而所有这些工具都包含在VSTS 2010中。
正如你所想象的，实验室管理能够最大程度的提升开发人员- 测试人员的工作流，并且帮助整个开发流程变得更加有效率。
Namaste!
【原文地址】ASP.NET MVC Design Gallery and Upcoming View Improvements with the ASP.NET MVC Release Candidate
【原文发表日期】 Friday, December 19, 2008 12:44 AM
今天我们在www.asp.net网站上推出了一个新的ASP.NET MVC 设计陈列室。这个设计陈列室里陈列了你可以下载和轻易使用在你的ASP.NET MVC应用中的免费HTML设计模板。每个设计模板中包括了一个Site.master文件，一个CSS样式表文件，也许还有一套图片，用户控件，以及支持它们的辅助方法等。
陈列室允许你在线预览每个设计，以及下载一个你可以解出和集成进你的网站的模板.zip版本。该陈列室允许任何人在创作共用许可（creative commons license）下创建和提交新的设计。访客可以对它们进行投票，提供反馈。最受欢迎的设计会在陈列室的顶部显示。
我们认为这会给开发人员提供一个很有用的方式来更轻松地创建有吸引力的，与标准兼容的网站。希望还能鼓励大家创建和共享可轻易为他人重用的设计。
即将推出的最终版候选版本中的View方面的改进
说到UI这个话题，我想我也应该与大家分享即将推出的ASP.NET MVC最终版候选版本(Release Candidate,简称RC)中的一些与视图有关的改进的细节。除了缺陷修补外，RC版本还融合了若干个特定于视图的新功能和来自社区的建议。
不需要后台代码文件的视图
基于许多人的反馈，我们决定做一个变动，这样MVC视图文件在默认情形下不再拥有后台代码文件。这个变动有助于强化视图在MVC世界中的目的（视图意在纯粹的显示，不该包含任何与显示无关的代码），去掉项目中没被使用的文件（对大多数人来说）：
在ASP.NET MVC Beta版本中，开发人员可以通过在视图中的Inherits（继承）属性上使用泛型的CLR句法来除去后台代码文件，但这个CLR句法，说得轻一点的话，非常难以发现而且非常难用。ASP.NET MVC开发团队结合了ASP.NET中现有的几个扩展性功能，将在ASP.NET RC版本中，在Inherits属性中提供一个标准VB/C#语言句法：
不使用后台代码文件的另一个好处是，在你将视图文件加到项目中时，你会马上得到intellisense。在Beta版本中，你需要在创建视图后做一次编译才能在其中得到代码intellisense。RC版本将使得添加和立刻编辑视图的流程免去了编译之累，变得更加紧凑。
视图的顶级Model属性
在ASP.NET MVC的早期版本中，你使用ViewData.Model属性来访问传给视图的强类型的模型对象：
上面的句法还是可用的，虽然现在ViewPage上还有一个顶级的Model属性可为你所用：
这个属性的作用跟先前的代码例子是一样的，它主要的好处在于它允许你编写的代码更加简明。
HTML/AJAX辅助对象现在允许表达式句法
有一个不少人都提出的要求是，在使用视图的HTML和AJAX辅助对象时，在指称Model时使用强类型表达式的句法（而不是字符串）的能力。
在ASP.NET MVC Beta版本中，这是不可能的，因为HtmlHelper和AjaxHelper辅助类并没有在它们的签名中呈示模型的类型，所以大家需要建造直接基于ViewPage<TModel>基类的辅助方法才能达成这个目的。ASP.NET MVC RC 版本引进了新的HtmlHelper<TModel>和 AjaxHelper<TModel> 类型，是在ViewPage<TModel> 基类上呈示的。这些类型现在允许任何人建造使用了表达式句法的强类型HTML和AJAX辅助扩展来指称View的模型。
例如，我可以使用下面的代码建造一个（非常简单的）强类型TextBox辅助方法：
然后可以这样，在我的任意一个视图中，用它来绑定一个Product模型对象：
Visual Studio将在源代码编辑器中操作View的模型时，以这种方式对强类型的表达式句法提供完整的intellisense：
注：核心ASP.NET MVC V1程序集中的HTML辅助扩展还将使用现有的句法（不是基于表达式的），我们正计划在MVCFutures程序集中加入基于表达式的版本。当然，你还可以使用字符串或者强类型的表达式，来添加你自己的辅助方法。所有这些内置的辅助方法都是可以去掉的（因为他们是扩展方法），如果你要用自己的版本来替换或覆盖它们的话。
Scaffolding支持
ASP.NET MVC RC版本还包括了在Visual Studio中使用新的ASP.NET MVC "Add View"命令创建视图时的自动的"UI scaffolding" 支持。这个scaffolding支持将允许针对任何.NET 类型或对象的自动的视图生成，意味着它对POCO类，LINQ to SQL, LINQ to Entities, NHibernate, SubSonic, LLBLGen Pro,或者任何其他对象模型都工作。Scaffolding引擎使用了反射来获取View的模型类型的公开接口，然后将它们传给scaffolding模板，在生成的视图中填充基于它的合适HTML标识。
例如，假定我们有一个ProductsController类，想创建一个它的"Edit" action，来显示特定产品的编辑视图。使用RC版本，我们可以象这样，在我们的"Edit" action方法中右击，选择"Add View"上下文菜单命令：
然后在"Add View" 对话框中，我们可以表示我们将把Product类型传给我们的View：
我们可以表示我们要创建一个"Empty" 视图模板（象上面那样），或者表示我们要VS针对我们提供的Product对象自动提供一个"Edit"表单视图的基本架子：
如果我们选择"Edit" 模板， VS会自动为我们生成一个文件，该文件含有合适的HTML和验证辅助方法来生成一个可编辑的表单视图：
然后我们可以运行应用，马上得到一个编辑界面：
然后我们可以进去，将生成的edit.aspx文件做任意改动。
我们发布的scaffolding系统的一个非常棒的东西是，它是使用Visual Studio的内置T4代码生成系统实现的（Scott Hanselman在这里有一篇非常好的相关博客）。随ASP.NET MVC发布的"List（列表）", "Edit（编辑）", "Create（创建）" and "Details（细节）" 模板可以做完全定制，或者用你自己的T4模板做替换（或者从ASP.NET MVC设计陈列室下载）。所以，如果你自己有特别的方式生成HTML的话，或者想要使用自定义的HTML辅助类（譬如，基于强类型表达式的辅助类），那你可以更新默认的模板，然后scaffolding系统之后就会使用它们。
我们计划允许模板可以在整个机器的层次，以及每个项目的层次上被置换（这样，你可以在源码控制中签入特定于应用的scaffolding模板，在团队成员间共享）。
编辑视图的MSBuild任务
在默认情形下，当你编译ASP.NET MVC项目时，它会编译项目中除了视图文件中代码以外的所有代码。在ASP.NET MVC Beta中，你想要编译视图的话，你需要编写你自己的 MSBuild任务。ASP.NET MVC RC版本现在包含了一个内置的 MSBuild 任务，你可以用它来将视图包括成为项目编译过程的一部分。它会核实应用中所有视图和母版页的句法和行内代码，如果遇到问题的话，它会给你编译错误信息。
但因为性能的缘故，我们不建议在开发期间运行它来做快速编译，但将它加到特定的编译配置（例如，staging和部署）或者在与 Build 或 CI (连续集成)服务器一起使用时是非常方便的。
即将推出的ASP.NET MVC RC版本的其他一些功能
上面是RC版本中一些特定于视图的功能的简短列表。
在RC版本中，还有许多其他的功能和要求，这些包括：IDataErrorInfo支持，允许模型汇报验证错误信息，以及更丰富的错误验证扩展性以允许你使用自己的方式来汇报模型验证信息到ModelBinders中（IDataErrorInfo支持是建造在这个的基础之上的）；新的FileResult和JavaScriptResult的ActionResult 类型（允许你更轻松地下载文件和可执行的JavaScript到浏览器中）；内置的 jQuery -vsdoc intellisense支持；重构了的AccountController支持，以促成更简单的表单登录场景的单元测试和扩展性；各种各样的项目模板改进，随处可见的众多扩展性；诸多的缺陷修补；以及若干个在RC出来后我将在博客中讨论的其他很酷的特性等。
我们将在一月份发布ASP.NET MVC的RC版本。我们的计划是，该版本将是ASP.NET MVC V1 API和功能完备，含有0个已知的缺陷。我们将给大家一个简短的时间更新到该版本，好好试用一下，报告任何紧要问题，在那之后不久，我们就将发布正式的V1版本（所以，离现在也不太远了）。
希望本文对你有所帮助，
Scott
