.NET-Compiler – DEBUG vs.FREIGEBEN

Question

Seit Jahren verwende ich die Compilerkonstante DEBUG in VB.NET, um Nachrichten an die Konsole zu schreiben.Ich habe auch System.Diagnostics.Debug.Write auf ähnliche Weise verwendet.Ich war immer davon überzeugt, dass bei Verwendung von RELEASE als Build-Option alle diese Anweisungen vom Compiler weggelassen wurden, wodurch Ihr Produktionscode vom Overhead der Debug-Anweisungen befreit wurde.Als ich kürzlich mit Silverlight 2 Beta 2 arbeitete, fiel mir auf, dass Visual Studio tatsächlich an einen RELEASE-Build angehängt wurde, den ich von einer öffentlichen Website aus ausführte, und DEBUG-Anweisungen anzeigte, von denen ich annahm, dass sie noch nicht einmal kompiliert waren!Jetzt neige ich zunächst dazu, anzunehmen, dass mit meiner Umgebung etwas nicht stimmt, aber ich möchte auch jeden fragen, der sich mit System.Diagnostics.Debug und der Build-Option DEBUG im Allgemeinen auskennt, was ich hier möglicherweise falsch verstehe.

Answer 1

Die bevorzugte Methode besteht darin, das bedingte Attribut tatsächlich zum Umschließen Ihrer Debug-Aufrufe zu verwenden, und nicht die Compiler-Anweisungen.#ifs können knifflig werden und zu seltsamen Build-Problemen führen.

Ein Beispiel für die Verwendung eines bedingten Attributs ist wie folgt (in C#, funktioniert aber auch in VB.NET):

[ Conditional("Debug") ]
private void WriteDebug(string debugString)
{
  // do stuff
}

Wenn Sie ohne gesetztes DEBUG-Flag kompilieren, wird jeder Aufruf von WriteDebug entfernt, wie angenommen wurde, dass er mit Debug.Write() erfolgt.

Answer 2

Untersuchen die Debug.Write Methode.Es ist mit dem gekennzeichnet

[Conditional("DEBUG")]

Attribut.

Die MSDN-Hilfe für BedingtesAttribut Zustände:

Zeigt den Compilern an, dass ein Methodenaufruf oder ein Attribut ignoriert werden sollte, sofern keine angegeben bedingter Kompilierungssymbol ist definiert.

Es spielt keine Rolle, ob die Build-Konfiguration die Bezeichnung „Release“ oder „Debug“ trägt. Entscheidend ist, ob das DEBUG-Symbol darin definiert ist.

Answer 3

Ich kapsele den Aufruf von Debug in meiner eigenen Klasse und füge eine Precompiler-Direktive hinzu

public void Debug(string s)
{
#if DEBUG
    System.Diagnostics.Debug(...);
#endif
}

Answer 4

Durch die Verwendung des DEBUG-Compilersymbols wird, wie Sie sagten, der Code tatsächlich aus der Assembly weggelassen.

Ich glaube, dass System.Diagnostics.Debug.Write immer an einen angehängten Debugger ausgegeben wird, auch wenn Sie im Release-Modus erstellt haben.Pro MSDN-Artikel:

Schreibt Informationen zum Debug in die Trace-Listener in der Listeners-Auflistung.

Wenn du nicht willst beliebig Wenn Sie eine Ausgabe ausgeben möchten, müssen Sie Ihren Aufruf von Debug.Write mit der DEBUG-Konstante umschließen, wie Juan sagte:

#if DEBUG
    System.Diagnostics.Debug.Write(...);
#endif

Answer 5

Ich habe den Artikel auch gelesen und kam zu dem Schluss, dass, wenn DEBUG nicht definiert war, das für System.Debug-Funktionen deklarierte ConditionalAttribute dazu führen würde, dass der Compiler diesen Code vollständig weglässt.Ich gehe davon aus, dass das Gleiche auch für TRACE gilt.Das heißt, die System.Diagnostics.Debug-Funktionen müssen über ConditionalAttributes für DEBUG und TRACE verfügen.Mit dieser Annahme habe ich mich geirrt.Die separate Trace-Klasse verfügt über dieselben Funktionen und diese definieren ConditionalAttribute abhängig von der TRACE-Konstante.

Von System.Diagnostics.Debug:_ Public Shared Sub Write (_ Nachricht als String _)

Von System.Diagnostics.Trace:_ Public Shared Sub -Write -linie (_ Nachricht als String _)

Es scheint also, dass meine ursprüngliche Annahme richtig war, dass System.Diagnostics.Debug-Anweisungen (oder system.Diagnostics.Trace-Anweisungen) tatsächlich nicht in die Kompilierung einbezogen werden, als ob sie in #IF DEBUG-Regionen (oder #IF TRACE-Regionen) enthalten wären.

Aber ich habe hier auch von euch erfahren und bestätigt, dass der RELEASE-Build dies nicht selbst erledigt.Zumindest bei Silverlight-Projekten, die noch etwas instabil sind, müssen Sie in die „Erweiterten Kompilierungsoptionen…“ gehen und sicherstellen, dass DEBUG nicht definiert ist.

Wir sind von .NET 1.1/VS2003 auf .NET 3.5/VS2008 umgestiegen, daher denke ich, dass einiges davon früher anders funktionierte, aber vielleicht hat es sich in 2.0/VS2005 geändert.

Answer 6

Um auszuwählen, ob die Debug-Informationen kompiliert oder entfernt werden sollen,

Rufen Sie im Eigenschaftenfenster des Projekts die Registerkarte „Build“ auf.

Wählen Sie die richtige Konfiguration (Active/Release/Debugug/All) und stellen Sie sicher, dass Sie die "Debug -Konstante" überprüfen, wenn Sie die Informationen wünschen, oder deaktivieren Sie sie, wenn Sie dies nicht tun.

Änderungen übernehmen und neu erstellen

Answer 7

Meiner Erfahrung nach macht die Wahl zwischen Debug und Release in VB.NET keinen Unterschied.Sie können beiden Konfigurationen benutzerdefinierte Aktionen hinzufügen, aber standardmäßig sind sie meiner Meinung nach gleich.

Durch die Verwendung von Release werden die System.Diagnostics.Debug.Write-Anweisungen sicherlich nicht entfernt.