Debuggen von Office-Projekten

Sie können Office-Projekte mithilfe der gleichen Microsoft Visual Studio-Tools debuggen, die Sie für andere Visual Studio-Projekte verwenden. Visual Studio-Debuggerfeatures, z. B. die Möglichkeit, Haltepunkte und Ansichtsvariablen in das Fenster "Lokal" einzufügen, stehen auch beim Debuggen von Office-Projekten zur Verfügung. Weitere Informationen zu Visual Studio-Debuggingtools finden Sie unter Debuggen in Visual Studio.

Gilt für: Die Informationen in diesem Thema gelten für Projekte auf Dokumentebene und VSTO-Add-In-Projekte. Siehe Verfügbare Features nach Office-Anwendung und Projekttyp.

Starten und Beenden des Debuggers

Sie können mit dem Debuggen eines Office-Projekts beginnen, wie sie mit dem Debuggen anderer Visual Studio-Projekte beginnen. Sie können z. B. F5 drücken. Wenn Sie mit dem Debuggen eines VSTO-Add-In-Projekts beginnen, wird ein neuer Prozess für die zielorientierte Office-Anwendung gestartet, und das VSTO-Add-In wird geladen.

Wenn Sie mit dem Debuggen eines Projekts auf Dokumentebene beginnen, wird das Dokument oder die Arbeitsmappe in einem neuen Word- oder Excel-Prozess geöffnet.

Wenn Sie den Debugger beenden, wird der Anwendungsprozess abrupt beendet, oder der Debugger trennt sich, wenn er zum Trennen eingestellt ist. Alle anderen Dokumente, die im beendeten Office-Anwendungsprozess geöffnet werden, werden auch ohne Warnung geschlossen, und nicht gespeicherte Änderungen gehen verloren. Dies kann alle Dokumente oder Arbeitsmappen umfassen, die geöffnet werden, während der Debugger ausgeführt wird.

In der Regel ist es besser, sich vom Prozess zu trennen, bevor Sie den Debugger beenden, damit Sie die Office-Anwendung auf die übliche Weise beenden können. Sie können sich auch zuerst vom Prozess lösen, wenn Sie noch nach dem Beenden des Debuggers mit einem geöffneten Dokument oder Arbeitsblatt arbeiten möchten.

Wenn Sie eine Anpassung auf Dokumentebene für Word debuggen, kann das Beenden des Debuggers und das plötzliche Schließen von Word dazu führen, dass die Vorlage "Normal" beschädigt wird. In diesem Fall können Sie die beschädigte Vorlage "Normal" löschen, und sie wird beim nächsten Öffnen von Word automatisch neu erstellt. Alle Makros, die in der Vorlage "Normal" gespeichert wurden, werden jedoch nicht neu erstellt.

Debuggen von Office 2013 VSTO-Add-Ins mithilfe von Office 2013 oder Office 2016

Wenn Sie Visual Studio 2015 verwenden und beide Versionen von Office nebeneinander installiert sind, startet Visual Studio Office 2016. Wenn Sie Visual Studio 2013 verwenden, startet Visual Studio Office 2013.

Wenn Sie Ihr VSTO-Add-In mithilfe einer anderen Version von Office (2013 oder 2016) debuggen möchten, öffnen Sie den Project Designer, und wählen Sie auf der Registerkarte " Debuggen " die Optionsschaltfläche " Externes Programm starten " aus. Navigieren Sie dann zum Speicherort der entsprechenden ausführbaren Office-Programmdatei.

F10- und F11-Verhalten

Wenn Sie mit dem Debuggen eines Office-Projekts beginnen, haben F10 und F11 nicht das gleiche Verhalten wie beim Debuggen anderer Visual Basic- oder C#-Projekte. In Visual Basic- oder C#-Projekten stoppt der Debugger auf der Hauptfunktion. in Office-Projekten hat Visual Studio keine Kontrolle über die Hauptfunktion der Office-Anwendung. Während des Debuggens verfügen F10 und F11 jedoch über die gleichen Funktionen wie in Visual Basic- und C#-Projekten.

Anzeigen von Ausnahmen

Aufgrund der Art und Weise, wie verwalteter Code mit nicht verwaltetem Code interagiert, zeigt Visual Studio keine Fehler an, die von Microsoft Office-Anwendungen ausgelöst werden. Wenn beispielsweise ein mit Office-Entwicklungstools in Visual Studio erstelltes VSTO-Add-In eine Ausnahme auslöst, wird die Microsoft Office-Anwendung fortgesetzt, ohne einen Fehler anzuzeigen. Wenn Sie diese Fehler anzeigen möchten, legen Sie den Debugger so fest, dass er für Ausnahmen für die Common Language Runtime aufbricht. Weitere Informationen finden Sie unter Verwalten von Ausnahmen mit dem Debugger.

Wenn Sie den Debugger so einstellen, dass er bei Common Language Runtime (CLR)-Ausnahmen anhält, werden nun alle Ausnahmen im Debugger angehalten, einschließlich derer, die Sie behandelt haben, und einige First-Chance-Ausnahmen aus der Laufzeitumgebung selbst, die für Ihr Projekt möglicherweise nicht relevant sind. Fehler, die auf msosec verweisen, werden nicht in jedem Projekt gefunden, sind jedoch sicher zu ignorieren. Diese Msosec-Ausnahmen wirken sich nicht auf Ihre Lösung aus.

Sie können auch Try...Catch-Anweisungen um Ihre Methoden verwenden, um Ausnahmen abzufangen.

Standardmäßig zeigt Visual Studio auch keine Just-In-Time Debuggingfehler für Office-Projekte an; Sie können dieses Feature jedoch aktivieren, damit Sie die ausgelösten Fehler sehen können. Weitere Informationen finden Sie unter Just-In-Time Debugging in Visual Studio.

Befehlszeilenargumente

Wenn die Startaktion auf der Eigenschaftenseite " Debuggen " auf " Projekt starten" festgelegt ist, verwendet Visual Studio beim Debuggen des Projekts keine Befehlszeilenargumente, auch wenn Sie Befehlszeilenargumente als Startoptionen angegeben haben. Wenn Sie beim Starten des Debuggings Befehlszeilenargumente verwenden möchten, müssen Sie eine andere Startaktion als "Projekt starten" auswählen.

Quellcodeverwaltung

Debugeigenschaften werden nicht für mehrere Benutzer unter Quellcodeverwaltung freigegeben. Visual Basic- und C#-Projekte speichern die Debugeigenschaften in einer benutzerdefinierten Datei (ProjectName.vbproj.user oder ProjectName.csproj.user), und diese Datei befindet sich nicht unter der Quellcodeverwaltung. Wenn mehrere Personen debuggen, muss jede Person Debugeigenschaften manuell eingeben.

Debuggen zwischengespeicherter Datasets in einem Projekt auf Dokumentebene

Jedes Mal, wenn Sie ein Projekt erstellen, wird das Dataset geleert und neu erstellt. Wenn Sie ein zwischengespeichertes Dataset debuggen möchten, müssen Sie das Dokument außerhalb von Visual Studio öffnen und dann den Debugger anfügen.

Debuggen von Word-Dokumentprojekten basierend auf dem Word 97-2003-Dokumentformat (*.doc)

Um ein Word-Dokumentprojekt basierend auf dem Word 97-2003-Dokumentformat (/.doc*) zu debuggen, müssen Sie den Projektordner zur Liste der vertrauenswürdigen Ordner hinzufügen. Weitere Informationen dazu finden Sie unter Vertrauen für Dokumente gewähren.

Debuggen deaktivierter Add-Ins

Microsoft Office-Anwendungen können VSTO-Add-Ins deaktivieren, die sich unerwartet verhalten. Eine Microsoft Office-Anwendung deaktiviert VSTO-Add-Ins, um zu verhindern, dass problematischer Code bei jedem Start der Anwendung geladen wird. Es ist jedoch auch einfach, unerwartetes Verhalten während des typischen Debuggings zu verursachen. Informationen zum Erneuten Aktivieren von VSTO-Add-Ins finden Sie unter How to: Re-enable a VSTO Add-in that has been disabled.

Es gibt zwei Arten von Deaktivierung, die Microsoft Office-Anwendungen für VSTO-Add-Ins verwenden: harte Deaktivierung und weiche Deaktivierung.

Harte Deaktivierung

Eine harte Deaktivierung kann auftreten, wenn ein VSTO-Add-In bewirkt, dass die Anwendung unerwartet geschlossen wird. Es kann auch auf Ihrem Entwicklungscomputer auftreten, wenn Sie den Debugger beenden, während der Startup-Ereignishandler in Ihrem VSTO-Add-In ausgeführt wird. Wenn ein VSTO-Add-In schwer deaktiviert ist, wird es in der Liste "Deaktivierte Elemente " in der Anwendung angezeigt.

Wenn eine Office-Anwendung ein mit Office-Entwicklungstools in Visual Studio erstelltes VSTO-Add-In hart deaktiviert, deaktiviert die Anwendung nur das VSTO-Add-In, das den Fehler verursacht hat. Andere VSTO-Add-Ins, die mit Office-Entwicklungstools in Visual Studio für diese Office-Anwendung erstellt wurden, werden weiterhin geladen.

Weiche Deaktivierung

Eine weiche Deaktivierung kann auftreten, wenn ein VSTO-Add-In einen Fehler erzeugt, der nicht dazu führt, dass die Anwendung unerwartet geschlossen wird. Eine Anwendung kann z. B. ein VSTO-Add-In weich deaktivieren, wenn beim Ausführen des Startup Ereignishandlers eine unbehandelte Ausnahme ausgelöst wird. Wenn ein VSTO-Add-In vorläufig deaktiviert ist, wird es in der Liste "Inaktive Anwendungs-Add-Ins " in der Anwendung angezeigt, und die Anwendung ändert den Wert des Registrierungseintrags "LoadBehavior " für das VSTO-Add-In, um anzugeben, dass es entladen wird. Weitere Informationen zum Registrierungseintrag "LoadBehavior " finden Sie unter Registrierungseinträge für VSTO-Add-Ins.

Beheben von Installationsfehlern mithilfe der Ereignisanzeige

Die Visual Studio Tools für Office-Laufzeit schreibt Meldungen für alle Ausnahmen, die beim Installieren oder Deinstallieren von Office-Lösungen ausgelöst werden, in die Ereignisanzeige in Windows. Sie können diese Meldungen verwenden, um Installations- und Bereitstellungsprobleme zu beheben.

Beheben von Startfehlern mithilfe einer Protokolldatei und Fehlermeldungen

Die Visual Studio-Tools für Office-Laufzeit können alle beim Starten auftretenden Fehler in eine Protokolldatei schreiben oder jeden einzelnen Fehler in einem Meldungsfenster anzeigen. Diese Optionen sind standardmäßig deaktiviert. Sie können die Optionen aktivieren, indem Sie Umgebungsvariablen erstellen.

Um jeden Fehler in einem Meldungsfeld anzuzeigen, erstellen Sie eine Umgebungsvariable namens VSTO_SUPPRESSDISPLAYALERTS und legen sie auf 0 (Null) fest. Sie können die Nachrichten unterdrücken, indem Sie die Umgebungsvariable löschen oder auf 1 (eins) festlegen.

Um die Fehler in eine Protokolldatei zu schreiben, erstellen Sie eine Umgebungsvariable namens VSTO_LOGALERTS und legen sie auf 1 (eins) fest. Die Visual Studio Tools für Office-Laufzeit erstellt die Protokolldatei im Ordner, die das Bereitstellungsmanifest für das VSTO-Add-In enthält, oder in dem Ordner, der das Dokument oder die Arbeitsmappe enthält, das der Anpassung zugeordnet ist. Wenn dies fehlschlägt, erstellt die Visual Studio Tools for Office-Laufzeit die Protokolldatei im lokalen %TEMP% Ordner. Für VSTO-Add-Ins auf Anwendungsebene ist der Standardname der Add-In-Name.vsto.log. Bei Projekten auf Dokumentebene ist der Name der Protokolldatei der Dokumentname. extension.log, z. B. ExcelWorkbook1.xlsx.log. Um die Protokollierung von Fehlern zu beenden, löschen Sie die Umgebungsvariable, oder legen Sie sie auf 0 (null) fest.

Verwandte Inhalte

• Erstellen von Office-Lösungen
• Vorgehensweise: Erneutes Aktivieren eines VSTO-Add-Ins, das deaktiviert wurde
• Programmieren von VSTO-Add-Ins