这几天升级了一下原来的1.1项目，发现了一些问题，总结一下放在这里，也提醒还没有来得及升级或准备升级的朋友，升级的过程中少走弯路，少浪费时间。
1．Global.asax文件的处理形式不一样，转化后将出现错误，在vs2003中Global.asax具有代码后置文件，2.0下, 将代码分离文件移到 App_Code 目录下，以便使其自动变为可通过应用程序中的任意 ASP.NET 页面访问。“Code-behind”属性将从 ASAX 文件的指令中删除。vs2005则直接把代码写在Global.asax。所以需要删除转化过来的文件重新加入，并把相应的代码copy过来。
2．2.0没有了项目文件。 在 1.1 应用程序中，项目文件包含生成设置、对外部程序集的引用以及项目中的文件列表。而在 2.0 应用程序中，不再需要版本设置和文件列表，因为 Web 项目目录下的所有文件都被视为 Web 项目的一部分。
3．代码分离模式。
在 ASP.NET 1.1 中，代码分离模式使内容（例如 test.aspx）与代码（例如 test.aspx.cs）分离。内容页面从代码分离页面继承而来，代码分离页面包含用户和设计器生成的代码。
ASP.NET 2.0 通过使用局部类来增强代码分离模式，使用 partial 关键字可以将单个类的代码分隔到两个独立的文件中。它允许一个类跨越多个文件。在新的代码分离模式中，内容页面从编译的类继承而来，它由相应的代码分离页面以及自动生成的存根文件组成，存根文件用于为内容页面中使用的控件定义字段声明。此项更改使自动生成的代码与用户的代码分离，并且使代码分离页面显著变小且更加简洁。局部类结构还降低了由于编辑设计器生成的代码而不小心破坏页面的风险。
如果出错请检查是否有partial 关键字，否则添加 partial 关键字。
4．语法检查。asp.net1.1程序，编译时不会检查aspx、aspcx等文件中的语法错误，而vs2005编译时会检查项目中所有的aspx、aspcx等文件中的语法，所以如果有语法错误，会导致编译无法通过。
5．控件声明。如果在 .aspx 页面上声明了所有控件，则从代码分离文件中删除所有控件声明，否则报错：重复定义。
6．（仅限于 C#）将事件挂钩代码从代码分离文件的 InitialzeComponent 函数移到 .aspx 页面中。请注意，此操作不适用于自动调用的事件，包括 Page_Init、Page_Load、Page_DataBind、Page_PreRender、Page_Unload、Page_Error、 Page_AbortTransaction 和 Page_CommitTransaction。
7．部署方式（预编译、完整编译、可更新站点等）。在 1.x 中，Web 应用程序是作为一个大型程序集而预编译和部署的。内容页面（*.aspx）不在服务器上编译，但可以在服务器上编辑。借助新的页面编译模式和目录结构，您就可以使用多种不同的配置来部署 ASP.NET 2.0 应用程序。一种情况，您可以预编译所有的 ASPX 页面并部署由完全编译好的程序集组成的 Web 应用程序。在这种模式下，您不能在服务器上轻松地更改该应用程序。另一种情况，您可以在不预编译任何代码的情况下部署应用程序。在这种配置下，您可以直接在服务器上更改该应用程序中的 .aspx 页面、代码分离文件或其他任何代码。当用户请求服务器上的页面时，页面将被动态编译。
8．将 .aspx 页面中的所有 CodeBehind 属性更改为 CodeFile 属性
CodeBehind: 指定包含与页关联的类的已编译文件的名称。该属性不能在运行时使用。
提供此属性是为了与以前版本的 ASP.NET 的兼容，以实现代码隐藏功能。在 ASP.NET 2.0 版中，应改用 CodeFile 属性指定该源文件的名称，同时使用 Inherits 属性指定该类的完全限定名称。
CodeFile 指定指向页引用的代码隐藏文件的路径。此属性与 Inherits 属性一起使用可以将代码隐藏源文件与网页相关联。此属性仅对编译的页有效。
9.将所有独立的代码文件和AssemblyInfo.cs都被移到 App_Code 目录下。
但运行转换向导之后，您可能会发现某些代码分离文件（例如，*.aspx.cs 或 *.ascx.vb）被移到 App_Code 目录下。这表明代码分离文件的内容页面含有格式不正确的 Codebehind 指令，并且没有进行正确设置。也就是说，转换向导不能确定该代码分离文件是否实际绑定到某个特定的 .aspx 页面。
10.Web 服务
在 ASP.NET 1.x 中，Web 服务 (.asmx) 自动拆分到空白标题页面 (.asmx) 和包含实际方法的代码分离文件中。
Asp.net2.0下：
• 将代码分离类移到 App_Code 目录下，以便使其自动变为可通过应用程序中的任意 ASP.NET 页面访问。
• 更改 .asmx 文件中的 CodeBehind 属性，以便指向新位置。
（请注意，代码分离文件不使用局部类，因此继续使用 CodeBehind 属性。）
• 将所有的默认、Friend 和 Internal 范围的声明更改为 Public。
在1.1到2.0的升级过程中，你遇到过什么样的问题呢？可以写下来让大家共同学习，少走弯路。
当你准备将Web应用程序从ASP.NET 1.1升级到ASP.NET 2.0，你将面对这样一个cookie问题：在ASP.NET 1.1应用程序中客户端保存的所有cookie将失效。
博客园也遇到了这样的问题，对博客园来说，意味着所有使用cookie的用户都需要重新登录，虽然这不是一个很大的问题，但的确给大家带来了麻烦，如果忘记了密码，将更加麻烦。
对于一个非常重视用户满意度的网站来说，应该努力去解决这个问题。博客园希望尽可能减少升级带来的影响，所以这两天我一直在研究这个问题并找到了解决方法。
问题的原因是：当程序从ASP.NET 1.1升级到于ASP.NET 2.0后，ASP.NET 2.0使用新的算法与密钥对客户端发送过来的cookie进行解密，这样导致ASP.NET中生成的cookie在ASP.NET 2.0中失效。在ASP.NET 1.1中，使用3DES算法对cookie的内容进行加密，而在ASP.NET 2.0中默认使用Advanced Encrypted Standards （AES）算法进行解密，这是引起问题的原因之一，通过相应的设置可以将ASP.NET 2.0中将cookie加密算法改为3DES，只需在web.config中加上：
如何解决这个问题呢？
原理很简单，只要我们知道在ASP.NET 1.1中随机生成的密钥的值，然后在ASP.NET 2.0应用程序的web.config中进行指定就行了，这里的密钥有两个：一个是加密密钥decryptionKey，一个是散列计算密钥validationKey（防止cookie被中途篡改）。假如我们知道密钥分别为：X、Y，那在web.config进行如下设置就能解决问题：
由于博客园主要是解决登录cookie的问题，而这个cookie是在System.Web.Security.FormsAuthentication. SetAuthCookie（string userName， bool createPersistentCookie）中生成的，所以我就从ASP.NET 1.1的System.Web.Security.FormsAuthentication的源代码下手，发现了System.Web.Configuration.MachineKey，经过进一步对MachineKey的源代码进行研究，在MachineKey的MachineKeyConfig中发现了两个密钥分别存在于s_validationKey与s_oDes这两个私有静态成员中（发现这个费了不少功夫），validationKey的值直接存储于s_validationKey中，而decryptionKey存储于s_oDes.Key中。由于MachineKey是internal class，MachineKeyConfig是私有类型，那两个成员是私有静态成员，无法直接访问。这时，该是。NET中强大的反射功能发挥作用的时候了。通过反射得到这两个值，需要注意的是这两个值的类型是Byte[]，通过测试发现直接转换成字符串生成的密钥无效，需要通过反射调用System.Web.Configuration.MachineKey.ByteArrayToHexString（Byte[]， Int32） 转换成字符串。
今天晚上终于解决了这个问题，好兴奋！中途几次想放弃，但想到在博客园程序升级到ASP.NET 2.0后，会因为这个问题给很多人带来麻烦，虽然只需要重新登录一下就行了，但我还是觉得要解决这个问题，做程序开发不就是尽可能给用户带来方便吗？
解决了这个问题就为博客园网站升级到ASP.NET 2.0作好了进一步的准备。
费了好一袋烟工夫把CommunityServer升级到了Asp.Net2.0平台，一点心得：
vs2005可以很方便的帮我们把vs2003开发的asp.net1.1版本项目升级到vs2005开发的asp.net2.0版本，从vs2005里面打开vs2003的解决方案或者项目文件，会有向导帮我们自己完成升级工作。一部分asp.net1.1的项目做完这个工作就足够了。
不过更多的时候不会这么顺利，还要注意一些问题：
- vs2003开发的asp.net1.1程序，不会检查aspx、aspcx等文件中的语法错误，而vs2005会检查项目中所有的aspx、aspcx等文件中的语法，所以如果有语法错误，会导致编译无法通过。
- vs2003中，如果用的是默认的代码绑定方式，那么在aspx文件（以aspx文件为例，ascx文件也有这个问题）中申明的服务器端控件，会在aspx文件对应的aspx.cs文件中，生成一个对应的申明，例如aspx中有一个TextBox，ID是MyTextBox，那么在aspx.cs中，会申明一个"protected TextBox MyTextBox;"，而在vs2005中，这个申明是多余的，所以升级后要去除这些多余的申明。
- 如果有程序采用了asp.net1.1下的Membership——使用MemberRole.dll，要升级到asp.net2.0下的Membership，需要做如下工作：
- 删除所有项目中对"MemberRole.dll"的引用，添加"System.Configration"的引用
- 改变命名空间ScalableHosting.Profile -> System.Web.Profile;ScalableHosting.Security -> System.Web.Security; 同时添加using System.Configuration;
- 移除所有MemberRole.dll相关的Membership配置，参照以前的Membership配置，增加asp.net2.0支持的Membership配置，更新Membership的存储过程。
- CCS1.1 for asp.net2.0的下载：http://www.communityserver.cn/builds