2017-08-15 4 views
0

J'essaie d'utiliser des directives de préprocesseur simples pour le mode de débogage et de libération en C#.Directives de préprocesseur C# dans le code IL

Par exemple:

using System; 
public class C { 
    public void M() { 
     #if DEBUG 
      Console.WriteLine("Debug"); 
     #else 
      Console.WriteLine("Release"); 
     #endif 
    } 
} 

Ce code très simple et clair.

Mais quand je vois dans le code IL je n'ai rien à propos de la directive de débogage.

.class private auto ansi '<Module>' 
{ 
} // end of class <Module> 

.class public auto ansi beforefieldinit C 
    extends [mscorlib]System.Object 
{ 
    // Methods 
    .method public hidebysig 
     instance void M() cil managed 
    { 
     // Method begins at RVA 0x2050 
     // Code size 13 (0xd) 
     .maxstack 8 

     IL_0000: nop 
     IL_0001: ldstr "Release" 
     IL_0006: call void [mscorlib]System.Console::WriteLine(string) 
     IL_000b: nop 
     IL_000c: ret 
    } // end of method C::M 

    .method public hidebysig specialname rtspecialname 
     instance void .ctor() cil managed 
    { 
     // Method begins at RVA 0x205e 
     // Code size 8 (0x8) 
     .maxstack 8 

     IL_0000: ldarg.0 
     IL_0001: call instance void [mscorlib]System.Object::.ctor() 
     IL_0006: nop 
     IL_0007: ret 
    } // end of method C::.ctor 

} // end of class C 

C'est très intéressant pour moi, pourquoi cela arrive.

Je veux dire pourquoi je ne vois rien sur le mode DEBUG dans le code IL?

P.S. J'utilise sharplab pour voir le code IL.

P.S.2 en direct example

+0

Est-ce que vous regardez l'IL pour la configuration de débogage? – GalacticCowboy

+0

@GalacticCowboy non, je regarde dans la configuration DEBUG –

+0

Ce que vous avez montré est le Release IL. Le débogage IL ne sera pas le même. – GalacticCowboy

Répondre

6

Il est parce que les directives de préprocesseur sont utilisées par le compilateur pour générer un code différent de IL selon la configuration. Il n'est pas utilisé par le CLR. Quant à savoir pourquoi SharpLab ne fait pas ce qu'il faut, il utilise Rosyln et ne définit que les paramètres d'optimisation. Il ne définit pas la variable du préprocesseur. Je suggère que vous ouvriez un problème avec SharpLab qu'ils implémentent ceci pour fonctionner comme prévu.

+0

oui, mais je cherche dans la configuration DEBUG et le code attendu IL pour le mode de débogage. –

+1

@TarasKovalenko pouvez-vous vérifier avec vos drapeaux msbuild/csc pour vous assurer que 'DEBUG' est bien défini. –

+0

J'ai mis à jour ma question avec l'exemple en direct –

2

Il y a deux concepts qui semblent vous dérouter.

  1. Release/Debug mode de compilation:

    contrôle si le compilateur émet les informations de débogage dans le code (par exemple NOP instructions pour la mise en points d'arrêt) et d'autres aspects tels que les optimisations effectuées sur les deux compilateur et JIT niveau. Ceci est basé sur le paramètre /debug au compilateur C#.

  2. symboles préprocesseur:

    Ce contrôle ce que les symboles sont définis pour le cycle de compilation. Par défaut, ils sont définis sur DEBUG et TRACE en mode débogage et TRACE en mode de publication lors de l'utilisation de Visual Studio pour créer le projet C#. Ces symboles sont ensuite utilisés pour résoudre les directives #if que vous utilisez. Ceci est basé sur le paramètre /define à compilateur C#

Ce qui semble se produire dans votre cas est que votre outil indique au compilateur C# pour exécuter dans Debug/le mode de sortie, mais ne fournit pas le symbole de préprocesseur attendu (DEBUG) dans les paramètres. Par conséquent, vous voyez le code non DEBUG dans les configurations Release et Debug.

Voir aussi: Microsoft docs: C# compiler options by category