DotNet Reflector - 为什么我无法反汇编 XmlHierarchicalEnumerable？
请注意，以下是 dotNet Reflector 无法正确反汇编的极少数情况的示例。在绝大多数情况下，它都能完美工作，我并不认为这一定是反射器中的错误。这可能是由于相关程序集上的保护、混淆或非托管代码造成的。
我尝试在 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)
什么给出？有人知道吗？
Note that the following are examples of the rare cases where dotNet reflector does not disassemble correctly. In the vast majority of cases it works perfectly, and I am not suggesting this is necessarily a bug in reflector. It may be a result of protection or obfuscation or unmanaged code on the assemblies in question.
I try to disassemble System.Web.UI.WebControls.XmlHierarchicalEnumerable in dotnet reflector. The generics seems all screwed up, eg:
// 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;
In other assemblies I sometimes get little squares (I know these usually stand for 'unknown symbol') in place of class names, eg:
dictionary1.Add("autopostbackonselect", 0x34);
ᜀ.ᜌ = dictionary1;
}
if (ᜀ.ᜌ.TryGetValue(key, out num))
{
switch (num)
What gives ? Anyone know ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
编译器会自动生成很多东西。自动属性、匿名类型/方法和基于枚举器块的枚举器。他们都需要一个名称，并且该名称应该不会与开发人员的名称冲突。由于 <>_ 在 CLR 术语中是完全合法的名称，但在 C# 中则不然，所以为自动生成的任何内容添加前缀 <>_ 可确保编译器不会意外选择开发人员已使用的名称。
There's quite a few things being autogenetated by the compiler. Auto properties, anonymous types/methods and emumerators based on enumerator blocks. They All need a name and that should be one that does not clash with something names by the developer. Since <>_ is a perfectly legal name in CLR terms but not in C# prefixing anything autogenetated and named with <>_ ensures that the compiler wont accidentally choose a name already used by the developer.
在第一个示例中，这完全是预料之中的。这些类用于实现
IEnumerable使用收益回报< /a> 语句。它生成存储状态并在MoveNext在 < 上调用 的 code>IEnumeratorIEnumerable.GetEnumerator 实现（您会注意到它们是同一个）。需要注意的是，从 CLR 角度来看，您所看到的命名语法是完全合法的。但从 C# 的角度来看，这是不合法的。但是，由于这些类是内部类，您永远不需要直接访问它们（仅通过接口实现），因此它们不需要是合法的 C# 名称。
至于第二个，我还没有看到这种行为，可能是程序集被混淆了，但我在.NET的任何版本中都没有看到这种情况。如果您澄清您正在查看哪个版本的 .NET 框架中的程序集（是否为 .NET 框架）以及您正在使用哪个版本的反射器，这将会有所帮助。
In the first example, this is completely expected. These classes are used for the implementation of
IEnumerable<T>when using theyield returnstatements. It generates classes which store the state and get the new values whenMoveNextis called on theIEnumerator<T>instance output by theIEnumerable<T>.GetEnumeratorimplementation (you will note they are one in the same).It should be noted that what you are seeing is completely legal naming syntax from a CLR perspective. From a C# perspective though, it is not legal. However, since these classes are internal and you will never need access to them directly (only through interface implmentations), there is no need for them to be legal C# names.
As for the second, I haven't seen that behavior, it's possible that the assembly is obfuscated, but I've not seen that in .NET in any version. If you clarify the assemblies (.NET framework or not) in which version of the .NET framework you are looking at, as well as what version of reflector you are using, it would help.
我之前在查看已混淆的程序集时见过这一点。在此过程中，变量名称常常是人眼无法读取的，从而导致未知字符。
I have seen this before when looking at assemblies that have been Obfuscated. Quite often during this process variable names are unreadable to the human eye, thus resulting in a unknown character.
此程序集可能已被混淆，您可以检查这些链接 http://cooprotector.com/ http://intelliside.com/
This assembly might have been Obfuscated, you can check these links http://cooprotector.com/ http://intelliside.com/