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

Question

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

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

Answer 1

我已经在客户端项目多次上完成了这项工作，并像其他评论员一样使用Reflector。这种事情经常发生，而不是应该发生。例如，当有人突然离开开发团队时。在一个项目中，我的团队成员在整个开发团队离开之后被召集进来，我们不得不对生产中运行的每一段代码都遵循这个程序，以确保我们实际拥有的东西。

我处理它的方法是将每个版本的已编译代码放在文件系统的单独区域中。这包括源代码控制或开发工作站之外的版本。这很重要，因为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这样的工具来获取做出决定的实际不同的报告。

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

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

第一次，这看起来令人生畏，但是我的团队成员已经发现，在以后的项目中，他们往往看起来像是在出现令人讨厌的情况时能够看似完成不可能的英雄。 ，让它值得你进入你的工具箱。

Answer 2

如果我遇到你的情况，我会一次一个地编译4个独立的源项目......然后运行diff add-in for .NET Reflector以查看你是否与生产组件匹配。如果没有，编译下一个源项目并再次尝试差异。

Answer 3

如果项目目录包含构建工件（如DLL和EXE），则可以检查版本号并与生产中的版本号进行比较。即使你没有完全匹配，你也会看到最接近的东西。

Answer 4

.NET Reflector是一个方便的工具，可以查看给定服务器上正在使用的代码。