转眼间，距离微软推出.net平台已经4年了，.net也经历了 从 1.0 到 1.1 再到2.0的升级。 由于 asp.net 2.0 和vs 2005 IDE的各种优越特性的吸引，大伙都忙着学习2.0，将项目升级至vs 2005 下面开发。 但实际上，很多项目由于种种原因，无法升级到新版本。随着时间的变迁，老版本的项目维护问题越来越让人头痛。虽然.net诞生时间不长，但4年的时间足够积累一量的项目。
我手上就有个用vs.net 2002开发的项目，由于种种原因一直没有升级（主要是因为该项目在vs.net 2003出来之前已经良好运行了一段时间，并且服务器上的其他asp.net程序无法适应.net 1.1的安全性要求。）
当初公司开发平台升级时，在电脑上同时安装vs.net 2002 和vs.net 2003, 暂时性的解决了不同版本的项目的维护。再后来，项目过了维护期了，很久没更新了，我电脑也重装了，vs.net 2002就彻底扫地出门了。可到了2005年，客户每隔1，2个月就提出修改要求，而且要快，没办法 ，客户太牛B，过了维护期也要改。可问题来了，没有vs 2002，无法编译啊。
在电脑上装个.net framework 1.0, 使用手工方式调用 csc 编译修改后的代码，非常麻烦，项目有一堆引用，编写命令行很繁。特别是项目有很多文件夹时更痛苦。也考滤过写个程序编译，但我懒，一直没实现。
今天又碰上要修改程序，突然想起很早的时候（2002年）使用过一次 @Page指令的 Src 属性，使用此属性，asp.net将采用自己的编译模型而不是使用vs.net IDE的CodeBehind方式，代码无需编译成dll 便可发布，访问站点时，asp,net会自动将aspx文件 和 .aspx.vb 文件一起编译。 这种方式的缺点主要有两个：1、 代码文件(.vb) 必须发布到服务器上, 2、vs.net IDE 不支持。 因为第二个问题的原因，后来放弃使用了，这事也就忘了。 现在正愁没办法编译程序呢，只要能让修改的代码生效，其他的缺点都不考滤了。 反正所有的源代码都发布到服务器上了。 我在@Page 指令中 加了个 Src属性，使用的值与CodeBehind 属性的值相同，指向代码文件。再将.vb 文件中的代码修改完毕。刷新，修改生效，维护完成。爽啊。以后就这么干了。由于vs.net IDE 不支持，MSDN上也是一笔带过，未必有很多人知道.net具有这种编译模型。现在将其共享出来，如果有人也正经受我一样的痛苦，您也可以考滤在页面中添加Src，呵呵，简单快捷，改完代码就生效，不用再绞尽脑汁找工具编译了。
总结： 包括我在内的许多人，都更喜欢将程序编译成dll,感觉这才更像一个发布的软件。其实，采用“将所有源代码发布到服务器，运行时完整的编译代码”的方式非常不错，大大简化日后的维护工作。很多公司为客户作的项目其实没必要对客户隐藏源代码。在这种情况下，使用这种方式为以后的维护工作带来巨大的好处，无论.net 升级了n次，不管你电脑上是否装有相应版本的开发工具，你都无需担心，用记事本都可以搞定一切。
注意： 所有版本的 asp.net都支持此编译模式，但vs.net 2002和2003的 IDE不支持，无法打开设计视图。 刚出来的vs 2005 IDE支持这种编译模式。 使用Src 属性时，CodeBehind属性不再需要了，但建议你仍然保留，如果你突然需要回到计视图，它还可以帮你的忙。 Inherits 属性也不需要，但强烈建议你不要删除它，因为如果你在aspx文件的控件声明中直接绑定了事件（如： OnClick="....") ，没有Inherits属性会报错。
我手上就有个用vs.net 2002开发的项目，由于种种原因一直没有升级（主要是因为该项目在vs.net 2003出来之前已经良好运行了一段时间，并且服务器上的其他asp.net程序无法适应.net 1.1的安全性要求。）
当初公司开发平台升级时，在电脑上同时安装vs.net 2002 和vs.net 2003, 暂时性的解决了不同版本的项目的维护。再后来，项目过了维护期了，很久没更新了，我电脑也重装了，vs.net 2002就彻底扫地出门了。可到了2005年，客户每隔1，2个月就提出修改要求，而且要快，没办法 ，客户太牛B，过了维护期也要改。可问题来了，没有vs 2002，无法编译啊。
在电脑上装个.net framework 1.0, 使用手工方式调用 csc 编译修改后的代码，非常麻烦，项目有一堆引用，编写命令行很繁。特别是项目有很多文件夹时更痛苦。也考滤过写个程序编译，但我懒，一直没实现。
今天又碰上要修改程序，突然想起很早的时候（2002年）使用过一次 @Page指令的 Src 属性，使用此属性，asp.net将采用自己的编译模型而不是使用vs.net IDE的CodeBehind方式，代码无需编译成dll 便可发布，访问站点时，asp,net会自动将aspx文件 和 .aspx.vb 文件一起编译。 这种方式的缺点主要有两个：1、 代码文件(.vb) 必须发布到服务器上, 2、vs.net IDE 不支持。 因为第二个问题的原因，后来放弃使用了，这事也就忘了。 现在正愁没办法编译程序呢，只要能让修改的代码生效，其他的缺点都不考滤了。 反正所有的源代码都发布到服务器上了。 我在@Page 指令中 加了个 Src属性，使用的值与CodeBehind 属性的值相同，指向代码文件。再将.vb 文件中的代码修改完毕。刷新，修改生效，维护完成。爽啊。以后就这么干了。由于vs.net IDE 不支持，MSDN上也是一笔带过，未必有很多人知道.net具有这种编译模型。现在将其共享出来，如果有人也正经受我一样的痛苦，您也可以考滤在页面中添加Src，呵呵，简单快捷，改完代码就生效，不用再绞尽脑汁找工具编译了。
总结： 包括我在内的许多人，都更喜欢将程序编译成dll,感觉这才更像一个发布的软件。其实，采用“将所有源代码发布到服务器，运行时完整的编译代码”的方式非常不错，大大简化日后的维护工作。很多公司为客户作的项目其实没必要对客户隐藏源代码。在这种情况下，使用这种方式为以后的维护工作带来巨大的好处，无论.net 升级了n次，不管你电脑上是否装有相应版本的开发工具，你都无需担心，用记事本都可以搞定一切。
注意： 所有版本的 asp.net都支持此编译模式，但vs.net 2002和2003的 IDE不支持，无法打开设计视图。 刚出来的vs 2005 IDE支持这种编译模式。 使用Src 属性时，CodeBehind属性不再需要了，但建议你仍然保留，如果你突然需要回到计视图，它还可以帮你的忙。 Inherits 属性也不需要，但强烈建议你不要删除它，因为如果你在aspx文件的控件声明中直接绑定了事件（如： OnClick="....") ，没有Inherits属性会报错。
