2010-02-16 95 views
2

请注意,以下是dotNet反射器无法正确分解的罕见情况的示例。在绝大多数情况下,它可以很好地工作,而且我并不是说这必然是反射器中的一个缺陷。这可能是保护或混淆的结果,也可能是有关程序集上的非托管代码。DotNet反射器 - 为什么我不能反汇编XmlHierarchicalEnumerable?

我尝试在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) 

什么给了?有人知道吗?

回答

4

在第一个例子中,这是完全预期的。当使用yield return语句时,这些类用于执行IEnumerable<T>。当IEnumerable<T>.GetEnumerator实现输出的IEnumerator<T>实例上调用MoveNext时,它会生成存储状态并获取新值的类(您将会注意到它们是相同的)。

应该指出,你所看到的是从CLR的角度来看完全合法的命名语法。不过从C#的角度来看,这是不合法的。但是,由于这些类是内部的,您将永远不需要直接访问它们(仅通过接口实现),因此不需要它们是合法的C#名称。

至于第二个,我没有看到这种行为,它可能是混淆的程序集,但我没有在任何版本的.NET中看到过。如果您澄清了您正在查看的.NET框架版本(以及不包括.NET框架)的程序集以及您使用的反射器版本,它将有所帮助。

+0

我相信我记得有一些非可打印的ASCII字符是合法的CLR标识符,可用于编译器生成的代码 – jeffora 2010-02-16 06:47:20

+0

casperOne:感谢您的澄清。该代码甚至在内部看起来并不一致(例如'GetEnumerator> d__0'),但我完全没有使用CLR规则,因此很好地解释了它。如你所料,我只是反编译.NET 2.0,以便我可以解决一些更可怕的错误。我厌倦了它零碎的东西,所以使用FileDisassembler我只是拉动整个System.Web程序集。它几乎可以编译 - 只有两到三个这样的类阻止它。 第二个示例是一个商业用户界面AJAX控件(不是Telerik,但喜欢它们)的品牌。 – 2010-02-23 12:16:39

+0

Reflector ver 5.1.6.0 .Net Framework 2.0。50727.3603 – 2010-02-23 12:19:12

1

我以前看过这个组件时已经看过Obfuscated。在这个过程中很多时候,变量名称对于人眼来说是不可读的,从而导致一个未知的字符。

0

有由编译器被autogenetated不少东西。自动属性,基于枚举器块的匿名类型/方法和管理员。他们都需要一个名字,并且这个名字应该不会与开发者的名字冲突。由于<> _在CLR术语中是完全合法的名称,但在C#中并不包含任何自动生成并使用<> _命名的东西,以确保编译器不会意外地选择开发人员已使用的名称。

+0

谢谢,我将不得不查看CLR格式规则。 – 2010-02-23 12:21:46