Debuggen in Projekten auf Dokumentebene

Artikel
08/10/2011

Aktualisiert: September 2010

Sie können Projekte auf Dokumentebene für Microsoft Office Word und Microsoft Office Excel mit denselben Visual Studio-Tools debuggen, die Sie auch in anderen Projekten verwenden. Beim Ausführen eines Projekts im Debugmodus startet Visual Studio entweder Word oder Excel, und der Debugger überwacht die Ausführung Ihres Codes, der im Prozess von Word oder Excel ausgeführt wird. Weitere Informationen zu den Debugtools von Visual Studio finden Sie unter Debuggen in Visual Studio.

Tipp

Schließen Sie vor dem Erstellen und Debuggen alle geöffneten Instanzen von Word oder Excel, um Konflikte zu vermeiden.

Betrifft: Die Informationen in diesem Thema betreffen Projekte auf Dokumentebene für die folgenden Anwendungen: Excel 2007 und Excel 2010, Word 2007 und Word 2010. Weitere Informationen finden Sie unter Verfügbare Funktionen nach Office-Anwendung und Projekttyp.

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

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. Weitere Informationen finden Sie unter Debugging Shortcut Keys, Brief Scheme.

Beenden des Debuggers

Wenn Sie mit dem Debuggen eines Dokuments oder einer Arbeitsmappe beginnen, wird das Dokument oder die Arbeitsmappe in einem neuen Word- oder Excel-Prozess geöffnet. Wenn Sie den Debugger beenden, beendet dieser abrupt den Word- oder Excel-Prozess oder trennt sich vom Prozess, sofern Sie ihn entsprechend eingerichtet haben. Alle anderen Dokumente oder Arbeitsmappen, die in einem beendeten Word- oder Excel-Prozess 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 Word und Excel normal beenden. Wenn Sie nach dem Beenden des Debuggers weiter in einem geöffneten Dokument oder Arbeitsblatt arbeiten, können Sie den Prozess auch zuerst trennen. Weitere Informationen zum Trennen vom Prozess finden Sie unter Gewusst wie: Trennen aller Prozesse.

Das wiederholte Beenden des Debuggers und das damit einhergehende plötzliche Beenden von Word während umfangreicher Debugsitzungen kann zur Beschädigung der Normal-Vorlage führen. 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.

Die Normal-Vorlage wird von Word gesperrt, während das Programm in Visual Studio geöffnet ist

Wenn Word in Visual Studio geöffnet ist, ist die Normal-Standardvorlage gesperrt. Wenn Sie die Projektmappe zum Debuggen ausführen, wird eine Kopie von Word in einem anderen Prozess geöffnet. Wenn Sie an der geöffneten Kopie von Word Anpassungen auf Anwendungsebene vornehmen, können Sie diese Änderungen nicht speichern, da die Normal-Vorlage durch den in Visual Studio geöffneten Prozess gesperrt wird.

Zur Laufzeit öffnet Word separate Instanzen von Dokumenten in einem einzigen Prozess. Daher ist es unwahrscheinlich, dass ein geöffnetes Dokument die Normal-Vorlage sperrt und Änderungen auf Anwendungsebene verhindert.

Weitere Informationen finden Sie im Knowledge Base-Artikel "PRB: Prompt to Save Normal.dot When Using Word as an Automation Server" (https://support.microsoft.com/default.aspx?scid=kb;de-de;285885).

Debuggen zwischengespeicherter Datasets

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

Quellcodeverwaltung

In der Quellcodeverwaltung werden Debugeigenschaften nicht für mehrere Benutzer gemeinsam verwendet. In Visual Basic-Projekten 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.

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.

Problembehandlung von Installationsfehlern mithilfe der Ereignisanzeige

Die Visual Studio Tools for 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. Weitere Informationen finden Sie unter Ereignisprotokollierung für Office-Lösungen.

Problembehandlung von Startfehlern mithilfe einer Protokolldatei und Fehlermeldungen

Alle beim Start auftretenden Fehler können von der Visual Studio Tools for 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 for Office-Laufzeit erstellt die Protokolldatei in dem Ordner, der das Dokument oder die Arbeitsmappe enthält, das bzw. die der Anpassung zugeordnet ist, oder wenn dies fehlschlägt, im lokalen Ordner "%TEMP%". Der Name der Protokolldatei lautet "Dokumentname.Erweiterung.log", z. B. "ExcelWorkbook1.xlsx.log". Um die Fehlerprotokollierung zu beenden, löschen Sie die Umgebungsvariable, oder legen Sie sie auf 0 (null) fest.

Siehe auch

Änderungsprotokoll

Datum	Versionsgeschichte	Grund
September 2010	Ein Abschnitt zur Problembehandlung von Installationsfehlern mithilfe der Ereignisanzeige wurde hinzugefügt.	Informationsergänzung.
Mai 2010	Einige Details zu Protokollierungsfehlern wurden korrigiert.	Korrektur inhaltlicher Fehler.

September 2010

Ein Abschnitt zur Problembehandlung von Installationsfehlern mithilfe der Ereignisanzeige wurde hinzugefügt.

Informationsergänzung.

Mai 2010

Einige Details zu Protokollierungsfehlern wurden korrigiert.

Korrektur inhaltlicher Fehler.

Freigeben über