【问题标题】:How to match .Net deployment with the source that it was compiled from?如何将 .Net 部署与其编译来源相匹配?
【发布时间】:2012-02-10 21:59:30
【问题描述】:

在将 VB asp.net 2.0 代码推送到生产环境后,我们有一名开发人员离职,现在我们需要进行更改,完全不清楚哪个(如果有)可用版本的源代码与部署到生产环境的内容相匹配.

这个问题和上一个问题有点类似:Decompile Precompiled Source Code ASP.NET 除了我想,如果可能的话,确定生产部署是否与我们拥有的源代码版本之一完全匹配。

在我尝试过的事情中:

  1. 1) 我尝试使用各种工具对源代码和生产环境中的 .aspx 文件进行逐个目录、逐个文件的递归比较。但是编译过程更改了头文件,以至于它们不再与编译前的文件匹配,而且我还没有找到可以过滤掉这种差异的工具。无论如何,这还不够。
  2. 2) 我尝试将生产代码反编译为VB,并编译源代码,然后将其反编译为VB。这给我留下了两组反编译的 VB 源代码来进行比较。我使用 Redgate Reflector 和 Denis Bauer 的 File Disassembler 插件来生成源代码。这种方法的问题:反编译器为每个代码集输入不同的变量名,因此所有文件都是不同的,在大量涉及变量使用的地方。
  3. 3) 我在 Sean Hederman 的 Diff 插件中使用了反射器。这应该只是为我们区分 .dll 中的源代码。这里的困难在于大型项目在编译时分布在 5 个或更多 .dll 上。这些 .dll 似乎被赋予了随机名称,并且相同的代码文件可能在一次编译时编译为一个 .dll,而在另一次编译时编译为另一个 .dll。 Diff 加载项似乎只是将一个 .dll 与另一个 .dll 进行比较,因此该工具的范围太大。
  4. 4) Redgate 具有“导出”功能,可以将 .dll 中的源代码导出到一个充满源文件的目录。认为这可能会产生与上面第 (2) 项中的加载项方法不同的结果,我也尝试了它。这一次,我在 IL 中导出了代码,因为我认为这可能与 VB 源代码不同。事实上,即使我认为源文件可能相同,编译器生成的 IL 也完全不同(因为反编译为 C# 的文件除了变量名不同外看起来相同。)
  5. 我还研究了许多其他反编译工具,但似乎没有一个工具能够将如此大的项目反编译成可以比较的大量源代码文件。
  6. 在尝试上述任何方法之前,我查找了具有可识别版本号的文件/.dll,以查看版本号是否可以与生产相匹配。我还没有找到一个。

有没有人有任何想法/工具/策略可以一劳永逸地解决这个问题? 非常感谢!

【问题讨论】:

  • 这个开发者没有使用源代码管理吗?
  • 是的,太好了。源代码控制中有 3 个不同的版本,他的机器上有第四个版本。他们不匹配。这对我们来说不是常态,但在这种情况下,我们必须处理它......

标签: asp.net visual-studio deployment .net-2.0 decompiling


【解决方案1】:

与其尝试反编译生产以查看它是否与源代码匹配,您可以换个方向吗?检索源的每个版本,对其进行编译,然后将结果与生产中的结果进行比较 - 如果您最终得到一组匹配的文件,那么这很可能是用于生产中的版本。

假设版本位于某种源代码控制系统中,您甚至可以编写“签出、构建、比较”过程的脚本。

【讨论】:

  • 您好,感谢您的反馈。我已经按照你的建议做了,但它没有显示源文件中的差异。也就是说,我可以在不更改生成的编译代码的情况下更改源文件,因此不会在此代码和部署的代码之间产生显着差异。
  • 关于如何确定这些版本的源代码中的哪一个(如果有)用于生成部署的任何其他想法?
  • 事实证明我的答案可能无论如何都行不通 - 两次编译相同的源代码并不能保证得到相同的程序集,至少不是为了进行差异:blogs.msdn.com/b/ericlippert/archive/2012/05/31/…跨度>
猜你喜欢
  • 1970-01-01
  • 2021-03-13
  • 2014-04-27
  • 1970-01-01
  • 2013-09-25
  • 1970-01-01
  • 1970-01-01
  • 2016-03-21
  • 2013-07-26
相关资源
最近更新 更多