转眼间,距离微软推出.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属性会报错。