DotNet Reflector - 为什么我不能反汇编 XmlHierarchicalEnumerable？答案

【问题标题】：DotNet Reflector - why can't I disassemble XmlHierarchicalEnumerable?DotNet Reflector - 为什么我不能反汇编 XmlHierarchicalEnumerable？
【发布时间】：2010-02-16 04:39:43
【问题描述】：

请注意，以下是 dotNet 反射器无法正确拆卸的罕见情况示例。在绝大多数情况下，它都能完美运行，我并不是说这一定是反射器中的错误。这可能是相关程序集上的保护或混淆或非托管代码的结果。

我尝试在 dotnet 反射器中反汇编 System.Web.UI.WebControls.XmlHierarchicalEnumerable。泛型似乎都搞砸了，例如：

// Nested Types
[CompilerGenerated]
private sealed class GetEnumerator>d__0 : IEnumerator<object>, 
    IEnumerator, IDisposable
{
    // Fields
    private int <>1__state;
    private object <>2__current;
    public XmlHierarchicalEnumerable <>4__this;
    public IEnumerator <>7__wrap2;
    public IDisposable <>7__wrap3;
    public XmlNode <node>5__1;

在其他程序集中，我有时会用小方块（我知道这些通常代表“未知符号”）代替类名，例如：

    dictionary1.Add("autopostbackonselect", 0x34);
    ᜀ.ᜌ = dictionary1;
}

if (ᜀ.ᜌ.TryGetValue(key, out num))
{
    switch (num)

什么给了？有人知道吗？

【问题讨论】：

标签： c# .net reflector

【解决方案1】：

在第一个示例中，这是完全可以预料的。这些类用于在使用yield return 语句时实现IEnumerable<T>。当MoveNext 由IEnumerable<T>.GetEnumerator 实现输出的IEnumerator<T> 实例输出调用MoveNext 时，它会生成存储状态并获取新值的类（您会注意到它们是同一个）。

应该注意的是，从 CLR 的角度来看，您看到的是完全合法的命名语法。但从 C# 的角度来看，这是不合法的。但是，由于这些类是内部的，您永远不需要直接访问它们（仅通过接口实现），因此它们不需要是合法的 C# 名称。

至于第二个，我没有看到这种行为，可能是程序集被混淆了，但我在任何版本的 .NET 中都没有看到这种情况。如果您澄清您正在查看的 .NET 框架版本中的程序集（是否为 .NET 框架），以及您正在使用的反射器版本，这将有所帮助。

【讨论】：

我相信我记得读到有一些不可打印的 ASCII 字符是合法的 CLR 标识符，可用于编译器生成的代码
casperOne：感谢您的澄清。代码在我看来甚至在内部看起来都不一致（例如，'GetEnumerator>d__0'），但我完全不符合 CLR 规则，因此很好地解释了它。正如您所料，我只是在反编译 .NET 2.0，以便解决一些更令人发指的错误。我厌倦了零碎的东东，所以使用 FileDisassembler 我只是拉出了整个 System.Web 程序集。它几乎可以编译——只有两三个像这样的类阻止它。第二个示例是一个品牌的商业 UI AJAX 控件（不是 Telerik，而是类似它们）。

【解决方案2】：

我之前在查看 Obfuscated 的程序集时已经看到了这一点。在此过程中，人眼经常无法读取变量名称，从而导致出现未知字符。

【讨论】：

【解决方案3】：

此程序集可能已被混淆，您可以查看这些链接 http://cooprotector.com/ http://intelliside.com/

【讨论】：

【解决方案4】：

编译器会自动生成很多东西。基于枚举器块的自动属性、匿名类型/方法和枚举器。他们都需要一个名称，并且该名称应该与开发人员的名称不冲突。由于 _ 在 CLR 术语中是一个完全合法的名称，但在 C# 中不是以任何自动生成和命名的前缀 _ 确保编译器不会意外选择开发人员已经使用的名称。

【讨论】：