Warum NetOffice?                                                                                            english | deutsch

Die herkömlichen Methoden für den Zugriff auf Microsoft Office in .NET sind die Primary Interop Assemblies und VSTO. Beide Zugriffsmethoden beinhalten jedoch verschiedene Nachteile.

  • sie funktionieren nur mit einer oder bestimmten Office Versionen 
  • sie verursachen Probleme bei der Weitergabe bzw. Installation auf anderen Systemen 
  • sie bieten keinen Schutzmechanismus bei der Verwaltung von COM Proxies

NetOffice eliminiert diese Nachteile und bleibt dabei ein 1:1 Wrapper der syntaktisch und semantisch identisch zu den Interop Assemblies ist.


Wie funktioniert NetOffice?

NetOffice verwendet für den Zugriff ausschliesslich LateBinding Calls via COM Interop, ohne jedoch den Komfort und Einfachheit von EarlyBind Aufrufen einzubüßen. Durch die schlanke Architektur und effizientes Design ist dieser Weg nur sehr geringfügig langsamer als sogenannte EarlyBind Aufrufe in .NET(max 10%). Events werden in NetOffice über eine Technik realisiert die der Autor Dynamic EarlyBinding nennt. Mehr dazu in der technischen Dokumentation.

NetOffice beinhaltet 16 Assemblies. Warum und welche Assemblies brauche ich für meine gewünschte Office Anwendung?

Alle Office Anwendungen benutzen Typen die in anderen Komponenten/Typenbibliotheken definiert sind. Diese abhängigen TypenBibliotheken liegen daher als eigenständiges Assembly bei. Jedes Assembly benötigt darüber hinaus die NetOffice.dll Assembly. Eine Übersicht welche Office Anwendung welche zusätzlichen Assemblies einbindet finden Sie hier.

Deployment Table:

Office Anwendung Abhängigkeiten
ExcelApi.dll
OfficeApi.dll
VBIDEApi.dll
NetOffice.dll
WordApi.dll
OfficeApi.dll
VBIDEApi.dll
NetOffice.dll
OutlookApi.dll
OfficeApi.dll
NetOffice.dll
PowerPointApi.dll
OfficeApi.dll
VBIDEApi.dll
NetOffice.dll
AccessApi.dll
OfficeApi.dll
DAOApi.dll
VBIDEApi.dll
ADODBApi.dll
OWC10Api.dll
MSDATASRCApi.dll
MSComctlLibApi.dll
NetOffice.dll
MSProjectApi.dll
OfficeApi.dll
MSHTMLApi.dll
NetOffice.dll
VisioApi.dll
NetOffice.dll



Was muss ich tun um NetOffice mit meiner Anwendung auszuliefern?

Nichts, ausser die benötigten Assemblies auf das Zielsystem zu kopieren. Es ist keine Registrierung oder ähnliches notwendig. Falls Sie ein COM Addin erstellen möchten, muss dieses jedoch auf dem Zielsystem für COM registriert werden. In vielen Setup Projekten, z.B. Windows Installer oder InstallShield, können Sie die Registrierung Ihres COM Addins automatisch vornehmen lassen. Visual Studio erledigt diese Registrierung autmatisch für Sie während des kompilierens wenn Sie die Option 'Register for COM Interop' aktivieren.


COM Addins funktionieren ebenfalls versionsunabhängig?

Ja, dies ist eine besondere Stärke von NetOffice. Beispiele dazu für alle Office Anwendungen finden Sie unter den Projektbeispielen. Sie müssen jedoch möglicherweise 2 Versionen Ihres COM Addins zur Verfügung stellen wenn Sie 32 Bit und 64 Bit Office Anwendungen unterstützen möchten.


Funktioniert NetOffice auf verschiedenen Plattformen(32/64 Bit)?

Sie können in allen Szenarien die NetOffice AnyCPU Assemblies verwenden, unabhängig davon ob Sie für eine 32Bit Office Anwendung oder eine 64 Bit Office Anwendung entwickeln, auch unabhängig davon auf welcher Platform diese installiert ist. Ein weiterer Vorteil zu den Interop Assemblies oder VSTO bei denen Sie plattformspezifische Binaries verwenden müssen.


Hinweis für die plattformunabhängige Entwicklung

Wenn ihr Assembly eine Standalone Anwendung(.exe) ist oder von einer solchen geladen wird können Sie Ihr erstelltes Assembly bedenkenlos als AnyCPU kompilieren. Wenn Ihr Assembly ein COMAddin ist das von einer Office 32 Bit Anwendung geladen wird können Sie Ihr erstelltes Assembly ebenfalls als AnyCPU kompilieren.

Wenn Sie ein COMAddin entwickeln das von einer Office 64Bit Anwendung geladen wird müssen Sie ihr Assembly als x64 kompilieren. Fallweise müssen Sie ein zweites x64 kompiliertes COMAddin zur Verfügung stellen wenn Sie 32Bit und 64Bit Office Anwendungen unterstützen möchten. Anmerkung: Egal ob Sie NetOffice, die Interop Assemblies oder VSTO verwenden müssen Sie ein COMAddin für 64Bit Office Anwendungen immer als x64 kompilieren da eine 64Bit Anwendung nur 64Bit Dll's laden kann. Sofern Sie auf Ihrem Entwicklungssystem ein 64Bit Office zum Test verwenden und ein COMAddin entwickeln(d.h. Ihr Assembly als x64 kompilieren) und ihr COMAddin während der Kompilierung registrieren wollen(Register for COM Interop) müssen Sie beachten das manche Visual Studio Versionen in diesem Fall leider die die 32Bit Registrierung aufrufen und Sie den folgenden Fehler erhalten.

"File <path to assembly> is not a valid assembly".
Einen Workarround von Microsoft lesen Sie dazu hier:
http://support.microsoft.com/kb/956933


Wie migriere ich meine Interop Assembly oder VBA Lösung zu NetOffice?

Für Interop Lösungen
: Ändern Sie die Referenzen sowie du using bzw import Anweisungen. Fallweise müssen sie eine minimale Anpassung beim abbonieren von Events vornehmen. Marshal.ReleaseComObject Aufrufe ersetzen Sie durch den Auruf der Methode Dispose das ihnen jedes Objekt in NetOffice bietet oder löschen die entsprechende Codezeile da NetOffice alle COM Proxies für Sie verwaltet. Lesen zu dazu bitte die technische Dokumentation: COM Proxy Management verstehen.

Für VBA Lösungen
: Entwickler die VBA Lösungen zu VB.NET und NetOffice portieren müssen beachten das VB.NET zwar syntaktisch sehr kompatibel zu VBA ist, jedoch auch konzeptionelle Unterschiede aufweist das für .NET unerfahrende Entwickler in jedem Fall zusätzlichen Lernaufwand bedeutet. Sofern Sie über gute Kentnisse in VBA und VB.NET verfügen werden Sie keine Probleme haben Ihre Lösung zu NetOffice zu migrieren. Patrick O'Beirne hat als unerfahrender .NET Entwickler eine VBA Lösung mit mehr als 13.000 Codezeilen zu NetOffice portiert und seine Erfahrungen dazu festgehalten. Dokument1: Migrating Excel VBA Add-in to VB.Net[1].docx  Dokument 2: Migrating Excel VBA Add-in to VB.Net[2].docx


COM Proxy Verwaltung

Wenn sie Office Anwendungen also COM Server via .NET ansprechen erhalten sie statt echter Objekte sogenannte COM Proxies. Um dem COM Server zu signalisieren das sie diesen nicht mehr benötigen müssen diesen mittels einer speziellen Funkion wieder freigeben. Dies gilt sowohl für VSTO als auch für die Interop Assemblies.

Aufgrund dieses Umstandes dürfen Sie hier deshalb keine Objekte implizit und keine Enumeratoren direkt verwenden da Sie diese später nicht mehr freigeben können. In anderen Worten, sie müssen den Enumerator einer Instanz zuerst in einer lokalen Variale speichern um diesen später wieder freigeben zu können.

In NetOffice bietet Ihnen jedes Objekt die Methode Dispose() wenn sie es nicht mehr benötigen. Alle Klassen in NetOffice implementieren das IDisposable Interface und bieten darüber die Methode Dispose() an. Sie müssen jedoch nicht für jedes verwendetes Objekt Dispose() aufrufen und dürfen auch Objekte implizit und Enumerator direkt verwenden ohne sich um die Freigabe sorgen zu müssen. NetOffice speichert erzeugte Proxies in einer eigenen Tabelle und gibt diese frei wenn sie es festlegen oder ein übergeordnetes Objekt freigegeben wird. Mehr dazu in der
technischen Dokumentation und Tutorial01.

Unbekannte und variante Typen 

Viele Office Anwendungen beinhalten Properties, Rückgabewerte oder Parameter deren Typ zur Entwicklungszeit nicht feststeht und sich zur Laufzeit je nach Context ändern kann. Hier wird unterschieden zwischen unbekannten COM Proxies und dem Datentyp Variant der seine Wurzeln in Visual Basic for Applications(VBA) hat.

Unbekannte COM Proxies werden in NetOffice durch den Typ object representiert. Sie können einen anonymen COM Proxy jedoch zur Laufzeit problemlos in den tatsächlichen Typ umwandeln und als VB Entwickler das in der Sprache integrierte LateBinding Feature nutzen.
 
Der Datentyp Variant dient in VBA dazu zur Laufzeit jeden beliebigen Typ anzunehmen zu können sowohl einen COM Proxy als auch einen skalaren Datentyp wie bool oder int. In NetOffice wird ebenfalls der Typ Variant durch den Typ object ersetzt. Wenn ein Variant Property zur Laufzeit ein COM Proxy ist erhalten Sie ein Objekt der entsprechenden NetOffice Wrapper Klasse andernfalls den entsprechenden skalaren Datentyp. Mehr dazu in der
technischen Dokumentation und Tutorial06.


Wenn NetOffice alle Office Versionen unterstützt, wie erkenne ich welche Office Version welche Funktionalität anbietet?
 

Alle Klassen,Properties, Methoden, Enums etc. sind mit XML Dokumenation und einem speziellen Attribut ausgestattet das aufzeigt welche OfficeVersion(en) diese Entität unterstützen. Sie bekommen diese Information zur Entwicklungszeit auch im IntelliSense angezeigt. Darüber hinaus ist es möglich ein erstelltes Assembly das NetOffice verwendet mit der
NetOffice.DeveloperToolbox darauf zu prüfen welche Office Versionen es faktisch verwendet. Nutzen Sie diese Möglichkeit bevor Sie ihr Assembly ausliefern um sicher zu stellen das ihr Programm mit den Office Versionen funktioniert die sie(oder ihr Kunde) festgelegt haben.
 
Screenshot: IntelliSense Unterstützung in C# für Versionsinformation eines Property.
IntelliSenseCSharp

Last edited May 14, 2012 at 2:41 AM by SebastianDotNet, version 100

Comments

No comments yet.