Entwerfen und Erstellen von Office-Lösungen

  • Artikel

Visual Studio stellt Projektvorlagen bereit, mit denen Sie mehrere unterschiedliche Typen von Office-Projektmappen erstellen können. In diesem Abschnitt der Dokumentation werden die Projektvorlagen beschrieben und Anweisungen zum Erstellen von Office-Projekten bereitgestellt. Informationen zum Implementieren von Code- und Benutzeroberflächenanpassungen, nachdem Sie Ihr Projekt erstellt haben, finden Sie unter Entwickeln von Office-Lösungen.

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.

Erstellen von Office-Projekten

Bevor Sie beginnen, sollten Sie die Anforderungen bestimmen und den am besten geeigneten Lösungstyp festlegen. Wenn die Office-Projektmappe z. B. bei jeder Verwendung der Anwendung ausgeführt werden muss, ist ein VSTO-Add-In die beste Lösung für Ihre Anforderungen. Wenn der Code fest in ein einzelnes Dokument integriert ist, erstellen Sie eine Anpassung auf Dokumentebene. Diese Projekttypen sind als Visual Studio-Projektvorlagen verfügbar. Weitere Informationen zu den Office-Projektvorlagen, die in Visual Studio enthalten sind, finden Sie in der Übersicht über Office-Projektvorlagen. Weitere Informationen zum Erstellen von Office-Projekten finden Sie unter How to: Create Office projects in Visual Studio.

Office-Projekte enthalten Funktionen und Projektelemente, die sich von anderen Projekttypen in Visual Studio unterscheiden. Wenn Sie z. B. ein Projekt auf Dokumentebene erstellen, kann das Dokument oder die Arbeitsmappe im Projekt in Visual Studio geöffnet und bearbeitet werden. Weitere Informationen finden Sie unter Office-Projekte in der Visual Studio-Umgebung.

Auswählen einer .NET Framework-Version

Nachdem Sie den für Ihre Anforderungen am besten geeigneten Projekttyp ausgewählt haben, können Sie festlegen, welche .NET Framework-Version bei der Entwicklung verwendet werden soll. In Office-Projekten können die folgenden .NET Framework-Versionen verwendet werden:

  • .NET Framework 4

  • .NET Framework 4 Client Profile

  • .NET Framework 4.5

    Die .NET Framework-Version, die Sie für Ihr Projekt auswählen, ist auf Endbenutzercomputern erforderlich, damit Ihre Lösung ausgeführt werden kann. Wenn Ihr Projekt beispielsweise auf .NET Framework 4 ausgerichtet ist, ist .NET Framework 4 auf Endbenutzercomputern erforderlich. In diesem Beispiel wird Ihre Lösung nicht ausgeführt, wenn nur .NET Framework 3.5 auf Endbenutzercomputern installiert ist.

    Wenn Sie ein VSTO-Add-In-Projekt migrieren, das auf .NET Framework 3.5 ausgerichtet ist, ändert Visual Studio das Zielframework Ihres Projekts je nach installierter Office-Version in .NET Framework 4 oder höher.

    Nachdem das Zielframework von Visual Studio geändert wurde, müssen Sie jedoch möglicherweise einen Teil des Codes im Projekt ändern, wenn es bestimmte Funktionen verwendet. Weitere Informationen zum Ändern des Zielframeworks finden Sie unter How to: Target a version of the .NET Framework. Weitere Informationen zu Änderungen, die Sie möglicherweise in Ihrem Projekt vornehmen müssen, finden Sie unter Migrieren von Office-Lösungen zu .NET Framework 4 oder höher.

    Wenn Visual Studio das Ziel .NET Framework für Ihr Projekt ändert und Sie ClickOnce zum Bereitstellen Ihrer Lösung verwenden, stellen Sie sicher, dass Sie auch die entsprechende Version von .NET Framework im Dialogfeld "Voraussetzungen " auswählen. Diese Auswahl wird nicht automatisch geändert, wenn Sie das Zielframework für das Projekt ändern. Weitere Informationen finden Sie unter How to: Install prerequisites on end-user computers to run Office solutions.

Hinweis

Sie können nicht auf .NET Framework 3.5 oder früher in Office-Projekten abzielen, die Sie mit Visual Studio 2013 erstellen. Office-Projekte, die Sie mit Visual Studio 2013 erstellen, erfordern Features, die zuerst in .NET Framework 4-Clientprofil eingeführt wurden

Verstehen, wann die Office-PIAs auf Endbenutzercomputern erforderlich sind

Standardmäßig müssen primäre Interopassemblys (PIAs) von Office nicht auf Endbenutzercomputern installiert werden, wenn die Eigenschaft "Interop-Typen einbetten" jeder Office PIA-Referenz im Projekt auf "True" festgelegt ist. Dies ist der Standardwert. In diesem Szenario werden die in der Projektmappe für die PIA-Typen verwendeten Typinformationen beim Erstellen des Projekts in die Projektmappenassembly eingebettet. Zur Laufzeit werden die eingebetteten Typinformationen anstelle der PIAs verwendet, um das COM-basierte Objektmodell der Office-App lizenzierung aufzurufen. Weitere Informationen dazu, wie Typen von PIAs in Ihre Lösung eingebettet werden, finden Sie unter Type equivalence and embedded interop types.

Wenn die Eigenschaft "Interoptypen einbetten" jeder Office PIA-Referenz im Projekt auf "False" festgelegt ist, müssen Office-PIAs im globalen Assemblycache auf jedem Endbenutzercomputer installiert und registriert werden, auf dem die Lösung ausgeführt wird. In den meisten Fällen werden die PIAs standardmäßig mit Office installiert, Sie können die verteilbare PIA jedoch auch als erforderliche Komponente für die Lösung einschließen. Weitere Informationen finden Sie unter voraussetzungen für die Bereitstellung von Office-Lösungen.

Grundlegendes zum Clientprofil

.NET Framework Client Profile ist eine Teilmenge der Vollversion von .NET Framework. Sie können .NET Framework Client Profile verwenden, wenn nur die Clientfunktionen in .NET Framework verwendet werden müssen und die schnellstmögliche Bereitstellung für die Office-Lösung angegeben werden soll. Weitere Informationen finden Sie unter .NET Framework-Clientprofil.

Wenn Sie ein Office-Projekt erstellen, das auf .NET Framework 4 ausgerichtet ist, ist das .NET Framework 4-Clientprofil standardmäßig ausgerichtet. Wenn Sie für das vollständige .NET Framework 4 entwickeln möchten, müssen Sie diese Option festlegen, nachdem das Projekt erstellt wurde. Weitere Informationen finden Sie unter Vorgehensweise: .NET Framework-Version als Ziel.

Erstellen von Lösungen für die 64-Bit-Edition von Microsoft Office

Microsoft Office ist in 64-Bit- und 32-Bit-Editionen verfügbar. Um Office-Lösungen zu erstellen, die in beiden Editionen ausgeführt werden können, muss die Plattformzieleinstellung für Ihr Projekt auf "Beliebige CPU" festgelegt sein. Dies ist der Standardwert für Office-Projekte. Weitere Informationen finden Sie unter Erstellen von Office-Lösungen.

Es gibt separate 64-Bit- und 32-Bit-Versionen der Visual Studio-Tools für Office-Laufzeit, die von den 64-Bit- und 32-Bit-Editionen von Microsoft Office verwendet werden. Weitere Informationen finden Sie unter Visual Studio-Tools übersicht über die Office-Laufzeit.

Assemblys in Office-Lösungen

Wenn Sie mit den Office-Entwicklungstools in Visual Studio ein Office-Projekt erstellen, wird der Code, den Sie schreiben, schließlich in eine Assembly kompiliert. Die Assembly wird auf einem freigegebenen Server oder in einem Verzeichnis auf dem Clientcomputer bereitgestellt.

Assemblys in Office-Projektmappen werden von einer Office-Anwendung geladen. Nach dem Laden der Assembly kann Code in der Assembly auf Ereignisse reagieren, die in der Anwendung ausgelöst werden, z. B. wenn ein Benutzer auf ein Menüelement klickt. Code in der Assembly kann auch das Objektmodell aufrufen, um die Anwendung zu automatisieren und zu erweitern, und sie kann jede der Klassen in .NET Framework verwenden. Weitere Informationen finden Sie unter Architektur von Anpassungen auf Dokumentebene und Architektur von VSTO-Add-Ins.

Office-Lösungen identifizieren die Assembly mithilfe von Bereitstellungsmanifesten und Anwendungsmanifesten. Die Manifeste enthalten Informationen über Name, Version und Speicherort der Assembly, sodass die Anwendung die richtige Assembly suchen, eine Verbindung mit dieser herstellen und diese ausführen kann. Weitere Informationen finden Sie unter Anwendungs- und Bereitstellungsmanifesten in Office-Lösungen.

Projekte auf Dokumentebene enthalten zusätzlich zu einer Assembly ein Dokument. Das Dokument bildet das Front-End der Anwendung, in dem alle Benutzerinteraktionen stattfinden. Jedes Dokument kann nur mit einer Hauptprojektassembly verknüpft sein, es können jedoch mehrere Dokumente auf dieselbe Assembly verweisen.

Assemblys in Projekten auf Dokumentebene sind nicht im Dokument eingebettet, sondern werden an anderer Stelle gespeichert und durch das Anwendungsmanifest des Dokuments identifiziert.

Sicherheitsüberlegungen für Assemblys

Damit eine Office-Lösung auf einem Computer ausgeführt werden kann, müssen die von der Lösung verwendeten Assemblys als vertrauenswürdig gelten, um ausgeführt zu werden. Weitere Informationen zur Sicherheit finden Sie unter Secure Office Solutions.

Standardmäßig gelten die Projektmappenassembly und alle Assemblys, auf die verwiesen wird und die sich im Ausgabeordner des Projekts befinden, als vertrauenswürdig, um beim Erstellen des Projekts auf dem Entwicklungscomputer ausgeführt zu werden. Weitere Informationen finden Sie unter Erstellen von Office-Lösungen.

Aus Sicherheitsgründen empfiehlt es sich, Projekte auf dem lokalen Computer und nicht in einem freigegebenen Speicherort zu erstellen. Weitere Informationen finden Sie unter collaborative development of Office solutions.

Assemblys, auf die verwiesen wird

Eine Assembly kann auf andere Assemblys verweisen, die in den Verweisen des Projekts aufgelistet sind. Eine Assembly in einem Projekt auf Dokumentebene kann jedoch auf keine andere Assembly in einem Projekt auf Dokumentebene verweisen.

Zugehöriger Inhalt