Debuggen einer Anwendung in einer Kundenumgebung .NET

Question

Wir haben eine in C# .NET geschriebene Anwendung, die derzeit in Produktionsumgebungen verwendet wird. Offensichtlich wird der Release-Build verwendet.

Leider funktioniert die Anwendung manchmal unter bestimmten Bedingungen falsch und wir können nicht herausfinden, warum. Wir können das Problem nicht intern reproduzieren. Ja, mehr Nachverfolgung würde helfen, aber oft ist es nach der Tatsache, dass Sie erkennen, dass mehr Nachverfolgung hätte eingerichtet werden sollen.

Was ist der beste Weg zum Debuggen dieser Installation mit der regulären, Zeile für Zeile, Visual Studio Attach-to-Process-Debuggen. Würde es sein, die Express Edition von VS auf dem Kundenrechner zu installieren und die DLLs durch die Debug-Versionen zu ersetzen? Reicht es aus, nur die PDBs und die spezifischen Quelldateien zu senden? Gibt es einen besseren Weg? Das Endziel ist eine entwicklungsähnliche Umgebung, um das Problem zu beheben.

Answer 1

Remote-Debugging ist ein gutes Feature, aber es kann selten in Produktionsumgebungen verwendet werden, da es eine 2-Wege-Vertrauensstellung zwischen Domänen (eigene und Ihre Kunden) erfordert, die schwer zu erreichen ist idea)

siehe Remote Debugging Across Domains

jedoch PDB-Dateien mit Ihrer Anwendung senden, wird helfen. Sie können Ihre Kunden bitten, Clr Debugger (DbgCLR.exe) zu verwenden. Es hat einige Einschränkungen im Vergleich mit VS Debugger, aber es ist immer noch ein Debugger, der die Arbeit erledigen kann, und es ist ein Teil von .NET SDK. Wenn das Problem mit Clr Debugger nicht behoben werden kann, können Kunden versuchen, eine Testversion von VS in ihrer Produktionsumgebung zu installieren und Ihnen eine Remotedesktopverbindung zu geben (wenn Administratoren dies zulassen). Ich nehme an, dass 90-Tage-Probezeit genug sein wird, um das Problem zu lösen

Sie können auch versuchen, eine Testumgebung wie Ihre Kunden zu bauen - begrenzen (oder erhöhen) die Anzahl der CPUs, Speicher usw. physikalischen Bedingungen entsprechen soweit wie möglich. Bitten Sie Ihren Kunden, ein virtuelles Abbild ihres Windows zu erstellen, wenn Sie der Meinung sind, dass zusätzliche Drittanbietersoftware oder nicht vorhandene Registrierungsdatensätze Ihr Programm beeinflussen können.

Meine Erfahrung ist jedoch, dass in 50% solche "nicht reproduzierbaren" Fehler in .NET wegen des gleichzeitigen Zugriffs durch mehrere Benutzer (Deadlocks, Race Conditions, logisches Fehlverhalten in First Wins/Last Wins-Szenarien) passiert. In den meisten Fällen handelt es sich um Fehler, die Sie nicht debuggen können, selbst wenn Sie VS auf dem Kundencomputer installieren (wenn Sie dies zu Zeiten ohne Hauptdienstzeit ausführen), da Sie mindestens zwei Kunden gleichzeitig auf verschiedenen Computern ausführen müssen.

So, während Sie nach Optionen zum Debugging für Kunden suchen, arbeiten Sie weiter an der Verbesserung der Ablaufverfolgung und Überwachungsfunktionen. Ablaufverfolgung und Leistungsindikatoren sind oft Ihre einzigen Freunde in Produktionsumgebungen.

Answer 2

Zuerst stellen Sie sicher, dass Sie PDBs mit der App bereitgestellt haben (Release-PDBs sind ausreichend). Wenn Sie dann den Visual Studio-Remotedebugger auf dem Produktionsrechner installieren und ausführen, können Sie ihn von Ihrem lokalen Computer aus debuggen. Die PDB-Dateien der App auf dem bereitgestellten Computer sollten mit Ihrer lokalen Version übereinstimmen, da der Remote-Debugger meiner Meinung nach keine Synchronisierung durchführt.

Answer 3

Verwenden Sie Statusmeldungen und Protokolldateien, um die Codezeile zu identifizieren, die den Fehler verursacht hat.

Answer 4

Ich empfehle Ihnen die Verwendung von Ausnahmebehandlung Anwendungsblöcke von Enterprise-Bibliothek Mit diesem können Sie Ihre Fehlermeldungen auf Ihre E-Mail/Datenbank/Text-Dateien etc..etc protokollieren. So können Sie die Ursache für den Fehler genau herausfinden.

http://www.codeproject.com/KB/aspnet/ExceptionHandling.aspx