将 .NET 3.5 程序反编译为 C#，导出问题答案

【问题标题】：Decompiling a .NET 3.5 program to C#, issues with exporting将 .NET 3.5 程序反编译为 C#，导出问题
【发布时间】：2013-09-10 23:11:50
【问题描述】：

有一个相当老的程序我必须修改以进行一些相对较小的更改 - 有一些控制变量，如枚举结构、魔术字符串和来自以太的数字，在过去 4-5 年左右的时间里运行良好，但现在都不好了。然而，自然而然地，在随后的几年里，代码已经丢失，所以我们只有一个反编译选项。

我已经使用 dotPeek 和 JustDecompile 从 .dll 文件和 .exe 文件中获取 .csproj 文件（总共有 4 个 dll 和 1 个 exe），但是这两种解决方案都以几乎无穷无尽的语法流告终错误，以及在 dotPeek 的情况下，诸如对编译器变量的引用等问题的符号。

显然，我可以尝试仔细检查每个文件并尽我所能修复每个语法错误，但看起来这可能需要一周的努力。我以前从来没有做过反编译的方法，所以当我意识到我正在看的路径时，我立即怀疑我是否不知道自己在做什么。

对于.net 中的反编译项目，这种情况听起来正常吗？有什么方法可以更有效地制作可构建的项目？我用错工具了吗？这是混淆的症状吗（我完全没有经验）？

提前致谢，如果需要更多信息，请离开 cmets - 因为这有点超出我的范围，我不能完全确定什么是有用的信息，什么不是。

【问题讨论】：

您可以尝试 ILSpy，以确保 :-)
当然，我会试一试！当然不能再坏了！ :p
一定要使用最新的程序更新。 dotPeek 的早期版本存在错误，最新版本 (1.1.1.33) 似乎更适合我的项目。
我已经看到了很多 - 从 .NET 3.0（或 3.5，我不记得是哪个）开始，当他们开始向 C# 添加大量编译器技巧时，如 lambda、自动属性和像这样的东西，反汇编的代码很难重新组装。我建议的一件事是尝试 .NET Reflector - 它们的存在时间最长，因此它们很有可能已经解决了部分或全部问题。它不再免费，但如果它能够解决您的问题，可能值得付费。

【解决方案1】：

我使用过 dotPeek、ILSpy 和 Reflector，它们在反编译成 C# 代码方面似乎都做得很好。我只反编译了一个完整的项目，这是使用 Reflector 的，它需要大量的手动工作来重新组装项目源代码并使其工作。

我怀疑混淆是您面临的问题；他们要么停止上述工具的反编译，要么将它们反编译成代码的混淆（但工作）版本。在那种情况下，代码对于人类来说没有多大意义。

有时，这些无穷无尽的语法错误流实际上是一些缺失的引用。我不知道为什么编译器变量会出现在反编译代码中，因为它们不应该出现在可执行文件中。

最近我遇到了和你一样的问题，在使用其中一种工具检查代码时，我使用了 Mono.Cecil 库来更改现有的程序集。这有点hacky，但在我的情况下节省了一些时间。我相信 Mono.Cecil 带有 ILSpy 包。

【讨论】：

我现在正在玩 ILSpy 的反编译，但你的解决方案很有趣。能否请您稍微详细说明一下该库的使用方式？
是的，ILSpy 反编译仍然存在大量错误，需要永远修复。在研究了 Mono.Cecil 库之后，它看起来非常棒，但是有没有一个项目可以开箱即用地实现它？如果花一周时间纠正编译错误听起来很蹩脚，那么花一周时间制作一个项目只是为了可视化我需要播放的程序集，听起来也很蹩脚。在谷歌搜索或搜索 github 时，我没有看到它的“标准”实现。
这是他们的常见问题解答：mono-project.com/Cecil:FAQ - 我明天会发布一些我使用的代码。
@YYY 请参阅pastebin.com/j8hRW3Zx - 我必须替换分配给属性的字符串值（我看到我复制粘贴了第二种方法的文档）。使用 IL 而不是 C# 需要一些时间来适应。
搞笑的是，Cecil 在尝试打开这个 DLL 时实际上抛出了一个错误，声称它不能被反汇编。随着我进一步深入，越来越明显的是，几个匿名类型被用作方法返回签名会导致大量反编译问题。这是一个非常不标准的事情，所以我不确定现在有什么可以处理它。