#if DEBUG vs. Conditional("DEBUG")

Question

Was ist bei einem großen Projekt besser zu verwenden und warum?

#if DEBUG
    public void SetPrivateValue(int value)
    { ... }
#endif

o

[System.Diagnostics.Conditional("DEBUG")]
public void SetPrivateValue(int value)
{ ... }

Answer 1

Es kommt wirklich darauf an, was Sie erreichen wollen:

• #if DEBUG : Der hier enthaltene Code wird bei der Veröffentlichung nicht einmal die IL erreichen.
• [Conditional("DEBUG")] : Dieser Code wird die IL erreichen, aber ruft auf. an die Methode wird ausgelassen, es sei denn, DEBUG ist beim Kompilieren des Aufrufers gesetzt.

Ich persönlich benutze beides, je nach Situation:

Conditional("DEBUG") Beispiel: Ich verwende dies, damit ich nicht zurückgehen und meinen Code später während der Veröffentlichung bearbeiten muss, aber während der Fehlersuche möchte ich sicher sein, dass ich keine Tippfehler gemacht habe. Diese Funktion prüft, ob ich einen Eigenschaftsnamen richtig eingebe, wenn ich versuche, ihn in meinem INotifyPropertyChanged-Zeug zu verwenden.

[Conditional("DEBUG")]
[DebuggerStepThrough]
protected void VerifyPropertyName(String propertyName)
{
    if (TypeDescriptor.GetProperties(this)[propertyName] == null)
        Debug.Fail(String.Format("Invalid property name. Type: {0}, Name: {1}",
            GetType(), propertyName));
}

Sie sollten wirklich keine Funktion erstellen, die #if DEBUG es sei denn, Sie sind bereit, jeden Aufruf dieser Funktion mit demselben #if DEBUG :

#if DEBUG
    public void DoSomething() { }
#endif

    public void Foo()
    {
#if DEBUG
        DoSomething(); //This works, but looks FUGLY
#endif
    }

gegen:

[Conditional("DEBUG")]
public void DoSomething() { }

public void Foo()
{
    DoSomething(); //Code compiles and is cleaner, DoSomething always
                   //exists, however this is only called during DEBUG.
}

---

#if DEBUG Beispiel: Ich verwende dies, wenn ich versuche, verschiedene Bindungen für die WCF-Kommunikation einzurichten.

#if DEBUG
        public const String ENDPOINT = "Localhost";
#else
        public const String ENDPOINT = "BasicHttpBinding";
#endif

Im ersten Beispiel ist der Code zwar vorhanden, wird aber nur dann ignoriert, wenn DEBUG eingeschaltet ist. Im zweiten Beispiel wird die Konstante ENDPOINT auf "Localhost" oder "BasicHttpBinding" gesetzt, je nachdem, ob DEBUG eingestellt ist oder nicht.

---

Aktualisierung: Ich aktualisiere diese Antwort, um einen wichtigen und heiklen Punkt zu klären. Wenn Sie sich für die Verwendung der ConditionalAttribute nicht vergessen, dass die Aufrufe während der Kompilierung ausgelassen werden, und nicht zur Laufzeit . Das heißt:

MyLibrary.dll

[Conditional("DEBUG")]
public void A()
{
    Console.WriteLine("A");
    B();
}

[Conditional("DEBUG")]
public void B()
{
    Console.WriteLine("B");
}

Wenn die Bibliothek im Freigabemodus kompiliert wird (d.h. ohne DEBUG-Symbol), wird sie immer den Aufruf von B() von innen A() ausgelassen, auch wenn ein Aufruf von A() ist enthalten, weil DEBUG in der aufrufenden Assembly definiert ist.

Answer 2

Nun, es ist erwähnenswert, dass sie keineswegs dasselbe bedeuten.

Wenn das DEBUG-Symbol nicht definiert ist, dann wird im ersten Fall das SetPrivateValue selbst nicht aufgerufen wird... während es im zweiten Fall zwar existiert, aber jede Anrufer die ohne das DEBUG-Symbol kompiliert werden, werden diese Aufrufe weggelassen.

Wenn der Code und alle seine Aufrufer in der gleichen Assembly sind, ist dieser Unterschied menos wichtig - aber es bedeutet, dass Sie im ersten Fall également haben müssen #if DEBUG um den aufrufen auch den Code.

Ich persönlich würde den zweiten Ansatz empfehlen - aber Sie müssen sich den Unterschied zwischen beiden klar vor Augen halten.

Answer 3

Ich bin mir sicher, dass viele anderer Meinung sind, aber da ich als Entwickler ständig höre: "Aber das funktioniert doch auf meinem Rechner!", vertrete ich den Standpunkt, dass man beides so gut wie nie verwenden sollte. Wenn Sie wirklich etwas zum Testen und Debuggen brauchen, finden Sie einen Weg, diese Testbarkeit vom eigentlichen Produktionscode zu trennen.

Abstrahieren Sie die Szenarien mit Mocking in Unit-Tests, erstellen Sie einmalige Versionen von Dingen für einmalige Szenarien, die Sie testen wollen, aber fügen Sie keine Debug-Tests in den Code für Binärdateien ein, die Sie testen und für die Produktionsfreigabe schreiben. Diese Debug-Tests verbergen mögliche Fehler nur vor den Entwicklern, so dass sie erst später im Prozess gefunden werden.

Answer 4

Auch dieser kann nützlich sein:

if (Debugger.IsAttached)
{
...
}

Answer 5

Zum ersten Beispiel, SetPrivateValue nicht im Build vorhanden sein, wenn DEBUG nicht definiert ist, mit dem zweiten Beispiel, ruft auf. a SetPrivateValue im Build nicht vorhanden ist, wenn DEBUG ist nicht definiert.

Im ersten Beispiel müssen Sie alle Aufrufe an SetPrivateValue con #if DEBUG auch.

Im zweiten Beispiel sind die Aufrufe an SetPrivateValue wird weggelassen, aber beachten Sie, dass SetPrivateValue selbst wird weiterhin kompiliert. Dies ist nützlich, wenn Sie eine Bibliothek erstellen, so dass eine Anwendung, die auf Ihre Bibliothek verweist, Ihre Funktion weiterhin verwenden kann (wenn die Bedingung erfüllt ist).

Wenn Sie die Aufrufe weglassen und den Platz des Aufrufenden sparen wollen, können Sie eine Kombination der beiden Techniken verwenden:

[System.Diagnostics.Conditional("DEBUG")]
public void SetPrivateValue(int value){
    #if DEBUG
    // method body here
    #endif
}