days of linnchord » 项目迁移 http://linnchord.net 南台静坐 : : : Thu, 03 Nov 2011 02:22:39 +0000 en hourly 1 http://wordpress.org/?v=3.2.1 ASP.NET2.0的编译部署和VS2003到VS2005的项目迁移.2 http://linnchord.net/archives/9.html http://linnchord.net/archives/9.html#comments Fri, 06 Jul 2007 11:32:13 +0000 linnchord http://linnchord.net/2007/07/aspnet20%e7%9a%84%e7%bc%96%e8%af%91%e9%83%a8%e7%bd%b2%e5%92%8cvs2003%e5%88%b0vs2005%e7%9a%84%e9%a1%b9%e7%9b%ae%e8%bf%81%e7%a7%bb2/ 接着昨天……

VS2003到VS2005的项目迁移远没有想象的“可怕”，如果你只是转化为VS2005SP1支持的Web应用程序，那几乎没有什么多余的工作可作，使用VS2005打开SLN项目文件，随着向导一路按下去就可以完成转化工作了。

我的项目中有2个Web项目，转化时会在VSS中签出工程中的所有文件——如果不是VSS那么应该需要事先手动签出，转化会自动识别隐藏代码文件中的控件声明，并转移到一个新建的.aspx.designer.cs文件中，以此来实现兼容。

出现的问题

  • 部分文件无法识别，导致控件声明重复、缺失。这个很简单，可以删除.aspx.designer.cs文件，仍然使用原有的代码隐藏声明模式，或把隐藏代码中的声明删除，迁移到.aspx.designer.cs文件中，都可以很方便的解决。
  • ASP.NET2.0会有一些新的推荐方法替代旧的方法，例如最常用的可能就是读取AppSettings的方法了，虽然旧的方法仍然可用，不过只需要通过简单的“查找/替换”操作就可以在解决方案内替换所有会被编译警告的方法，追求品质嘛。
  • 回发或回调参数无效，这是一个兼容异常，通常是由于页面存在多个form或有js在客户端修改了数据造成，在ASP.NET1.1中会兼容这个异常不会报错，但是2.0中无法运行，需要进行修改。

这些是我在迁移中遇到的异常，更多的可以参考我昨天的文章 http://linnchord.net/archives/10

ok 祝大家顺利迁移，奔向2005　…… 2007就快出来了啊……

]]> http://linnchord.net/archives/9.html/feed 0 ASP.NET2.0的编译部署和VS2003到VS2005的项目迁移.1 http://linnchord.net/archives/10.html http://linnchord.net/archives/10.html#comments Thu, 05 Jul 2007 15:36:25 +0000 linnchord http://linnchord.net/2007/07/aspnet20%e7%9a%84%e7%bc%96%e8%af%91%e9%83%a8%e7%bd%b2%e5%92%8cvs2003%e5%88%b0vs2005%e7%9a%84%e9%a1%b9%e7%9b%ae%e8%bf%81%e7%a7%bb1/ 旧有系统总在不停的维护中，这两天维护一个网上商城的系统，我试图把他迁移到ASP.NET2.0/VS2005环境下。

由于种种关于迁移失败导致崩溃的信息给我带来的恐惧感，我花了一个下午的时间查询相关资料，详细考察了ASP.NET2.0/VS2005的编译部署机制和相关迁移文档，以确保整个过程顺利实施。

网上相关文档

首先需要确定迁移到哪种项目模式下。根据文档的描述，在VS2005中的ASP.NET网站有下面几种编译部署方式。

  • Web网站项目：VS2005提供的新的Web项目模式，没有项目文件控制，直接把一个物理目录视为项目，目录中的所有文件都是项目文件。
    • 完全编译：通过“网站发布”功能，在发布对话界面上取消所有选项（包括默认选项），可以将网站所有.NET文件(aspx/asmx/ashx/cs…)全部编译为一个DLL程序集，留下的只有非.NET相关的其他图片、样式表、js等文件和aspx占位文件。你可以打开占位文件查看，里面什么内容都没有……呵呵，这真是一种有意思的部署方式，可惜，这绝不适用于大多数一般网站开发项目。
    • 可更新预编译：这是VS2005默认的编译模式，在“网站发布”中选中“允许更新此预编译站点”，这样会保留aspx等非后端隐藏代码的程序文件内容，使你可以方便修改HTML内容并即时生效。这种部署方式最大的问题在于aspx页面会在发布时自动指向程序集，而每次编译的程序集文件名会发生变化，这就导致如果你修改了任何一个程序逻辑并重新编译，就不得不上传所有网站内的程序文件……这在实际网站开发中几乎也是不可接受的，且不论重新上传所有页面的操作代价，这几乎就否定了网站上传后其他人员如设计师直接修改aspx页面的可能，除非将设计师的工作也置于代码控制之下，这是难以实现的。
    • 固定命名和单页程序集编译：这个选项会解决上面的随机程序集命名问题，这个模式下的编译会把每个ASPX文件都编译为一个单程序集，每个程序集后会添加随机数，不过这个随机数是固定的。我试图查找这个随机数的生成依据，不过没有找到，推测应该是根据解决方案中的GUID。把这个选项和前面“可更新预编译”相结合，可以得到较好的编译方案……好吧，我得承认我忽略了生成数十或者以百计的单页面dll的繁琐，不过这是一个优劣并存的方案，因为当你只更新一个页面的逻辑时，可以只上传一个较小的dll，且不影响整个网站的运行，这也是一个不错的优势了。
    • 完全源码部署：这是一个很省心的方案，不做任何编译，直接COPY部署就OK，不过这是另一个极端，估计很少情况会采用——不过可以用来做测试部署，很方便。
  • Web应用程序项目：MS认识到到了“Web网站项目”带来的种种问题，在VS2005SP1中正式提供了这个原有的VS2003的项目模式。这样可以指定目录中的文件为项目文件——必须承认这是一个不可放弃的优势，所以虽然新的“Web网站项目”也有种种优势，但是我还是不得不采用这个“老”方案了。可以想象，如果采用新方案，我就得面对项目运行维护时在项目目录中骤增的数以百计、千计的运行时文件，还不得不接收由此带来的超长时间的编译及发布copy，这会使人崩溃的……

编译部署的方案就是上面这些了，VS2005的网站项目应该说是有很多优势的，不过用一句老话讲，这些改进并不符合中国国情，或者至少不符合一大部分中国网络服务供应商的运行状况。这些改进都是需要在业务相对稳定，有较严格代码控制等情况下才能较好的实施，而中国目前估计除了企业开发外，在一般的网络运营下少有这样的环境。其实从这些改进和现状的冲突，就可以看出国内和国外行业水平的差异，呜呼哀哉……

写太多了，迁移稍后吧……

]]> http://linnchord.net/archives/10.html/feed 0