ASP.NET 2.0总算发布了正式版本。而我也在第一时间下载了Framework和SDK。现在，我正在以我的无比强壮的英语（同样没有证据）和无敌的金山词霸200X版进入ASP.NET QuickStart。
据说我是从来不说废话的。微软的Visual Studio 2005虽然看起来像是比测试版的时候帅得多，但是实际上，他还是很快淹没了公司提供我的可怜的512M内存，当然，我是说在关掉了之后。而恐怖的Maxthon浏览器则是动不动的脚本错误，或者根本就不出错。不管是可怜的CSDN Blog还是我伟大的Javascript游戏，都被他谢绝了部分，他总是那么谦虚，唉。人生不如意者，十有八九啊。以下乃正式内容，请各位观众及时关闭，以免造成太大的愤怒，本人就罪大了，善哉...
请各位不要怀疑我是从New这样的字里面找来的东西，因为根本就是了。
首先，要提的是动态编译。ASP.NET 1.1中的Code Behind实际上aspx页面是aspx.cs文件创建的类的子类。而ASP.NET 2.0中由于引入了partial这种东东。（partial加在class前，可以将一个类放在多个文件中编写）因此Code Behind实际上跟aspx页面共同编译成一个类，因此，我不得不把该死的后缀名为cs的文件公开放置于网站下面。
但是，实际上并不是这样的，首先我发现了Page指令中的Inherits属性，为什么还是Inherits？从Visual Studio 2005的Build菜单中发现了Public Web Site一项，使用后发现OK，生成了Bin，并且里面有个以App_Web_开头的dll，名字是不固定的。于是我修改.aspx文件的内容，为其增加一个服务器控件，再次浏览该页，一切正常。
Code Behind还是父类！猜想在编译的时候编译器将aspx文件编译成一个临时的cs文件再将其和CodeFile文件合并生成父类。而运行时aspx文件又是它的子类，有趣啊，乱伦？不过看来，以上的两种方式就是ASP.NET的动态编译和预先编译。但是，更让人郁闷的是，CodeFile中的方法只能是public或者protected，也就是说，在编译时生成的类中并不包含事件的挂钩（Page_Load除外，Page_Load可以是private）。而是在aspx中指定，可能是为了灵活性吧。
同样的，可以将其它的cs文件放在App_Code目录下来动态编译，而发布后将生成App_Code.dll。事实上，VS.NET 2005只允许将其它的类（.cs）文件放在App_Code底下，放在其它位置将不会被编译。而现在的生成菜单似乎仅仅检查语法而已了，反正是不会生成什么看得到的东西了。
其它的方面，如新增的大量的服务器控件啊，还是我最喜欢的$绑定<%$ ... %>（从配置或资源文件中读取数据）好像没有什么好说的（有的话留着后面说吧），那就到此吧。顺便提一下，本系列的编号将根据QuickStart来完成，当然，完成了QuickStart的学习后还可能有其它的，那是后话，不提。
这么重要的一个部分，我却发现没有什么好说的。因为现在都是傻瓜式的了。而且恐怖的VS 2005又让我可怜的机子不堪重负，没有实践就没有发言权。下面列出新的控件及其用途
这么重要的一个部分，我却发现没有什么好说的。因为现在都是傻瓜式的了。而且恐怖的VS 2005又让我可怜的机子不堪重负，没有实践就没有发言权。下面列出新的控件及其用途。
一、Data Source Controls
SqlDataSource：儿童玩具型数据源，它就像你平常做的数据访问类一样，不过只需要设置它的一些属性就可以工作了，并且它和其它的数据显示控件很好的合作。因此还是很方便的。如果有了VS还不懂用这个玩意儿，那么可以直接去幼儿园进修了。
ObjectDataSource：企业级解决方案，不用再为UI层烦恼了，如果你做基于数据库的应用。可以轻松地把您的数据访问层或者业务层绑定在这个可爱的东西上面了。它用起来就像上面的儿童玩具一样的方便。真是玛丽顾得啊。
还有XmlDataSource和SiteMapDataSource来绑定于XML文件或站点地图（后面会提到，默认也是XML格式的），还可以使用XPath从中选择，或者直接使用XSLT转换XML（XmlDataSource）
忘记了还有另一个儿童玩具AcceseDataSource。不要小看儿童玩具哦，多啦A梦...
二、New Data Bound Controls
GridView：新的表格型数据控件，用来取代DataGrid。实际上，在VS2005中的工具栏上已经默认没有DataGrid了，可能是无地自容了。简单的说，GridView就是一个傻瓜式的DataGrid，不必再为一个简单的分页或者其它的什么功能写一大堆代码了。一个属性就摆平了。并且它的列更加丰富。为了区分DataGrid的Column属性，它的列都叫Field了，真不知道万一还有新的需要，3.0中会叫什么？
DetailsView：如果做一个数据表的维护，那么就会有这样的东西，无聊地编写增加和个性的页面，并且写一大堆更无聊的代码。那么现在DetailsView就是其中的一个不错的解决方案了。终于解放了啊。DetailsView就是一条记录的数据控件，可以增加和修改，还可以翻页。
FormView：可以把它当作DetailsView的自定义版本了，在下面的绑定中介绍。
三、Data Controls Parameter
就是上面那些Data Source的参数，有多种，就不一一解释了，仅将其列出。其中如果Data Source和Data Bound Controls共同使用时，参数名是有限制的。Parameter（静态）；QueryStringParameter；ControlParameter；SessionParameter；FormParameter；CookieParameter；ProfileParameter。
四、Improved Data Binding Syntax
新的绑定方法<%# Eval(...) %>和<%# Bind(...) %>，不需要再有Container.DataItem了，因为这两种方式只能用在数据绑定的容器内。其中Bind为双向绑定，可以从数据源Data Source绑定到Data Bound Control，而可以从数据显示控件返回到数据源控件。
五、竖向控件
即新的控件TreeView和Menu，Menu就像微软网站上的那个菜单，TreeView就是MSDN的那种树状方式，而实际上TreeView也可以实现像MSDN一样的分块读入，但是没有实际测试，不知道能不能适用于各个浏览器，不过TreeView再不是原先1.1时微软提供的那个劣质品了。
2.0的数据绑定完全改变了方式，当然，它还是向下兼容的，不过我想新的方式可能确实会给我们带来相当的便利
在N久之前，还在CSDN上论坛上看到过这样的说法：ASP.NET的客户端验证不安全。然而实际上验证控件是在服务器端验证的，不管客户端是否发生了验证。而像Firefox这样的浏览器更是所有的验证都是在服务器上执行的。
因为1.x版本的验证控件是用HTML自定义属性来实现的，而除IE及IE内核的浏览器外，这些特性是不被支持的，因此，在验证其它浏览器的数据时无论如何都只能返回服务器了。在2.0中，这个特性终于被修改了，虽然看起来有点傻傻的。是的，它确实像我们普通会javascript的人都会想到的一样，使用javascript为验证控件生成的span元素增加属性。但是，这么简单的改动却使得可以使用客户端验证的浏览器大大增加了（基本上都可以了）。
而通过Page的属性ClientTarget可以设置所有的验证控件是否会在客户端验证。只要将这个属性设置为UpLevel就可以了，DownLevel下，所有的验证都只会在服务器上执行了。默认情况下，大多数浏览器都是会在客户端验证的，所以我并不知道它的这个属性是不是默认UpLevel了。当然，如果要为单独的一个或几个验证控件设置的话，那么还是使用原先的EnableClientScript。
另外还增加了一个SetFoucsOnError属性。就是当出错的时候将焦点移到控件上。这样就不会使用户在点击了按钮之后因为没看到错误提示而在那发愣了。另外一个小东西就是CustomValidator增加了ValidateEmptyText属性来让用户自定义验证控件在值为空时也验证。
下一个有用的特性是ValidationGroup属性，将你在一个按钮点击时要验证的控件设置为同一个组名吧，而另一个按钮要验证的设置为另一个名，这样就可以使点击一个按键时只发生期望的验证，而不是所有的验证，而不必在服务器端显示来控件。注意，按钮也应该设计ValidationGroup属性。
最后一个就是比较验证控件将使用与文化无关的格式。
验证控件的改变从使用上来说没有多少改变。
Window XP的样式终于被可爱的M$搬到ASP.NET中了。这样的东西让我想到了M$的恐怖的想法，原先150智商现在被分解了，150智商=微软解决方案+50智商+已经学会了容忍不完美和失误。当然，如果您的智商已经是150的LEVEL，那么使用微软解决方案可能会导致溢出。（不在讨论范围之内）
其实用样式和主题这样的词并不能很好的说明ASP.NET 2.0中出现的这些东西。因为它很容易和我们的网页样式表css混淆起来。实际上，可以在主题和皮肤中可以定义的绝不仅仅是CSS样式而已。QuickStart中称之为服务器的端的样式，这样会更合适一点。在主题和皮肤中，绝大部分的内容都是可以使用定义的，当然不包括Id。
所有的主题和皮肤都必须放在一个叫App_Themes的目录下，这个目录可以是应用程序级的（把它放在你的站点目录下）或者是全局的（放在.net的目录下，或者放在IIS的一个目录下，具体参见帮助）。主题实际上就是多个皮肤的集合，在App_Themes下的子目录名就是主题名。而主题名下的后缀名为.skin的文件就是皮肤文件。
皮肤文件的写法更是傻瓜式的，其实就是把原先写在控件下的属性移至.skin下。写法和.aspx文件基本上是一样的，只不过没有Id属性，却多了一个SkinId的属性。不用怀疑，在页面中使用同样的SkinId就可以使用这个皮肤定义的样式了。而在皮肤文件中没有使用SkinId属性的控件，将是默认应用到页面中所有没有指定SkinId的同类控件上。
不好意思，忘记了说在Page指令或者程序代码中要显示指定Theme属性，属性的取值就是App_Themes下子文件夹的名字。另外还有一个StyleSheetTheme属性，也是同样的取值范围。晕乎哉？传说Theme属性>页面中指定的属性>StyleSheetTheme属性中指定的属性。但是例子中上述说法很明显是成立的。
不知道大叔大婶姐姐哥哥们有没有考虑过，在一个站点中出现N次男、女这类的下拉框时该怎么办？在每个页面写它的ListItem吗？绑定数据库或XML？漫漫的人生就在这样的思考中消失？如果是这样的话，那么你应该开始喜欢上皮肤了，您可以把你的简单的数据选择框的内容放到皮肤文件里去了。
在皮肤文件中甚至可以出现数据绑定表达式！当然这个是很有限的，仅在数据显示控件，如DataList，DataGrid，Repeater，GridView等（VS2005工具栏中它们被放置在一个单独的组里）。并且必须使用新的Eval或Bind表达式，并且不能在皮肤里执行绑定。
在皮肤文件中也可以使用CSS或者图片等资源，不用担心路径问题，M$已经帮我们解决了，当然，CSS使用起来得小心了，因为它可以影响到全局。
最后，如果要在整个站点使用同一个主题的话，那么在Web.Config中指定吧。在System.Web下增加这样的东东<pages theme="ExampleTheme"/>，也可以在代码中指定主题，但是，是在Page_PreInit中也不是Page_Load中。
可怜的我正在公司长达两天的培训中与无情的睡魔做斗争，还能抽空出来写写学习笔记，已经很不容易了，请各位大虾手下留情，thanks！
首先，因为这篇内容很少，所以废话居多。顺便提一下，有空在这儿看我这种闲人的笔记并发表详论，甚至有空看电脑报的大叔，您不如多发点时间去做点大叔应该做的事吧。本人不仅虚伪，而且不喜欢任何有意义或无意义的批评。Just For Fun！ No Class！
CSDN不知道是为了强烈证明微软的SQL SERVER的强健性，每日每夜总要无数次地为我们展现连接池满的异常提示。为了删除发表上一篇文章时按了N次F5的后遗症，我再一次NF5，总算把多余的文章给删除了。
上次提到的是主题和样式，而这回要提到的是Master Page（有称呼为母页面或者主页面的，总觉得不是很清楚，因此使用英文原词）也是ASP.NET 2.0针对WEB特性的改进之一吧。感觉2.0把普通的WEB特性都引入到服务器了。Master Page从设计上来看有点像是服务器端的框架。
不管是ASP开始的include还是ASP.NET的用户控件，都是页面公共部分的一个解决方案。而2.0引入的Master Page则给了一个更好的选择。
Master Page实际上更像Dreamweaver的模板，只不是，它是实际存在的，而不像Dreamweaver只是存在于设计时。Master Page定义了一个共同风格站点的框架，在它的内部使用占位符来表示实际可以修改的部分。具体语法如下。
在页面的声明中取代Page指令的是Master指令，如<%@ Master Language="C#" %>。Master Page中的语法和普通的页面并没有多少差别，不过有一个占位符控件。如<asp:contentplaceholder id="FlowerText" runat="server"/>。在占位符中的内容则是它的默认内容，如果在使用这个Master Page的ASPX页面中没有为这个占位符提供新的定义，那么它将显示它的默认内容。为了和普通页面区分开来，Master Page以后缀名.master结束。
在页面中使用Master Page的方法是在Page的声明中的MasterPageFile属性指定Master Page的路径。在页面中可以通过定义占位符的内容来显示不同的效果。语法如下（例子Copy自QuickStart）：
<asp:content id="Content1" contentplaceholderid="FlowerText" runat="server">
With sunshine, water, and careful tending, roses will bloom several times in a season.
</asp:content>
实际上，页面中如果引用了Master Page，就只能定义占位符对应的内容了。那么不同文件的标题呢？在Page指令中。一个Title属性指定了每页的标题。
Master Page并没有解决链接的相对路径问题，非常遗憾，我们还是得使用绝对路径或者应用程序相关路径（ASP.NET特定的~）来为不同路径下的引用解决路径问题。
为了在代码中调用并修改Master Page的内容，在页面中加入如下指令<%@ MasterType VirtualPath="Site.master" %>。在代码中使用Master. 就可以调用Master中的内容了，这里的调用有两种方法，提供强类型方式的属性或者直接操作Master Page中的控件。
Master Page是可以嵌套的，可以轻松为一个站点制定一个总的框架，再为每个部分制定一个更详细的框架。
在一个Master Page中引用另一个Master Page的语法和Page是一样的，因此，它也只能包含asp:content这样的东东了。
最近的学习都缺少实践，但是对于（形容词略去大约500个字）的我来说，it's nothing。如果在实践后有什么新的看法，再写新的笔记吧。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
