Dieser Artikel wurde manuell übersetzt. Bewegen Sie den Mauszeiger über die Sätze im Artikel, um den Originaltext anzuzeigen. Weitere Informationen
Übersetzung
Original
Informationen
Das angeforderte Thema wird unten angezeigt. Es ist jedoch nicht in dieser Bibliothek vorhanden.

Debuggen von Office-Projekten

Sie können Office-Projekte mit den gleichen Microsoft Visual Studio-Tools debuggen, die Sie auch für andere Visual Studio-Projekte verwenden. Visual Studio-Debuggerfunktionen, beispielsweise die Fähigkeit, Haltepunkte einzufügen und Variablen im Fenster Lokal anzuzeigen, stehen auch zur Verfügung, wenn Sie Office-Projekte debuggen. Weitere Informationen über Visual Studio-Debugtools finden Sie unter Debuggen in Visual Studio.

Tipp 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 Anwendungsebene für Office 2013 und Office 2010. Weitere Informationen finden Sie unter Verfügbare Funktionen nach Office-Anwendung und Projekttyp.

Link zu Video Eine entsprechende Videodemo finden Sie im Abschnitt zum Debuggen einer VSTO-Anwendung.

Um mit dem Debuggen eines Office-Projekts zu beginnen, gehen Sie genauso vor wie bei einem Visual Studio-Projekt. Eine Möglichkeit besteht darin, die F5-TASTE zu drücken. Wenn Sie mit dem Debuggen eines Add-In-Projekts auf Anwendungsebene beginnen, wird ein neuer Prozess für die entsprechende Office-Anwendung gestartet, und das 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, bricht der Debugger den Anwendungsprozess abrupt ab oder trennt sich vom Prozess, sofern Sie dies festgelegt haben. Alle anderen Dokumente, die in einem beendeten Office-Anwendungsprozess geöffnet sind, werden ohne Warnung ebenfalls geschlossen, wobei alle nicht gespeicherten Änderungen verloren gehen. Dazu können alle Dokumente oder Arbeitsmappen gehören, die geöffnet werden, während der Debugger ausgeführt wird.

Normalerweise empfiehlt es sich, den Prozess vor dem Beenden des Debuggers zu trennen. So können Sie die Office-Anwendung normal beenden. Wenn Sie nach dem Beenden des Debuggers weiter in einem geöffneten Dokument oder Arbeitsblatt arbeiten möchten, können Sie den Prozess auch zuerst trennen.

Wenn Sie eine Anpassung auf Dokumentebene für Word debuggen, kann das wiederholte Beenden des Debuggers ein abruptes Schließen von Word zur Folge haben, wodurch die Normal-Vorlage beschädigt werden kann. 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.

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.

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 mithilfe der Office-Entwicklungstools in Visual Studio erstelltes Add-In beispielsweise eine Ausnahme auslöst, wird die Ausführung der Microsoft Office-Anwendung fortgesetzt, ohne dass ein Fehler angezeigt wird. 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 den Debugger so konfigurieren, dass er bei Ausnahmen der Common Language Runtime anhält, wird der Debugger bei jeder Ausnahme aufgerufen. Dazu gehören auch Ausnahmen, die Sie behandelt haben, sowie Ausnahmen (erste Chance), die von der Common Language Runtime selbst ausgelöst werden und für das Projekt nicht relevant sind. 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 in Visual Studio.

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.

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

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.

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 finden Sie unter Gewähren von Vertrauenswürdigkeit für Dokumente.

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.

ms269003.collapse_all(de-de,VS.120).gifHarte 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.

ms269003.collapse_all(de-de,VS.120).gifWeiche 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.

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.

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. Die Visual Studio-Tools für Office-Laufzeit erstellt die Protokolldatei in dem Ordner, der das Bereitstellungsmanifest für das Add-In enthält, bzw. dem Ordner, der das Dokument oder die Arbeitsmappe enthält, das bzw. die der Anpassung zugeordnet ist. Wenn dieser Vorgang fehlschlägt, erstellt die Visual Studio-Tools für Office-Laufzeit die Protokolldatei im lokalen Ordner "%TEMP%". Für Add-Ins auf Anwendungsebene lautet der Standardname add-in name.vsto.log. Der Name der Projekte auf Dokumentebene lautet "document name.extension.log", z. B. "ExcelWorkbook1.xlsx.log". Um die Fehlerprotokollierung zu beenden, löschen Sie die Umgebungsvariable, oder legen Sie sie auf 0 (null) fest.

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.

Community-Beiträge

Anzeigen:
© 2015 Microsoft