5

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

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

4

4 回答 4

5

我已经多次在客户项目上完成此操作，并像其他评论者一样使用 Reflector。这种事情比它应该发生的更频繁。例如，当有人突然离开开发团队时。在一个项目中，在整个开发团队离开后，我的承包商团队被召集进来，我们必须对生产中运行的每一段代码都遵循这个程序，以确保我们手上实际拥有什么。

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

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

项目XyzReconciliation
|-生产
|-分期
|-测试
|-qa
|-开发工作站
|-源控制
|-reconciled（这是最终将回到源代码控制中的内容）

然后我使用 WinMerge（但也同样使用其他合并/比较工具）来比较目录并将它们合并到“reconciled”文件夹中。我通常用生产中运行的东西来填充它，然后将所有其他版本与之进行比较。

第一步实际上只是查看有什么不同，反编译成文件让您可以使用 WinMerge 等工具来获取有关做出决策的实际不同之处的报告。

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

当每个差异都被解释并合并或拒绝以供以后返工或删除时，新协调的代码将用作未来开发和重构的新基础。这确实会丢失代码中的任何注释，但是当整个过程是必要的时，坦率地说，丢失注释并没有太大的损失。

第一次完成时，这似乎令人望而生畏，但我的团队成员在这方面做得很好，他们发现在以后的项目中，他们往往看起来像是英雄，因为当出现令人讨厌的情况时，他们能够看似完成不可能的事情，使值得将其放入您的工具箱。

于 2009-07-14T13:30:29.687 回答
4

如果我遇到您的情况，我会一次编译 4 个单独的源项目中的每一个……然后运行​​.NET Reflector 的 diff 插件，看看您是否与生产程序集匹配。如果没有，请编译下一个源项目并再次尝试 diff。

于 2009-07-13T19:57:18.313 回答
1

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

于 2009-07-13T19:53:31.847 回答
1

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

于 2009-07-13T19:55:01.390 回答