Erstellen von Office-Lösungen

Im Allgemeinen entspricht das Erstellen und Debuggen von Office-Projekten dem Erstellen und Debuggen anderer Projekttypen in Visual Studio, z. B. Windows Forms. In den Themen in diesem Abschnitt werden die Unterschiede erläutert, die vorhanden sind. Allgemeine Informationen zum Erstellen von Anwendungen finden Sie unter Kompilieren und Erstellen in Visual Studio.

Projektausgabe für Office-Projekte

Der Ausgabespeicherort für Office-Projekte ist Projektname\bin\release oder Projektname\bin\debug. Sie können nicht in ein Bereitstellungsverzeichnis bauen.

Projekte auf Dokumentebene

Wenn Sie ein Projekt auf Dokumentebene erstellen, sind die folgenden Elemente in der Projektausgabe enthalten:

• Eine Kopie des Projektdokuments.

• Die Projektassembly und alle assemblys, auf die verwiesen wird, deren Eigenschaft "Lokal kopieren " auf "true" festgelegt ist.

• Das Anwendungsmanifest mit der Dateinamenerweiterung .manifest. Weitere Informationen finden Sie unter Anwendungsmanifesten für Office-Lösungen.

• Das Bereitstellungsmanifest mit der Dateinamenerweiterung VSTO. Weitere Informationen finden Sie unter Bereitstellungsmanifesten für Office-Lösungen.

• Eine Programmdatenbankdatei (PDB).

Projekte auf Anwendungsebene

Wenn Sie ein VSTO-Add-In-Projekt erstellen, sind die folgenden Elemente in der Projektausgabe enthalten:

• Die Projektassembly und alle assemblys, auf die verwiesen wird, deren Eigenschaft "Lokal kopieren " auf "true" festgelegt ist.

• Das Anwendungsmanifest mit der Dateinamenerweiterung .manifest. Weitere Informationen finden Sie unter Anwendungsmanifesten für Office-Lösungen.

• Das Bereitstellungsmanifest mit der Dateinamenerweiterung VSTO. Weitere Informationen finden Sie unter Bereitstellungsmanifesten für Office-Lösungen.

• Eine Programmdatenbankdatei (PDB) für eine Projektzusammenstellung.

  Der Buildprozess für VSTO-Add-In-Projekte erstellt außerdem eine Reihe von Registrierungseinträgen auf dem Entwicklungscomputer, die zum Laden des VSTO-Add-Ins erforderlich sind. Weitere Informationen finden Sie unter Registrierungseinträge für VSTO-Add-Ins.

  Wenn Sie ein Outlook VSTO-Add-In-Projekt erstellen, das Formularbereiche enthält, fügt der Buildprozess der Registrierung die folgenden zusätzlichen Informationen hinzu:

• Ein Schlüssel für jede Nachrichtenklasse, die einem oder mehreren Formularbereichen zugeordnet ist.

• Ein Eintrag für jeden Formularbereich und einen zugeordneten Wert, der den Namen des Outlook VSTO-Add-Ins darstellt.

  Outlook benötigt diese Informationen, um die Formularbereiche zu laden.

Referenzierte Assemblys

Sie können auf Assemblys (einschließlich Klassenbibliotheksprojekte) aus Ihrem Projekt "Office-Lösungen erstellen" verweisen. Jede referenzierte Assembly weist eine Eigenschaft namens "Lokal kopieren" auf. "Lokal kopieren" gibt an, ob die Assembly in das Ausgabeverzeichnis kopiert wird. Standardmäßig ist sie auf "true" festgelegt. Jede referenzierte Assembly, bei denen „Lokal kopieren“ auf „true“ festgelegt ist, wird in den Ausgabeverzeichnis kopiert.

Sicherheit während des Buildprozesses

Visual Studio konfiguriert automatisch die Sicherheitseinstellungen auf dem Entwicklungscomputer, um der Lösung während des Buildprozesses vertrauen zu können. Dadurch kann die Lösung ausgeführt werden, während Sie sie debuggen.

Office-Projekte verwenden Zertifikate, um den Herausgeber zu überprüfen. Visual Studio erstellt automatisch ein temporäres Zertifikat zum Identifizieren von Office-Lösungen und konfiguriert den Entwicklungscomputer so, dass dem temporären Zertifikat vertraut wird.

Weitere Informationen finden Sie unter Secure Office solutions.

Netzwerkprojekte

Wenn sich die Assembly oder der Dokumentspeicherort in einer Netzwerkfreigabe befindet, reicht das Sicherheitsrichtlinien-Update auf lokaler Ebene (Benutzerebene) nicht aus, um die Ausführung der Lösung zu ermöglichen. Ein Administrator muss Assemblys und Dokumenten, die sich in einer Netzwerkfreigabe befinden, auf Maschinenebene volle Vertrauenswürdigkeit gewähren, bevor die Lösung ausgeführt werden kann. Weitere Informationen zum Festlegen von Sicherheitsrichtlinien finden Sie unter Secure Office-Lösungen.

Bei Projekten auf Dokumentebene müssen Sie auch den vollqualifizierten Speicherort des Dokuments zur Liste der vertrauenswürdigen Office-Ordner hinzufügen. Weitere Informationen finden Sie unter Vertrauen zu Dokumenten gewähren.

Ändern des Plattformziels

Standardmäßig ist das Plattformziel für Office-Projekte "Any CPU". In der Regel sollten Sie diese Einstellung nicht ändern. Office-Lösungen, die mit der Zieleinstellung "Beliebige CPU-Plattform " erstellt wurden, werden in 32-Bit- und 64-Bit-Versionen von Microsoft Office 2013 oder Office 2010 ausgeführt.

Sie sollten das Plattformziel nur auf x64 festlegen, wenn Sie eine Lösung erstellen, die nur in 64-Bit-Versionen von Microsoft Office 2013 oder Office 2010 ausgeführt wird, und Ihre Lösung systemeigene 64-Bit-APIs aufruft. Weitere Informationen zum Ändern der Plattformzieleinstellung finden Sie unter How to: Configure projects to target platforms.

Wenn Sie das Plattformziel auf x64 festlegen, wird die Lösung nicht in 32-Bit-Versionen von Windows oder Office ausgeführt. Für das x64-Plattformziel muss die Lösung in einem 64-Bit-Prozess ausgeführt werden.

Verwenden Sie den Befehl "Bereinigen"

Um die erstellten Projektdateien vom Entwicklungscomputer zu entfernen, können Sie den Befehl "Bereinigen" im Menü " Erstellen " in Visual Studio verwenden. Der Befehl "Bereinigen" löscht alle Dateien am Build-Ausgabeort. Bei Projekten auf Anwendungsebene entfernt der Befehl " Bereinigen " auch die Registrierungseinträge, die vom Buildprozess erstellt werden.

Zugehörige Themen