7 votes

<PrivateImplementationDetails>{GUID}.method$$**** dans le fichier de code. Ne compile pas !

Nous avons un assemblage .NET provenant d'un autre projet où l'un des fichiers générés par Reflector contient un extrait de méthode.

Maintenant, le compilateur VS 2010 c# jette toutes sortes d'erreurs de compilation $$ inattendu. accolades fermées etc.

Dans ILDASM, je vois cette méthode ainsi que de nombreuses autres mentionnées, mais dans le code généré, je ne trouve qu'une seule de ces méthodes générées par le compilateur.

Comment procéder à la compilation ?

5voto

leppie Points 67289

Ils sont normalement créés par static readonly réseaux. Vous ne les compilerez pas. De plus, Reflector est particulièrement bogué lorsqu'il s'agit de recréer du code autre que trivial.

Je vous suggère de vous procurer le code source original.

2voto

Mehrdad Points 70493

Ceux-ci sont générés automatiquement par le compilateur, je crois pour des choses comme les objets d'expression lambda (pour lesquels vous ne fournissez pas de nom). Je crois que ce sont des noms invalides précisément parce que le compilateur veut s'assurer qu'il n'y a pas de conflit avec votre propre code ; vous devrez simplement les renommer avant de recompiler.

1voto

Sonic Beard Points 1

Dans tous les cas que j'ai vus, cela a à voir avec les initialisateurs de tableaux. Si vous regardez les types créés, vous remarquerez que le compilateur vient de créer une structure différente pour chaque taille de tableau que vous avez initialisé. Le compilateur fait cela pour réduire la taille de l'IL, accélérer l'allocation de mémoire pour les éléments du tableau et garder les éléments du tableau stockés en mémoire ensemble et en ordre. Sans entrer dans les détails, je dirai simplement que cette méthode permet d'initialiser les tableaux de toutes tailles en un nombre connu et constant d'instructions IL. Je ne me souviens pas de mes recherches dans ILDasm mais je pense que c'était 4. Assigner un élément à la fois signifie 4 instructions par élément.

Venons-en maintenant à votre problème spécifique. Ce n'est pas si grave si l'on réalise que l'on a affaire à des instances de type valeur qui doivent être renommées. Une recherche dans le réflecteur devrait révéler les instances où les objets générés par le compilateur sont utilisés. La déclaration et l'initialisation originales seront intactes dans la source. C'est tout ce dont vous avez besoin pour renommer globalement cet objet. Choisissez le nom que vous voulez et remplacez le nom généré par le compilateur. J'ai mis un autre code ci-dessous qui illustre cela. Pour les dictionnaires qui ont besoin d'être initialisés également, il optimise et crée une nouvelle instance pour chaque dictionnaire appelé <>f_switch$mapn où n est à nouveau un compteur.

Vous devrez également faire face à des absurdités similaires pour toutes les propriétés pour lesquelles les champs de sauvegarde ont été générés automatiquement. Même solution cependant. Créez votre propre champ de sauvegarde et utilisez-le.


[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)
.
.
.

0voto

Nick Points 492

Dans le menu d'affichage, sélectionnez les options.

Vérifiez la sélection de l'optimisation. Comme vous utilisez la dernière version de VS, vous devez spécifier l'optimisation pour .Net 4.0 ou au moins 3.5 pour obtenir le support des lambdas.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X