#ifdef en C #

117

Je voudrais faire ce qui suit mais en C # au lieu de C ++

#ifdef _DEBUG
bool bypassCheck=TRUE_OR_FALSE;//i will decide depending on what i am debugging
#else
bool bypassCheck = false; //NEVER bypass it
#endif

la source
Vérifiez également cette excellente réponse , elle montre comment vous pouvez ajouter des symboles de débogage en fonction des conditions via le fichier projet (.csproj).
Matt

Réponses:

163
#if DEBUG
bool bypassCheck=TRUE_OR_FALSE;//i will decide depending on what i am debugging
#else
bool bypassCheck = false; //NEVER bypass it
#endif

Assurez-vous que la case à cocher pour définir DEBUG est cochée dans vos propriétés de construction.

lourd
la source
52

Je vous recommande d'utiliser l' attribut conditionnel !

Mise à jour: 3,5 ans plus tard

Vous pouvez utiliser #ifcomme ceci ( exemple copié à partir de MSDN ):

// preprocessor_if.cs
#define DEBUG
#define VC_V7
using System;
public class MyClass 
{
    static void Main() 
    {
#if (DEBUG && !VC_V7)
        Console.WriteLine("DEBUG is defined");
#elif (!DEBUG && VC_V7)
        Console.WriteLine("VC_V7 is defined");
#elif (DEBUG && VC_V7)
        Console.WriteLine("DEBUG and VC_V7 are defined");
#else
        Console.WriteLine("DEBUG and VC_V7 are not defined");
#endif
    }
}

Utile uniquement pour exclure des parties de méthodes.

Si vous utilisez #ifpour exclure une méthode de la compilation, vous devrez exclure de la compilation tous les morceaux de code qui appellent également cette méthode (parfois vous pouvez charger certaines classes au moment de l'exécution et vous ne pouvez pas trouver l'appelant avec "Rechercher toutes les références"). Sinon, il y aura des erreurs.

Si vous utilisez la compilation conditionnelle, vous pouvez toujours laisser tous les morceaux de code qui appellent la méthode. Tous les paramètres seront toujours validés par le compilateur. La méthode ne sera tout simplement pas appelée au moment de l'exécution . Je pense qu'il est préférable de masquer la méthode une seule fois et de ne pas avoir à supprimer tout le code qui l'appelle également. Vous n'êtes pas autorisé à utiliser l'attribut conditionnel sur les méthodes qui renvoient une valeur - uniquement sur les méthodes void. Mais je ne pense pas que ce soit une grande limitation car si vous utilisez #ifune méthode qui renvoie une valeur, vous devez masquer tous les morceaux de code qui l'appellent aussi.

Voici un exemple:

    // l'appel de Class1.ConditionalMethod () sera ignoré à l'exécution 
    // sauf si la constante DEBUG est définie


    en utilisant System.Diagnostics;
    classe Classe1 
    {
       [Conditionnel ("DEBUG")]
       public static void ConditionalMethod () {
          Console.WriteLine ("Executed Class1.ConditionalMethod");
       }
    }

Résumé:

J'utiliserais #ifdefen C ++ mais avec C # / VB j'utiliserais un attribut conditionnel. De cette façon, vous masquez la définition de la méthode sans avoir à masquer les morceaux de code qui l'appellent. Le code appelant est toujours compilé et validé par le compilateur, la méthode n'est cependant pas appelée au moment de l'exécution. Vous pouvez utiliser #ifpour éviter les dépendances, car avec l'attribut conditionnel, votre code est toujours compilé.

Pavel Nikolov
la source
1
+1 C'est bien en effet, mais a des limites, comme lorsque vous essayez de renvoyer une valeur à partir d'une méthode conditionnelle (si je comprends bien). Un exemple en ligne aiderait, je pense.
Hamish Grubijan
1
Cela n'empêche pas non plus le code d'être compilé, cela n'autorise tout simplement pas ce code. La distinction est importante lorsque vous souhaitez supprimer des dépendances et autres.
Lee Louviere
1

C # a un préprocesseur. Cela fonctionne légèrement différemment de celui de C ++ et C.

Voici un lien MSDN - la section sur toutes les directives de préprocesseur .

Karl T.
la source
11
C'est un point mineur, mais C # n'a PAS de préprocesseur. # directives sont traitées par le compilateur principal comme s'il y avait un préprocesseur. Voir ici: msdn.microsoft.com/en-us/library/ed8yd1ha.aspx Le principal résultat de cette distinction est que les macros de style c / c ++ ne fonctionnent pas.
Simon P Stevens