Problembehandlung in Visual Studio zur Entwurfszeit

Artikel
04/28/2010

Aktualisiert: November 2007

Die folgenden Probleme können auftreten, während Sie Projektmappen mit Visual Studio Tools for Office entwickeln.

Speichern und anschließendes Ausführen einer Projektmappe lösen einen Fehler aus

Visual Studio speichert Projektmappen in einem temporären Ordner, bis sie gespeichert werden. Visual Studio Tools for Office ändert die Sicherheitsrichtlinie automatisch, um der Projektmappe am temporären Speicherort zu vertrauen. Diese Änderungen werden vorgenommen, wenn die Projektmappe erstellt wird. Wenn Sie an der Projektmappe keine Änderungen mehr vornehmen, bevor Sie sie in einem permanenten Ordner speichern, erstellt Visual Studio die Projektmappe nicht neu, wenn Sie sie von ihrem neuen Speicherort ausführen. Deshalb wird die Projektmappe am neuen Speicherort nicht automatisch als vertrauenswürdig eingestuft, und sie lässt sich nicht ausführen.

Wenn ein Fehler auftritt, nachdem Sie eine neue Projektmappe an einem permanenten Speicherort gespeichert haben, öffnen Sie das Menü Erstellen, und klicken Sie auf Projektmappe neu erstellen. Dies führt dazu, dass Visual Studio die Projektmappe auch dann erstellt, wenn Sie keine Änderungen daran vorgenommen haben. Visual Studio Tools for Office nimmt dann die entsprechenden Änderungen an der Sicherheitsrichtlinie für den neuen Speicherort vor.

Es kann kein Projekt auf Dokumentebene erstellt werden, das auf einem Dokument mit beschränkten Berechtigungen basiert

Visual Studio Tools for Office kann keine Projekte auf Dokumentebene erstellen, wenn das Dokument beschränkte Berechtigungen hat. Wenn Ihr Projekt ein Dokument mit beschränkten Berechtigungen enthält, kann das Projekt nicht kompiliert werden, und es wird die folgende Meldung im Fenster Fehlerliste angezeigt:

Fehler beim Hinzufügen der Anpassung.

Wenn Sie ein Dokument mit beschränkten Berechtigungen einschließen möchten, müssen Sie beim Entwickeln und Erstellen der Projektmappe ein unbeschränktes Dokument verwenden. Übernehmen Sie dann die beschränkten Berechtigungen für das Dokument am Veröffentlichungsort, nachdem Sie die Projektmappe veröffentlicht haben.

Einige Ereignisse werden nicht ausgelöst, wenn C# verwendet wird

Office-Objekte, die eine Methode und ein Ereignis mit demselben Namen haben, wurden in den primären Interop-Assemblys für Office in zwei Objekte aufgespalten: ein Kernobjekt mit allen Eigenschaften und Methoden und ein Ereignisobjekt, das Ereignisse enthält, deren Name zu einem Konflikt mit einer Eigenschaft oder einer Methode führt. Diese Ereignisobjekte verwenden die Namenskonvention <Objektname>_Event. Wenn Sie ein erwartetes Ereignis nicht sehen, wandeln Sie es in die <Objektname>_Event-Schnittstelle um.

Es gibt zum Beispiel ein ActivateEvent-Ereignis und eine Activate-Methode für ein Workbook. Um dieses Ereignis zu behandeln, verwenden Sie WorkbookEvents_Event statt Workbook.

Erstellen Sie im Deklarationsabschnitt Membervariablen:

private Excel.Workbook wkbk;
private Excel.WorkbookEvents_Event wbEvents;
private Excel.WorkbookEvents_ActivateEventHandler activateEvent;

Verbinden Sie das Ereignis in _Startup:

wbEvents = (Excel.WorkbookEvents_Event)wkbk;
activateEvent = new Excel.WorkbookEvents_ActivateEventHandler(ThisWorkbook_Activate);
wbEvents.Activate += activateEvent;

Schreiben Sie einen Ereignishandler:

private void ThisWorkbook_Activate()
{
    // Your code goes here.
}

Sie müssen in WorkbookEvents_Event umwandeln, da Excel.Workbook.Activate die Activate-Methode und nicht das ActivateEvent-Ereignis zurückgibt.

Alternativ können Sie das Objekt in seine entsprechende Ereignisschnittstelle in Startup umwandeln:

((Excel.WorkbookEvents_Event)(Globals.ThisWorkbook.InnerObject)).Activate += 
    new Excel.WorkbookEvents_ActivateEventHandler(ThisWorkbook_Activate);

Schreiben Sie dann einen Ereignishandler für den Code:

private void ThisWorkbook_Activate()
{
    // Your code goes here.
}

Verweise auf Office-Klassen werden nicht erkannt

Einige Klassennamen wie Application kommen in mehreren Namespaces vor, z. B. in Microsoft.Office.Interop.Word und System.Windows.Forms. Aus diesem Grund enthält die Imports/using-Anweisung am Anfang der Projektvorlage eine verkürzte Qualifizierungskonstante, z. B.:

Imports Word = Microsoft.Office.Interop.Word

using Word = Microsoft.Office.Interop.Word;

Bei dieser Verwendung der Imports/using-Anweisung müssen Sie anhand des Word- oder Excel-Qualifizierers eine Unterscheidung zwischen den Verweisen auf Office-Klassen vornehmen. Beispiel:

Dim doc As Word.Document

Word.Document doc;

Bei Verwendung einer Deklaration ohne Qualifizierer werden Fehlermeldungen ausgegeben. Beispiel:

Dim doc As Document  ' Class is ambiguous

Document doc;  // Class is ambiguous

Obwohl Sie den Word- oder Excel-Namespace importiert haben und über Zugriff auf alle Klassen darin verfügen, müssen Sie alle Typen mit Word oder Excel voll qualifizieren, um die Zweideutigkeit beim Namespace auszuräumen.

Beim Erstellen eines neuen Projekts auf Basis eines bestehenden Projektdokuments gehen Steuerelementeigenschaften verloren

Wenn Sie ein neues Visual Studio Tools for Office-Projekt anhand eines Dokuments aus einem bestehenden Projekt erstellen, werden die Eigenschaften für Steuerelemente auf dem Dokument nicht in das neue Projekt kopiert. Sie müssen die Eigenschaften für alle vorher bestehenden Steuerelemente manuell zurücksetzen. Alternativ können Sie die Steuerelementeigenschaften übernehmen, indem Sie statt eines neuen Projekts eine Kopie des bestehenden Projekts erstellen oder indem Sie das bestehende Projekt in die neue Projektmappe (im Designer) laden und die Steuerelemente aus dem bestehenden Dokument kopieren und in das neue Dokument einfügen.

Steuerelemente werden auf dem Dokument oder dem Arbeitsblatt als schwarze Rechtecke angezeigt

Wenn Sie Steuerelemente auf einem Dokument oder einem Arbeitsblatt gruppieren, erkennt Visual Studio Tools for Office die Steuerelemente nicht mehr. Auf gruppierte Steuerelemente kann im Eigenschaftenfenster nicht zugegriffen werden, und sie werden auf dem Dokument oder Arbeitsblatt als schwarze Rechtecke angezeigt. Sie müssen die Gruppierung der Steuerelemente auflösen, um ihre Funktionalität wiederherzustellen.

Steuerelemente in einer Word-Vorlage sind in Visual Studio nicht sichtbar.

Wenn Sie eine Word-Vorlage im Visual Studio-Designer öffnen, sind Steuerelemente in der Vorlage, die nicht in den Textfluss eingefügt wurden, eventuell nicht sichtbar. Dies ist darauf zurückzuführen, dass Word-Vorlagen in Visual Studio in der Normalansicht geöffnet werden. Um die Steuerelemente anzuzeigen, klicken Sie auf das Menü Ansicht, zeigen Sie auf Microsoft Office Word-Ansicht, und klicken Sie dann auf Seitenlayout.

Zwischengespeicherte Visual Basic-Datasetnamen werden im Cache nicht ordnungsgemäß angezeigt

DataSet-Objekte, die unter Verwendung von Visual Basic erstellt wurden und die als Cached und als WithEvents gekennzeichnet sind (einschließlich der DataSet-Objekte, die aus dem Datenquellenfenster oder aus der Toolbox gezogen wurden und deren CacheInDocument-Eigenschaft auf True festgelegt ist), sind mit einem dem Namen vorangestellten Unterstrich im Cache enthalten. Wenn Sie beispielsweise ein DataSet mit dem Namen Customers erstellen, lautet der CachedDataItem-Name im Cache _Customers. Wenn Sie für den Zugriff auf dieses zwischengespeicherte Element ServerDocument verwenden, müssen Sie _Customers anstelle von Customers angeben.

Compilerfehler bei Microsoft Office 2003-Projekt mit dem Namen "Excel" oder "Word"

In Office-Projekten sind Excel und Word reservierte Schlüsselwörter.

Compilerfehler nach dem Löschen eines NamedRange-Steuerelements

Wenn Sie ein NamedRange-Steuerelement aus einem Arbeitsblatt löschen, das nicht das aktive Arbeitsblatt im Designer ist, wird der automatisch generierte Code möglicherweise nicht aus dem Projekt entfernt, und es können Compilerfehler auftreten. Um sicherzustellen, dass der Code entfernt wird, müssen Sie vor dem Löschen des Steuerelements immer das Arbeitsblatt auswählen, das das NamedRange-Steuerelement enthält, um dieses als aktives Arbeitsblatt festzulegen. Wenn automatisch generierter Code beim Löschen des Steuerelements nicht gelöscht wird, können Sie den Designer anweisen, den Code zu löschen. Aktivieren Sie dazu das Arbeitsblatt, und nehmen Sie eine Änderung vor, sodass das Arbeitsblatt als geändert markiert wird. Beim Neuerstellen des Projekts wird der Code entfernt.

Zugriff auf die Assembly über HTTP-Pfad funktioniert nicht

Es gibt zwei Haupterklärungen:

Der Projekt-Assistent aus Visual Studio Tools for Office ändert keine Sicherheitsrichtlinien für Assemblys, die unter HTTP-Adressen erstellt wurden. Sie müssen der Assembly manuell volle Vertrauenswürdigkeit gewähren. Weitere Informationen finden Sie unter Gewusst wie: Gewähren von Berechtigungen für Ordner und Assemblys (2003 System).
ASP.NET deaktiviert standardmäßig das Herunterladen von DLLs. Damit Assemblys von Benutzern heruntergeladen werden können, muss der Administrator des Webservers die IIS-Eigenschaften (Internet-Informationsdienste) so ändern, dass DLLs aus dem Verzeichnis mit der Assembly heruntergeladen werden dürfen. Weitere Informationen finden Sie in der IIS-Hilfe unter https://localhost/iisHelp/ auf dem Webserver.

Um zu testen, ob dies die Ursache des Problems ist, können Sie das Protokoll des Webservers auf verweigerte DLL-Anforderungen hin prüfen. Wenn die Ursache eine andere zu sein scheint, stellen Sie den Debugger so ein, dass er bei allen Ausnahmen unterbricht, und prüfen Sie die Fehlermeldungen.

In UNC-Netzwerkverzeichnissen erstellte Projekte ändern die Sicherheitsrichtlinien nicht automatisch

Der Projekt-Assistent aus Visual Studio Tools for Office ändert die Sicherheitsrichtlinie auf Benutzerebene. Wenn Sie ein Projekt in einem UNC-Netzwerkverzeichnis erstellen, müssen Sie der Assembly in den Sicherheitsrichtlinien auf Computerebene Vertrauenswürdigkeit gewähren. Erst dann können Sie sie ausführen. Änderungen der Richtlinien auf Computerebene müssen Sie manuell vornehmen. Weitere Informationen finden Sie unter Gewusst wie: Gewähren von Berechtigungen für Ordner und Assemblys (2003 System).

Beim Öffnen eines Dokuments wird kein DocumentChange-Ereignis ausgelöst

Das DocumentChange-Ereignis wird ausgelöst, wenn das aktive Dokument geändert wird. Oft wird es auch beim Öffnen eines Dokuments ausgelöst. Doch wegen der verschiedenen Arten, auf die Word-Dokumente geöffnet werden können (z. B. über die Eingabeaufforderung, in Windows Explorer oder im Menü Datei in Word), wird das DocumentChange-Ereignis u. U. nicht immer beim Öffnen des Dokuments ausgelöst. Es sollte immer ausgelöst werden, wenn das aktive Dokument nach dem Öffnen geändert wird. Verwenden Sie das Startup-Ereignis, wenn Aktionen beim Öffnen des Dokuments ausgeführt werden sollen.

Threads werden nach dem Debuggen nicht ordnungsgemäß angehalten

Visual Studio Tools for Office folgt einer Threadnamenskonvention, die den Debugger in die Lage versetzt, das Programm ordnungsgemäß zu schließen. Wenn Sie in der Projektmappe Threads erstellen, stellen Sie vor den Namen jedes einzelnen Threads das Präfix VSTA_, um sicherzustellen, dass diese Threads ordnungsgemäß behandelt werden, wenn Sie das Debuggen stoppen. Legen Sie beispielsweise die Name-Eigenschaft eines Threads, der auf ein Netzwerkereignis wartet, auf VSTA_NetworkListener fest.

Excel-Ereignisse werden in Internet Explorer anders ausgelöst als in Excel

In einer von Internet Explorer gehosteten Arbeitsmappe werden Ereignisse in einer anderen Reihenfolge ausgelöst als in einer in Excel geöffneten Arbeitsmappe. Außerdem werden einige Ereignisse zweimal ausgelöst. Wenn Ihre Projektmappe Internet Explorer einschließt, sollten Sie testen, wie sich die unterschiedliche Ereignisreihenfolge auf das Funktionieren der Projektmappe auswirkt.

Beim Erstellen eines Dokuments auf Grundlage einer Vorlage wird kein New-Ereignis ausgelöst

Wenn Sie die Eingabeaufforderung verwenden, um eine Word-Vorlage zu öffnen und ein neues Dokument zu erstellen, müssen Sie den /z-Schalter verwenden, um das New-Ereignis auszulösen. Fügen Sie nach /z kein Leerzeichen ein, ansonsten erstellt Word kein neues Dokument auf Grundlage der Vorlage, sondern öffnet die Vorlage für die Bearbeitung. Beispiel: winword.exe /z"mytemplate.dot"

Dies ähnelt der Verwendung des /t-Schalters, nur dass /z zusätzlich das New-Ereignis auslöst.

Beim Öffnen eines XML-Arbeitsblatts wird kein Open-Ereignis ausgelöst

Wenn Sie einem Excel-Projekt ein vorhandenes systemfremdes Arbeitsblatt (z. B. Excel-XML-Format) zugrunde legen, wird das Open-Ereignis beim Öffnen des Arbeitsblatts nicht ausgelöst.

BeforeClose-Methode wird ausgeführt, aber Benutzer lässt Arbeitsmappe geöffnet

Ein Endbenutzer kann den Schließvorgang einer Arbeitsmappe abbrechen und die Projektmappe weiter verwenden, nachdem der BeforeClose-Ereignishandler aufgerufen wurde. Das geschieht, wenn der Benutzer Änderungen in einer Arbeitsmappe vornimmt und sie dann ohne vorheriges Speichern schließen möchte. Der BeforeClose-Ereignishandler wird aufgerufen, und es wird ein Dialogfeld mit der Option zum Abbrechen des Schließvorgangs angezeigt.

Wenn Sie Code in den BeforeClose-Ereignishandler schreiben, mit dem Datenbankverbindungen beendet oder sonstige Bereinigungsvorgänge durchgeführt werden, wird dieser Code u. U. aufgerufen, während der Benutzer noch mit der Projektmappe arbeitet.

Befehl "ClipArt einfügen" bewirkt nichts in Visual Studio-Designer

Wenn Sie das Menü Einfügen öffnen, auf Grafik zeigen und dann auf ClipArt klicken, wird nicht der ClipArt-Aufgabenbereich geöffnet, wenn zur selben Zeit Excel oder Word im Visual Studio-Designer geöffnet ist. Um ein ClipArt-Objekt mit den Menübefehlen hinzuzufügen, müssen Sie die Kopie des Arbeitsblatts oder Dokuments öffnen, die sich außerhalb von Visual Studio im Hauptprojektordner befindet (nicht die Kopie im \bin-Ordner), das ClipArt-Objekt hinzufügen und anschließend das Arbeitsblatt oder Dokument speichern.

Ein Office 2003-Projekt auf Dokumentebene kann nicht erstellt werden, obwohl Office 2003 installiert ist

Dieses Problem kann auftreten, wenn 2007 Microsoft Office System deinstalliert und anschließend Office 2003 installiert wird. Beim Erstellen eines Office 2003-Anpassungsprojekts auf Dokumentebene wird möglicherweise folgende Fehlermeldung angezeigt:

"Auf diesem Computer ist keine kompatible Version von Microsoft Office installiert."

So beheben Sie dieses Problem:

Schließen Sie Visual Studio.
Öffnen Sie die entsprechende Microsoft Office-Anwendung, und schließen Sie die Anwendung. Wenn Sie beispielsweise ein Excel 2003-Arbeitsmappenprojekt erstellen möchten, öffnen Sie Excel 2003, und schließen Sie es dann.
Starten Sie Visual Studio, und erstellen Sie das Projekt.

Excel-Arbeitsmappen werden deaktiviert, wenn in Visual Studio ein Excel-Anpassungsprojekt auf Dokumentebene geöffnet ist

Beim Öffnen von Excel 2007 und dem anschließenden Erstellen eines Excel 2007-Anpassungsprojekts auf Dokumentebene in Visual Studio antwortet die zuerst geöffnete Arbeitsmappe nicht mehr.

Klicken Sie zum Behandeln dieses Problems auf die Arbeitsmappe, die im Visual Studio-Designer angezeigt wird. Die geöffnete Arbeitsmappe beginnt zu antworten.

Siehe auch

Freigeben über