VS2005正式版在这个年末终于Release了(还不出炉，那就要成Vs2006了)，忙完手头的项目,明年的项目估计是得在Vs2005上做了，原来的项目还得维护，想想要能把以前的项目直接转移过来才好，要不机器上还得装两个VS，麻烦！
简单弄了一下，才发现从从ASP1.X到ASP2.0还没那么容易。搞这一行就是苦啊，一些东西还没玩热手，又有新的要学了。虽然ASP2.0是ASP1.X的一个升级，但不仅仅引入了一些新的特性，在设计，编译，部署方面都有根本性的变化。
1.没有工程文件了
很明显的差异，在Asp2.0中没有工程文件了（*.vbproj or *.csproj）.在Asp1.x，工程文件包含了编译设定，要引用的外部Assembly，以及一个工程中所有的文件的列表。在2.0中，Web项目中的每个文件都会被认为是Project的一部分，基于的信息就移到了Solution和Web.Config里面了。
2.新的文件夹结构
在1.x中只有bin文件夹是特殊的，用来存放相关的Assemble，在2.0中，新增的以“App_”的文件夹分别用来资源文件，源代码，Assembly等等，采用这个新的结构可以部分消除没有工程文件所带来的影响，同时也对VS2005新的部署方式提供了支持。
3.Code-behind
在1.x中，Code-behind Modle将Content(Test.aspx)和Code（Test.aspx.cs）分离，Content继承了Code，Code将包括VS由Test.aspx生成的代码及用户自定义代码。在2.0中，由于添加partial关键字，Code-behind Modle也允许将一个类中的代码跨越多个文件，Code将只包括用户定义代码，在编译的时候，Content将继承Code与由Content自动生成的存根（stub file）共同组成的类。这样子使得Code比较小，很清爽。
4.编译
在1.x中，所有的Code-behind文件都会被预编译到一个单独的Assembly中，但在2.0里却会生成多个Assemgly。例如：在ASP.Net默认的编译设置下，
所有的WebFrom和UserControl都会被编译到按文件名称放到不同的Assembly里，而App_Code中的文件将会被编译到另一个Assembly中。这种改变极大影响了整个项目的结构，
但对项目的部署也带来极大的灵活性。
5.部署
在1.X里，整个项目将会被预编译成一个大的Assembly（包括它依赖的其它Assembly），然后将这些Assembly和Forms页面一起部署到服务器上。
在2.0时，由于文件夹结构和编译模型的变化，部署方式也有了好几种选择，比较极端的一种是，可以将Forms页面，Code-behind代码等等一起进行预译成一组
Assembly，部署也只要将这些Assembly拷贝到服务上就可以，但这种方式也很不利于维护，而另一种极端方式就是不进行预编译，将所有文件拷贝到服务上，
在用户请求时再编译，所有的Form及代码都可以随时修改。
我们以前的项目很多都用了页面继承和用户控件的继承，由于Code-behind模型和编译模型的变化，实现它们的方法也有了一些变化。
1.动态装载UserControl
在1.x里，动态装载UserControl是很简单的，
例如：MyControl myControl = (MyControl)LoadControl("~/MyControl.ascx");
而在2.0里，却还需要在页面里加上<%@ Reference Control="~/MyControl.ascx" %>
这里就有了一个问题，如果我要装载的UserControl是不可预知的，那我必需把在页面添加所有的可能的UserControl引用，麻烦。
再如果我可能在运行时生成UserControl，那么装载这样的UserControl，那就还必需在动态修改页面的引用
2.UserControl继承
在1.x里，例如有 UserControl基类
public class BaseUserControl : System.Web.UI.UserControl{...}
继承：
public class DerivedControl :BaseUserControl{...}
BaseUserControl只需要在一个CS文件定义就可以(BaseUserControl只是一个普通的类)
在2.0中，则BaseUserControl必需定义在一个UserControl里面，就是BaseUserControl必需是一个完整的UserControl（包括*.ascx和*.ascx.cs或*.ascx.vb）
假如已经定义一个完整的BaseUserControl
继承：
在DerivedControl.ascx.cs中
public partial class DerivedControl : BaseUserControl{}
在DerivedControl.ascx中必需添加 <%@ Reference Control="~/BaseUserControl.ascx" %>
而且它还必需在<%@Control%> 的前面
<%@ Control Language="C#" AutoEventWireup="true" CodeFileBaseClass="BaseUserControl"
CodeFile="~/DerivedControl.ascx.cs" Inherits="DerivedControl" %>
CodeFileBaseClass指定父类类型
3.Page继承
与UserControl继承类似，需要从一个完整Page×(包括*.aspx和*.aspx.cs)来继承
在1.x里，例如有 Page基类
public class BasePage : System.Web.UI.Page{...}
在DerivedPage.aspx.cs中
public partial class DerivedPage : BasePage{}
在DerivedPage.aspx中必需添加 <%@ Reference Control="~/BasePage.aspx" %>
它也必需在<%@Page%> 的前面。
<%@ Control Language="C#" AutoEventWireup="true" CodeFileBaseClass="BasePage"
CodeFile="~/DerivedPage.ascx.cs" Inherits="DerivedPage" %>
要指出的是DerivedPage.aspx存根代码(即ASPNet2.0由*.aspx自动生成的那部分)会隐藏BasePage.aspx的存根代码
例如在BasePage.aspx中定义一个控件如Label1,而在DerivedPage.aspx没有定义它，而在DerivedPage中加入了操作Label1的代码，在预编译的时候，都是正常的，但在运行时访问DerivedPage.aspx就会报错，指出对Label1引用没有指定到一个对象的实例。那么我们可以简单地认为，在运行时，ASP.Net只会对所请求的页面的控件进行实例化，当然我们也可以在后台手工进行控件实例化。当然我们访问BasePage.aspx是不会有错的。
从ASP.Net1.x到ASP2.0绝不仅仅是版本上简单递进，在WEB设计思想更加成熟，也更加规范，也熔入了几年以来ASP.Net开发社区的精华部分，的确让人着迷。上面是我在看了一些资料的想法和心得，并不全面，可能也有理解错误的地方，希望大家能指出来。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
