将ASP.NET源代码与已编译的Web应用程序匹配

Question

我的客户端有一个编译的ASP.NET 2.0应用程序,该应用程序在一年前编译和部署.它们还有4个版本的源代码项目/解决方案,不受源代码控制(存储在以前的开发人员工作站文件系统中).没有文件日期看起来彼此匹配.

有没有办法确定哪些(如果有)这些版本是实际部署到生产网站的版本？

Answer 1

我这样做对客户项目多的时间和使用反射器,像其他评论者.这种事情经常发生,而不是应该发生.例如,当有人突然离开开发团队时.在一个项目中,我的团队成员在整个开发团队离开之后被召集进来,我们不得不对生产中运行的每一段代码都遵循这个程序,以确保我们实际拥有的东西.

我处理它的方法是将每个版本的已编译代码放在文件系统的单独区域中.这包括源代码控制或开发工作站之外的版本.这很重要,因为Reflector看到IL而不是实际的原始源,并且您想要比较苹果和苹果.

我使用FileDisassembler for Reflector将每个二进制文件反编译成一个单独的文件夹.我最终得到一个看起来像这样的结构:

ProjectXyzReconciliation
|-production
|-staging
|-test
|-qa
|-devworkstation
|-sourcecontrol
|-reconciled (this is what will eventually go back in source control)

然后我使用WinMerge(但同样使用其他合并/比较工具)来比较目录并将它们合并到"reconciled"文件夹中.我通常会将生产中运行的内容填入其中并将其与其他版本进行比较.

第一步实际上只是为了看看有什么不同,并且反编译到文件允许您使用像WinMerge这样的工具来获取有关做出决策的实际不同的报告.

有时,此过程会产生一个或两个更改,这些更改很容易追溯到错误跟踪数据库或电子邮件等中的错误,并且可以决定是应该进入还是留在外面进行进一步的工作.

当解释每个差异并将其合并或拒绝以供以后重新工作或删除时,新协调的代码将用作未来开发和重构的新基础.这确实会丢失代码中的任何注释,但是当需要整个过程时,丢失注释并不是一件容易的损失.

第一次通过,这看起来令人生畏,但是我的团队成员已经发现,在以后的项目中,他们往往看起来像是在一个恶劣的情况出现时能够看似完成不可能的英雄,值得将其放入您的工具箱中.