Debuggen von Office-Projekten

Sie können Office-Projekte debuggen, indem Sie die gleichen Tools Microsoft Visual Studio verwenden, die Sie für andere Visual Studio-Projekte verwenden.Visual Studio Debuggerfeatures, wie die Fähigkeit, Haltepunkte einzufügen und Variablen im Fenster Lokal anzuzeigen, stehen auch verfügbar, wenn Sie Office-Projekte debuggen.Weitere Informationen über Visual Studio-Debugtools finden Sie unter Debuggen in Visual Studio.

Tipp
Um das Debuggen zu vereinfachen, schließen Sie alle geöffneten Instanzen der Office-Anwendung bevor Sie sie erstellen und debuggen.

Betrifft: Die Informationen in diesem Thema betreffen Projekte auf Dokument- und auf Anwendungsebene für Office 2013 und Office 2010. Weitere Informationen finden Sie unter Verfügbare Funktionen nach Office-Anwendung und Projekttyp.

Eine entsprechende Videodemo finden Sie unter How Do I: Debug a VSTO Application?.

Starten und Beenden des Debuggers

Sie können das Debuggen eines Office-Projekts so wie Sie gestartet das Debuggen anderer Visual Studio-Projekte; Beispielsweise können Sie die F5-TASTE drücken.Wenn Sie das Debuggen eines Add-In-Projekt auf Anwendungsebene beginnen, wird ein neuer Prozess für die entsprechende Office-Anwendung gestartet und das Add-In geladen.Wenn Sie das Debuggen eines Projekts auf Dokumentebene starten, wird das Dokument oder die Arbeitsmappe in einem neuen Word- oder Excel-Prozess.

Wenn Sie den Debugger beenden, bricht der Debugger den Anwendungsprozess abrupt ab oder trennt sich vom Prozess, sofern Sie dies festgelegt haben.Alle anderen Dokumente, die im beendeten Office-Anwendungsprozess geöffnet sind, werden auch ohne Warnung und alle nicht gespeicherten Änderungen verloren gehen geschlossen.Dazu können alle Dokumente oder Arbeitsmappen gehören, die geöffnet werden, während der Debugger ausgeführt wird.

In der Regel auf trennen empfiehlt es sich, den Prozess, vor dem Beenden des Debuggers, damit Sie die Office-Anwendung normal beenden können.Sie können Sie den Prozess auch zuerst trennen, wenn Sie weiterhin mit einem geöffneten Dokument oder Arbeitsblatt arbeiten möchten, nachdem Sie den Debugger beendet haben.Weitere Informationen zum Trennen vom Prozess finden Sie unter Gewusst wie: Trennen aller Prozesse.

Wenn Sie eine Anpassung auf Dokumentebene für Word debuggen und wiederholt beenden, können der Debugger und dem Word, Debugsitzungen kann zu der Normal-Vorlage führen, die beschädigt ist.In diesem Fall können Sie die beschädigte Normal-Vorlage löschen. Sie wird beim nächsten Öffnen von Word automatisch neu erstellt.In der Normal-Vorlage gespeicherte Makros werden allerdings nicht neu erstellt.

Verhalten von F10 und F11

Beim Starten des Debuggens eines Office-Projekts haben F10 und F11 eine andere Funktion als beim Starten des Debuggens anderer Visual Basic- oder C#-Projekte.In Visual Basic- oder C#-Projekten wird der Debugger bei der main-Funktion angehalten. In Office-Projekten besitzt Visual Studio dagegen keine Kontrolle über die main-Funktion der Office-Anwendung.Während des Debuggens hingegen haben F10 und F11 dieselben Funktionen wie in Visual Basic- und C#-Projekten.

Anzeigen von Ausnahmen

Durch die Art und Weise der Interaktion zwischen verwaltetem und nicht verwaltetem Code werden in Visual Studio keine Fehler angezeigt, die von Microsoft Office-Anwendungen ausgelöst werden.Wenn ein Add-In, das erstellt wird, mithilfe der Office-Entwicklungstools in Visual Studio, eine Ausnahme auslöst, wird die Microsoft Office-Anwendung fortgesetzt, ohne Fehler anzuzeigen.Um diese Fehler anzuzeigen, konfigurieren Sie den Debugger so, dass er bei Ausnahmen der Common Language Runtime anhält.Weitere Informationen finden Sie unter Gewusst wie: Unterbrechen bei ausgelöster Ausnahme.

Wenn Sie das auf der Common Language Runtime anhält, Debugger, alle Ausnahmen nun der Debugger unterbrechen, darunter eine, die Sie behandelt haben und einige Erstmöglichkeitsausnahmen von der Laufzeit selbst relevant sind, die nicht dem Projekt möglicherweise.Fehler, in denen darauf Bezug genommen wird, dass msosec nicht gefunden werden kann, treten in jedem Projekt auf, können aber ignoriert werden.Diese msoec-Ausnahmen haben keine Auswirkungen auf die Projektmappe.

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

In der Standardeinstellung zeigt Visual Studio auch keine Just-In-Time-Debugfehler für Office-Projekte an. Sie können dieses Feature jedoch aktivieren, um die ausgelösten Fehler anzuzeigen.Weitere Informationen finden Sie unter Just-In-Time-Debuggen.

Befehlszeilenargumente

Wenn auf der Debugeigenschaftenseite die Startaktion auf Projekt starten festgelegt wird, werden beim Debuggen des Projekts von Visual Studio keine Befehlszeilenargumente verwendet. Dies ist auch dann der Fall, wenn Befehlszeilenargumente als Startoptionen angegeben wurden.Wenn Sie beim Debuggen Befehlszeilenargumente verwenden möchten, müssen Sie eine andere Startaktion als Projekt starten auswählen.

Quellcodeverwaltung

In der Quellcodeverwaltung werden Debugeigenschaften nicht für mehrere Benutzer gemeinsam verwendet.Visual Basic- und C#-Projekten werden die Debugeigenschaften in einer benutzerspezifischen Datei vvbproj.user (Projektname oder Projektname csproj.user), und diese Datei wird nicht unter Quellcodeverwaltung.Wenn mehrere Personen debuggen, muss jede Person die Debugeigenschaften manuell eingeben.

Debuggen zwischengespeicherter Datasets in einem Projekt auf Dokumentebene

Bei jeder Erstellung eines Projekts 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 auf Grundlage des Dokumentformats für Word 97-2003 (*.doc).

Zum Debuggen eines Word-Dokumentprojekts, das auf dem Dokumentformat für Word 97-2003 (*.doc) basiert, müssen Sie den Projektordner der Liste vertrauenswürdiger Ordner hinzufügen.Weitere Informationen dazu, wie dies, finden Sie unter. Gewähren von Vertrauenswürdigkeit für Dokumente ausführt.

Debuggen deaktivierter Add-Ins

Microsoft Office-Anwendungen können Add-Ins deaktivieren, die unerwartetes Verhalten aufweisen.Solche Add-Ins werden von der Microsoft Office-Anwendung deaktiviert, um zu verhindern, dass bei jedem Start der Anwendung problematischer Code geladen wird.Aber auch beim typischen Debuggen kann es zu unerwartetem Verhalten kommen.Informationen zum erneuten Aktivieren von Add-Ins finden Sie unter Gewusst wie: Erneutes Aktivieren von Add-Ins, die deaktiviert wurden.

Es gibt zwei Arten der Deaktivierung von Add-Ins in Microsoft Office-Anwendungen: harte Deaktivierung und weiche Deaktivierung.

Harte Deaktivierung

Die harte Deaktivierung kann auftreten, wenn ein Add-In zur unerwarteten Beendigung einer Anwendung führt.Sie kann auch auf dem Entwicklungscomputer auftreten, wenn Sie den Debugger anhalten, während der Startup-Ereignishandler im Add-In ausgeführt wird.Wenn ein Add-In hart deaktiviert wird, wird es in der Liste Deaktivierte Elemente in der Anwendung angezeigt.

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

Weiche Deaktivierung

Die weiche Deaktivierung kann auftreten, wenn ein Add-In einen Fehler erzeugt, der nicht zur unerwarteten Beendigung der Anwendung führt.Eine Anwendung kann ein Add-In z. B. weich deaktivieren, wenn es einen Ausnahmefehler auslöst, während der Startup-Ereignishandler ausgeführt wird.Wenn ein Add-In weich deaktiviert wird, 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 Add-In, um anzugeben, dass es entladen wurde.Weitere Informationen zum Registrierungseintrag LoadBehavior finden Sie unter Registrierungseinträge für Add-Ins auf Anwendungsebene.

Problembehandlung 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-Projektmappen ausgelöst werden, in die Ereignisanzeige in Windows.Anhand dieser Meldungen können Sie Installations- und Bereitstellungsprobleme beheben.

Problembehandlung von Startfehlern mithilfe einer Protokolldatei und Fehlermeldungen

Alle beim Start auftretenden Fehler können von der Visual Studio-Tools für Office-Laufzeit in eine Protokolldatei geschrieben oder in einem Meldungsfeld angezeigt werden.Standardmäßig werden diese Optionen deaktiviert.Durch das Erstellen von Umgebungsvariablen können Sie diese Optionen aktivieren.

Um jeden Fehler in einem Meldungsfeld anzuzeigen, erstellen Sie eine Umgebungsvariable mit dem Namen VSTO_SUPPRESSDISPLAYALERTS, die Sie auf 0 (null) festlegen.Sie können die Meldungen 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 mit dem Namen VSTO_LOGALERTS, die Sie auf 1 (eins) festlegen.Visual Studio-Tools für Office-Laufzeit erstellt die Protokolldatei in dem Ordner, der das Bereitstellungsmanifest für das Add-In enthält, oder im Ordner, der das Dokument oder die Arbeitsmappe enthält, die der Anpassung zugeordnet ist.Wenn dies fehlschlägt, erstellt Visual Studio-Tools für Office-Laufzeit die Protokolldatei im lokalen Ordner "%TEMP%".Bei Add-Ins auf Anwendungsebene ist der Standardname Erweiterungsname.vsto.log.Bei Projekten auf Dokumentebene ist der Name der Protokolldatei Dokumentname.Erweiterung.log, wie ExcelWorkbook1.xlsx.log.Um die Fehlerprotokollierung zu beenden, löschen Sie die Umgebungsvariable, oder legen Sie sie auf 0 (null) fest.

Siehe auch

Aufgaben

Gewusst wie: Erneutes Aktivieren von Add-Ins, die deaktiviert wurden

Weitere Ressourcen

Aktualisieren von Office-Projektmappen

Programmieren von Add-Ins auf Anwendungsebene