当前位置：文江博客话题详情

代码文件中的{GUID}.method$$****。无法编译！

发布于 2024-10-07 20:25:10 字数 193 浏览 1 评论 0原文

我们有一个来自另一个项目的 .NET 程序集，其中 Reflector 生成的文件之一具有 .. 方法片段。

现在 VS 2010 c# 编译器会抛出各种编译错误 $$ 意外。在 ILDASM 中，我看到了这个方法以及

提到的许多其他方法，但在生成的代码中，我发现只有这些编译器生成的方法中的 1 个进来。

如何进行编译？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

薄荷港 2024-10-14 20:25:10

这些通常由静态只读数组创建。你不会编译它们。此外，Reflector 在重新创建除琐碎代码之外的任何内容时都存在明显的错误。

我建议你获取原始源代码。

回复收藏 0 原文

物价感观 2024-10-14 20:25:10

我相信这些是由编译器自动生成的，例如 lambda 表达式对象（您不提供任何名称）。我相信它们是无效的名称，因为编译器希望确保与您自己的代码不存在任何冲突；您只需要在重新编译之前重命名它们即可。

回复收藏 0 原文

不交电费瞎发啥光 2024-10-14 20:25:10

在我所见过的所有情况下，这都与数组初始值设定项有关。如果您查看创建的类型，您会注意到编译器刚刚为您初始化的每个大小的数组创建了一个不同的结构。编译器这样做是为了减少 IL 大小、加快数组元素的内存分配速度并保持数组元素按顺序存储在内存中。在不深入讨论的情况下，我只是提到，这样做意味着任何大小的数组初始化都发生在已知且恒定数量的 IL 指令中。我不记得我在 ILDasm 中的挖掘情况，但我认为它是 4。一次分配一个意味着每个元素 4 条指令。

现在谈谈你的具体问题。一旦您意识到您只是在处理需要重命名的值类型实例，这并没有那么糟糕。在反射器中进行一些搜索应该会揭示使用编译器生成的对象的实例。原始声明和初始化在源代码中将保持不变。这就是您需要遵循的全部内容，即对该对象进行全局重命名。选择您想要的任何名称并替换编译器生成的名称。我在下面放置了一些其他代码来说明这一点。对于需要初始化的字典，它会优化并为每个字典创建一个名为 <>f_switch$mapn 的新实例，其中 n 又是一个计数器。

对于自动生成的支持字段的任何属性，您还将处理类似的废话。不过同样的修复。创建您自己的支持字段并使用它。

[CompilerGenerated]
internal class <PrivateImplementationDetails>
{
    // Fields
    internal static $ArrayType$4 $field-0; // data size: 4 bytes
    internal static $ArrayType$4 $field-1; // data size: 4 bytes
    internal static $ArrayType$4 $field-2; // data size: 4 bytes
    internal static $ArrayType$4 $field-3; // data size: 4 bytes
    internal static $ArrayType$44 $field-4; // data size: 44 bytes
    internal static $ArrayType$4 $field-5; // data size: 4 bytes

    // Nested Types
    [StructLayout(LayoutKind.Explicit, Size=4, Pack=1)]
    private struct $ArrayType$4
    {
    }

    [StructLayout(LayoutKind.Explicit, Size=0x2c, Pack=1)]
    private struct $ArrayType$44
    {
    }
}

static GATWavHelper()
{
    riffBytes = new byte[] { 0x52, 0x49, 70, 70 };
    waveBytes = new byte[] { 0x57, 0x41, 0x56, 0x45 };
    fmtBytes = new byte[] { 0x66, 0x6d, 0x74, 0x20 };
    dataBytes = new byte[] { 100, 0x61, 0x74, 0x61 };
    headerSize = 0x2c;
    floatToInt16RescaleFactor = 0x7fff;
    __canonicalHeader = new byte[] { 
        0x52, 0x49, 70, 70, 0, 0, 0, 0, 0x57, 0x41, 0x56, 0x45, 0x66, 0x6d, 0x74, 0x20, 
        0, 0, 0, 0x10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
        0, 0, 0, 0, 100, 0x61, 0x74, 0x61, 0, 0, 0, 0
     };
}

// Fields
[CompilerGenerated]
private static Dictionary<string, int> <>f__switch$map0;
.
.
.
if (<>f__switch$map0 == null)
{
    Dictionary<string, int> dictionary = new Dictionary<string, int>(3);
    dictionary.Add("false", 0);
    dictionary.Add("true", 1);
    dictionary.Add("null", 2);
    <>f__switch$map0 = dictionary;
}

if (<>f__switch$map0.TryGetValue(nextWord, out num))
{
    switch (num)
.
.
.

In all the cases I have seen this it has to do with Array initializers. If you look at the types created in you'll notice that the compiler has just created a different struct for each size array you have initialized. The compiler does this to reduce IL size, speed memory allocation for the array elements and to keep the array elements stored in memory together and in order. Without getting to deep in the weeds I'll just mention that doing it this way means any size array initialization happens in a known and constant number of IL instructions. I can't remember from my digging in ILDasm but I think it was 4. Assigning one at a time means 4 instructions per element.

Now to your specific problem. It's not that bad once you realize you're just dealing with value type instances that need to be renamed. Some searching in reflector should reveal the instances where the compiler generated objects are used. The original declaration and initialization will be intact in source. That's all you need to follow though with a global rename for that object. Pick any name you want and replace the compiler's generated name. I put some other code below that illustrates this. For Dictionaries that need initialization as well it optimizes and creates a new instance for each Dictionary called <>f_switch$mapn where n is a counter again.

You'll also deal with similar nonsense for any properties the backing fields were autogenerated for. Same fix though. Create your own backing field and use it.

[CompilerGenerated]
internal class <PrivateImplementationDetails>
{
    // Fields
    internal static $ArrayType$4 $field-0; // data size: 4 bytes
    internal static $ArrayType$4 $field-1; // data size: 4 bytes
    internal static $ArrayType$4 $field-2; // data size: 4 bytes
    internal static $ArrayType$4 $field-3; // data size: 4 bytes
    internal static $ArrayType$44 $field-4; // data size: 44 bytes
    internal static $ArrayType$4 $field-5; // data size: 4 bytes

    // Nested Types
    [StructLayout(LayoutKind.Explicit, Size=4, Pack=1)]
    private struct $ArrayType$4
    {
    }

    [StructLayout(LayoutKind.Explicit, Size=0x2c, Pack=1)]
    private struct $ArrayType$44
    {
    }
}

static GATWavHelper()
{
    riffBytes = new byte[] { 0x52, 0x49, 70, 70 };
    waveBytes = new byte[] { 0x57, 0x41, 0x56, 0x45 };
    fmtBytes = new byte[] { 0x66, 0x6d, 0x74, 0x20 };
    dataBytes = new byte[] { 100, 0x61, 0x74, 0x61 };
    headerSize = 0x2c;
    floatToInt16RescaleFactor = 0x7fff;
    __canonicalHeader = new byte[] { 
        0x52, 0x49, 70, 70, 0, 0, 0, 0, 0x57, 0x41, 0x56, 0x45, 0x66, 0x6d, 0x74, 0x20, 
        0, 0, 0, 0x10, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 
        0, 0, 0, 0, 100, 0x61, 0x74, 0x61, 0, 0, 0, 0
     };
}

// Fields
[CompilerGenerated]
private static Dictionary<string, int> <>f__switch$map0;
.
.
.
if (<>f__switch$map0 == null)
{
    Dictionary<string, int> dictionary = new Dictionary<string, int>(3);
    dictionary.Add("false", 0);
    dictionary.Add("true", 1);
    dictionary.Add("null", 2);
    <>f__switch$map0 = dictionary;
}

if (<>f__switch$map0.TryGetValue(nextWord, out num))
{
    switch (num)
.
.
.

回复收藏 0 原文