将 ASP.NET 源代码与已编译的 Web 应用程序匹配 [关闭]答案

【问题标题】：Matching ASP.NET source code to a compiled web application [closed]将 ASP.NET 源代码与已编译的 Web 应用程序匹配 [关闭]
【发布时间】：2009-07-13 19:49:26
【问题描述】：

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

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

【问题讨论】：

标签： asp.net reflection reflector

【解决方案1】：

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

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

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

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

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

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

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

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

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

【讨论】：

+1 以获得出色的细节，以及像我这样的反射菜鸟的精心设计的演练

【解决方案2】：

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

【讨论】：

+1 表示 diff 插件的链接。

【解决方案3】：

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

【讨论】：

版本号可以是任意的。您需要拆卸工件并从那里确定。
是的，它们可以是任意的，但您可能需要 很长时间 时间来分解这些工件。所以我的回答是务实的，但是 YMMV。

【解决方案4】：

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

【讨论】：