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

Question

关闭。这个问题需要更多focused .它目前不接受答案。












想改善这个问题吗？更新问题，使其仅关注一个问题 editing this post .

3年前关闭。




Improve this question




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

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

Answer 1

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

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

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

ProjectXyzReconciliation
|-生产
|-分期
|-测试
|-qa
|-devworkstation
|-源控制
|-reconciled(这是最终会回到源代码管理的东西)

然后我使用 WinMerge(但也同样很好地使用了其他合并/比较工具)来比较目录并将它们合并到“已协调”文件夹中。我通常用生产中运行的内容填充它，然后将每个其他版本与它进行比较。

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

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

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

第一次通过时，这似乎令人生畏，但我的团队中擅长这一点的成员发现，在以后的项目中，他们通常看起来像英雄，因为在出​​现令人讨厌的情况时能够完成看似不可能的事情，从而使值得将其放入您的工具箱中。