C# if/then-Anweisungen für Debug vs. Release

Question

In den Lösungseigenschaften habe ich die Konfiguration für mein einziges Projekt auf "Release" gesetzt.

Am Anfang der Hauptroutine habe ich diesen Code, und es wird "Mode=Debug" angezeigt. Außerdem habe ich diese beiden Zeilen ganz oben:

#define DEBUG 
#define RELEASE

Teste ich die richtige Variable?

#if (DEBUG)
            Console.WriteLine("Mode=Debug"); 
#elif (RELEASE)
            Console.WriteLine("Mode=Release"); 
#endif

Mein Ziel ist es, unterschiedliche Standardwerte für Variablen auf der Grundlage von Debug vs Release-Modus zu setzen.

Answer 1

An dieser Stelle sei darauf hingewiesen, dass einer der wichtigsten Unterschiede zwischen der bedingten Ausführung von Code auf der Grundlage von #if DEBUG gegen if(System.Diagnostics.Debugger.IsAttached) ist, dass die Compiler-Richtlinie ändert den Code, der kompiliert wird . Das heißt, wenn Sie zwei verschiedene Anweisungen in einer #if DEBUG/#else/#endif bedingter Block, nur eine von ihnen werden im kompilierten Code erscheinen. Dies ist eine wichtige Unterscheidung, denn sie ermöglicht es Ihnen, Dinge zu tun, wie z.B. Methodendefinitionen bedingt zu kompilieren, damit sie public void mymethod() gegen internal void mymethod() abhängig vom Build-Typ, so dass Sie zum Beispiel Unit-Tests in Debug-Builds ausführen können, die die Zugriffskontrolle in Produktions-Builds nicht verletzen, oder Hilfsfunktionen in Debug-Builds bedingt kompilieren können, die im endgültigen Code nicht erscheinen, wenn sie die Sicherheit in irgendeiner Weise verletzen würden, falls sie in die freie Wildbahn gelangen. Die IsAttached hat dagegen keine Auswirkungen auf den kompilierten Code. Beide Codesätze sind in allen Builds enthalten - die IsAttached Bedingung wirkt sich nur auf das aus, was ausgeführt . Dies kann an sich schon ein Sicherheitsproblem darstellen.

Answer 2

Ein Tipp, der Ihnen viel Zeit ersparen kann: Vergessen Sie nicht, dass Sie, auch wenn Sie sich für debug unter der Build-Konfiguration (bei vs2012/13 im Menü unter BUILD => CONFIGURATION MANAGER) - das reicht nicht.

Achten Sie auf das Feld PUBLISH Configuration als solche:

Answer 3

Ich habe über einen besseren Weg nachgedacht. Es dämmerte mir, dass #if-Blöcke in anderen Konfigurationen effektiv Kommentare sind (unter der Annahme, dass DEBUG o RELEASE (gilt aber für jedes Symbol)

public class Mytest
    {
        public DateTime DateAndTimeOfTransaction;
    }

    public void ProcessCommand(Mytest Command)
        {
            CheckMyCommandPreconditions(Command);
            // do more stuff with Command...
        }

        [Conditional("DEBUG")]
        private static void CheckMyCommandPreconditions(Mytest Command)
        {
            if (Command.DateAndTimeOfTransaction > DateTime.Now)
                throw new InvalidOperationException("DateTime expected to be in the past");
        }

Answer 4

Entfernen Sie die Definitionen und prüfen Sie, ob die Bedingung im Debug-Modus ist. Sie brauchen nicht zu prüfen, ob sich die Richtlinie im Freigabemodus befindet.

Etwa so:

#if DEBUG
     Console.WriteLine("Mode=Debug"); 
#else
    Console.WriteLine("Mode=Release"); 
#endif

Answer 5

Da der Zweck dieser COMPILER-Direktiven darin besteht, dem Compiler mitzuteilen, dass er Code, Debug-Code, Beta-Code oder vielleicht Code, der von allen Ihren Endbenutzern benötigt wird, NICHT einschließen soll, mit Ausnahme von denen der Werbeabteilung, d.h. #Define AdDept, möchten Sie in der Lage sein, diese je nach Ihren Bedürfnissen einzuschließen oder zu entfernen. Ohne dass Sie Ihren Quellcode ändern müssen, wenn zum Beispiel ein Nicht-AdDept in das AdDept übergeht, müssen Sie nur die #AdDept-Direktive in die Compiler-Optionen einer bestehenden Version des Programms aufnehmen, kompilieren und siehe da, der Code des übergegangenen Programms erwacht zum Leben.

Sie können auch ein Deklarativum für einen neuen Prozess verwenden, der noch nicht reif ist oder der im Code nicht aktiv sein kann, bis es Zeit ist, ihn freizugeben.

Jedenfalls mache ich das so.