Sollte ich Release-Builds mit Debug-Informationen als "voll" oder "nur pdb" kompilieren?

Wenn Sie in Visual Studio 2010 für ein C # -Projekt zu Projekteigenschaften> Erstellen> Erweitert> Debug-Informationen gehen, haben Sie drei Optionen: Keine, Vollständig oder Nur PDF. Aufgrund der Antwort auf diese Frage glaube ich, einige der Unterschiede zwischen Voll- und Nur-PDF-Dateien zu verstehen. Was ist jedoch für einen Release-Build besser geeignet? Wenn ich "voll" verwende, gibt es Leistungseinbußen? Wenn ich "nur pdb" verwende, ist es dann schwieriger, Produktionsprobleme zu beheben?

Was ist der Unterschied zwischen "voll" und "pdbonly"? https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/debug-compiler-option

Ich würde mit bauen pdb-only. Sie können dem freigegebenen Produkt keinen Debugger hinzufügen. Wenn Sie jedoch einen Absturzspeicherauszug erhalten, können Sie mit Visual Studio oder WinDBG die Stapelspuren und Speicherabbilder zum Zeitpunkt des Absturzes untersuchen.

Wenn Sie sich für fullanstatt entscheiden pdb-only, erhalten Sie dieselben Vorteile, außer dass die ausführbare Datei direkt an einen Debugger angehängt werden kann. Sie müssen feststellen, ob dies angesichts Ihres Produkts und Ihrer Kunden angemessen ist.

Stellen Sie sicher, dass Sie die PDB-Dateien irgendwo speichern, damit Sie sie beim Eingang eines Absturzberichts referenzieren können. Wenn Sie einen Symbolserver zum Speichern dieser Debugging-Symbole einrichten können, umso besser.

Wenn Sie sich für das Bauen entscheiden none, haben Sie bei einem Absturz auf dem Feld keinen Rückgriff. Sie können den Absturz nicht nachträglich untersuchen, was Ihre Fähigkeit, das Problem aufzuspüren, erheblich beeinträchtigen könnte.

Ein Hinweis zur Leistung:

Sowohl John Robbins als auch Eric Lippert haben Blog-Posts über die /debugFlagge geschrieben, und beide weisen darauf hin, dass diese Einstellung keine Auswirkungen auf die Leistung hat . Es gibt ein separates /optimizeFlag, das vorschreibt, ob der Compiler Optimierungen durchführen soll.

WARNUNG Die MSDN- Dokumentation für / debug switch (in Visual Studio ist Debug Info) scheint veraltet zu sein! Dies ist, was es hat, was falsch ist

Wenn Sie / debug: full verwenden , beachten Sie, dass sich dies auf die Geschwindigkeit und Größe des JIT-optimierten Codes sowie auf die Codequalität mit / debug: full auswirkt . Wir empfehlen / debuggen: pdbonly oder kein PDB zum Generieren von Release-Code.

Ein Unterschied zwischen / debug: pdbonly und / debug: full besteht darin, dass der Compiler mit / debug: full ein a ausgibt , mit DebuggableAttributedem dem JIT-Compiler mitgeteilt wird, dass Debug-Informationen verfügbar sind.

Was ist dann jetzt wahr?

1. Nur Pdb - Vor .NET 2.0 war es hilfreich, die Absturzabbilder von freigegebenen Produkten ( Kundencomputern) zu untersuchen. Der Debugger konnte jedoch nicht angehängt werden. Dies ist in .NET 2.0 nicht der Fall. Es ist genau das gleiche wie Full .
2. Vollständig - Dies hilft uns bei der Untersuchung von Absturzabbildern und ermöglicht es uns, den Debugger an den Release-Build anzuhängen. Im Gegensatz zu MSDN-Erwähnungen wirkt sich dies jedoch nicht auf die Leistung aus (seit .NET 2.0). Es funktioniert genauso wie Pdb-only .

Wenn sie genau gleich sind, warum haben wir diese Optionen? John Robbins (Windows Debugging God) fand heraus, dass diese aus historischen Gründen vorhanden sind.

Zurück in .NET 1.0 gab es Unterschiede, in .NET 2.0 jedoch nicht. Es sieht so aus, als würde .NET 4.0 dem gleichen Muster folgen. Nach einer Überprüfung mit dem CLR-Debugging-Team gibt es überhaupt keinen Unterschied.

Was steuert, ob der JITter einen Debug-Build ausführt, ist der Schalter / optimize. <…>

Unter dem Strich möchten Sie Ihre Release-Builds mit / optimize + und einem der Schalter / debug erstellen, damit Sie mit dem Quellcode debuggen können.

dann beweist er es weiter.

Jetzt ist die Optimierung Teil eines separaten Schalters /optimize(im Visual Studio heißt sie Optimize code).

Kurz gesagt, unabhängig davon, ob DebugInfo pdb-only oder full einstellt, werden wir die gleichen Ergebnisse erzielen. Es wird empfohlen, None zu vermeiden, da Sie dadurch nicht in der Lage sind, die Crash-Dumps des freigegebenen Produkts zu analysieren oder den Debugger anzuhängen.

Sie möchten nur PDB, aber Sie möchten die PDB-Dateien nicht an Benutzer weitergeben. Wenn Sie sie jedoch neben Ihren Binärdateien für sich haben, können Sie Crash-Dumps in einen Debugger wie WinDbg laden und sehen, wo Ihr Programm tatsächlich fehlgeschlagen ist. Dies kann sehr nützlich sein, wenn Ihr Code auf einem Computer abstürzt, auf den Sie keinen Zugriff haben.

Beim vollständigen Debuggen wird Ihrem Code das Attribut [Debuggable] hinzugefügt. Dies hat einen großen Einfluss auf die Geschwindigkeit. Beispielsweise können einige Schleifenoptimierungen deaktiviert werden, um das Einzelschreiten zu vereinfachen. Darüber hinaus hat dies einen geringen Einfluss auf den JIT-Prozess, da das Tracking aktiviert wird.

Ich bin gerade dabei, einen nicht behandelten Ausnahmebehandler zu schreiben, und der Stack-Trace enthält die Zeilennummer, wenn nur pdb verwendet wird. Andernfalls erhalte ich nur den Namen des Sub / der Funktion, wenn ich Keine auswähle.

Wenn ich die .pdb nicht verteile, erhalte ich die Zeilennummer im Stack-Trace auch mit dem Build nur für pdb nicht.

Also verteile ich die PDF-Datei zusammen mit der Exe aus meiner VB-App (XCOPY-Bereitstellung in einem LAN).