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.
Tipp
Um das Debuggen zu vereinfachen, schließen Sie alle geöffneten Instanzen der Office-Anwendung, bevor Sie sie erstellen und debuggen.
Gilt für: Die Informationen in diesem Thema gelten für Projekte auf Dokumentebene und VSTO-Add-In-Projekte. Siehe features available by Office-App lication and project type.
Hinweis
Möchten Sie Lösungen entwickeln, die die Office-Erfahrung auf mehreren Plattformen erweitern? Schauen Sie sich das neue Office-Add-Ins-Modell an. Office-Add-Ins haben im Vergleich zu VSTO-Add-Ins und -Lösungen einen geringen Platzbedarf, und Sie können diese mithilfe nahezu jeder Webprogrammiertechnologie erstellen, z. B. HTML5, JavaScript, CSS3 und XML.
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 gezielte Office-App lizenzierung 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, 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.
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 Office-Version (2013 oder 2016) debuggen möchten, öffnen Sie den Projekt-Designerund wählen auf der Registerkarte Debuggen die Optionsschaltfläche Externes Programm starten aus. Navigieren Sie dann zum Speicherort der ausführbaren Datei der entsprechenden Office-Anwendung.
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 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 verfügen F10 und F11 jedoch über die gleichen 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 beispielsweise ein mit Office-Entwicklungstools in Visual Studio erstelltes VSTO-Add-In eine Ausnahme auslöst, wird die Microsoft Office-App lizenzierung fortgesetzt, ohne einen 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 Verwalten von Ausnahmen mit dem Debugger.
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-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
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.
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 basierend auf dem Word 97-2003-Dokumentformat (*.doc)
Zum Debuggen eines Word-Dokumentprojekts, das auf dem Word 97-2003-Dokumentformat (/DOC*) basiert, müssen Sie den Projektordner zur Liste der vertrauenswürdigen Ordner hinzufügen. Weitere Informationen dazu finden Sie unter Erteilen einer Vertrauensstellung für Dokumente.
Debuggen deaktivierter Add-Ins
VSTO-Add-Ins, die ein unerwartetes Verhalten aufweisen, können von Microsoft Office-Anwendungen deaktiviert werden. Solche VSTO-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 VSTO-Add-Ins finden Sie unter How to: Re-enable a VSTO Add-in that has been disabled.
Es gibt zwei Arten der Deaktivierung von VSTO-Add-Ins in Microsoft Office-Anwendungen: harte Deaktivierung und weiche Deaktivierung.
Harte Deaktivierung
Eine harte Deaktivierung kann auftreten, wenn ein VSTO-Add-In bewirkt, dass die Anwendung unerwartet geschlossen wird. Sie kann auch auf dem Entwicklungscomputer auftreten, wenn Sie den Debugger beenden, während der Startup -Ereignishandler im 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-App lizenzierung 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 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 VSTO-Add-In einen Fehler erzeugt, der nicht zur unerwarteten Beendigung der Anwendung führt. Ein VSTO-Add-In kann von einer Anwendung z. B. weich deaktiviert werden, wenn es einen Ausnahmefehler auslöst, während der Startup -Ereignishandler ausgeführt 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 in die Ereignisanzeige in Windows für alle Ausnahmen, die beim Installieren oder Deinstallieren von Office-Lösungen ausgelöst werden. Anhand dieser Meldungen können Sie Installations- und Bereitstellungsprobleme beheben.
Beheben von Startfehlern mithilfe einer Protokolldatei und Fehlermeldungen
Die Visual Studio-Tools für Die Office-Laufzeit kann alle Fehler schreiben, die beim Start in eine Protokolldatei auftreten oder jeden Fehler in einem Meldungsfeld anzeigen. Standardmäßig werden diese Optionen deaktiviert. Sie können die Optionen aktivieren, indem Sie Umgebungsvariablen erstellen.
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 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 für Office-Laufzeit die Protokolldatei im lokalen Ordner "%TEMP%". Für VSTO-Add-Ins auf Anwendungsebene lautet der Standardname „ Add-In-Name.vsto.log“. Für Projekte auf Dokumentebene lautet der Name der Protokolldatei „ Dokumentname.Erweiterung.log“; Beispiel: „ExcelWorkbook1.xlsx.log“. Um die Fehlerprotokollierung zu beenden, löschen Sie die Umgebungsvariable, oder legen Sie sie auf 0 (null) fest.