Aus meiner eigenen Erfahrung:
Wenn Sie auf Office 2003 und höher abzielen wollen, verwenden Sie die Office 2003 PIAs und beschränken sich auf die Office 2003 API. Der Code würde unter Office 2003 laufen oder später . Sie können zwar immer noch Office 2007-Funktionen mit Reflection aufrufen, aber das ist nicht angenehm.
Ich kann mir vorstellen, dass es ähnlich ist, wenn Ihre Basisversion Office 2000 ist - obwohl ich es nicht ausprobiert habe, und ich glaube, die früheste Version, für die Microsoft selbst PIAs anbietet, ist Office 2002 (XP).
Sie können Ihre eigenen Interop-Assemblies für 2000 erstellen, und ich habe keinen Grund anzunehmen, dass Sie das nicht auch für '95 tun können, obwohl Sie der erste sind, den ich je nach '95-Unterstützung fragen sehe! Wenn Sie Ihre eigenen Interop-Assemblies erstellen, müssen Sie sie natürlich zusammen mit Ihrer Anwendung bereitstellen.
In jedem Fall sollten Sie die höchste Office-Version, mit der Sie als Basisversion auskommen, so dass Sie so viele Funktionen wie möglich unterstützen können, ohne auf Reflection zurückzugreifen. Sie sollten Ihren Code auf einem Rechner entwickeln, der über sólo diese Version von Office installiert.
In meinem Fall entwickle ich für Office 2003 und weiß, dass meine Benutzer auch 2003 haben. Also bitte ich sie, sicherzustellen, dass sie die Funktion ".NET Programmability Support" aktiviert haben (was Sie über Office 2003 Setup über Software tun können, wenn Sie die Option Ändern wählen). Mit dieser Option werden die PIAs grundsätzlich in der GAC installiert. Für die Benutzer, die dies nicht tun können, erkennt mein Setup-Programm das Fehlen der PIAs und installiert sie vor der Installation meiner Anwendung (wie es für das .NET-Framework geschieht).
XCOPY-Einsatz? Ja, das würde ich auch gerne - aber vergessen Sie es. Wenn Ihr Add-In im Hochsicherheitsmodus arbeiten soll, brauchen Sie eine vom Code signierte COM-"Zwischenschicht" zwischen Ihrem Code und Office, und die muss registriert werden. Ich glaube, VSTO bietet ein eigenes Shim an, wenn Sie sich für diesen Weg entscheiden (ich habe es nicht getan, da ich in der Lage sein musste, Office von Grund auf zu "steuern", anstatt mich darauf zu verlassen, dass der Benutzer die Anwendung startet).
Die Bereitstellung - und der Umgang mit den Installations- und Sicherheitsproblemen - ist einer der schwierigsten Teile der Entwicklung von Office-Add-Ins mit .NET, und es ist ein echter Knaller, dass er genau am Ende kommt, wenn Sie dachten, Sie wären fertig.
Mon stark raten wir Ihnen, sich Tage und Wochen des Ärgers zu ersparen und sich Add-in Express . Ich bin selbst erst kürzlich darauf gestoßen und ärgere mich seitdem, weil ich damit so viel Zeit hätte sparen können. Es hat mehrere Vorteile, die meiner Meinung nach für Sie nützlich sein könnten:
- Es ermöglicht Ihnen, ein einziges Add-In für Office 2000 bis Office 2007 (leider nicht '95) zu erstellen, unabhängig davon, welche Version Sie auf Ihrem Entwicklungs-PC haben.
- Es erstellt ein Installationsprogramm für Sie (das sogar unter Vista funktioniert!), das an sich schon den Preis wert ist.
- Es wird mit einem eigenen COM-Shim geliefert und ist so weit integriert, dass Sie sich nicht darum kümmern müssen.
- Damit können Sie ein einzelnes Add-In erstellen, das in den Office-Versionen bis 2003 eine Menü-/Symbolleistenschnittstelle, in 2007 jedoch eine Multifunktionsleistenschnittstelle hat.
Bitte beachten Sie, dass ich in keiner Weise mit Add-in Express verbunden bin (außer als kürzlich erfolgter Kunde), aber ich habe auch meine Projekte noch nicht auf die Verwendung von Add-in Express umgestellt. Die ersten Tests, die ich durchgeführt habe, lassen mich glauben, dass es ziemlich gut ist - und definitiv der richtige Weg für kleine bis mittlere Projekte.
