Outlook erweitern
NET und Sicherheit
Wie bereits in den vergangenen Teilen dargestellt wurde, ist Office zum heutigen Zeitpunkt eine komplett auf Unmanaged Code basierende Anwendung, ohne jegliche Anpassung an .NET. Add-Ins werden deshalb auch nur als die COMKomponente wahrgenommen, die die IDTExtensibility2-Schnittstelle implementiert. Die dahinter liegenden .NET-Klassen sind für Office nicht sichtbar.
Bei Verwendung der mit Visual Studio .NET mitgelieferten generischen Add-In-Assistenten wird, wie beschrieben wurde, ein einziges Ladeprogramm für alle auf diese Weise erstellten Erweiterungen verwendet. Dies bedeutet aus dem Gesichtspunkt der Sicherheit heraus, dass Outlook sowie alle anderen Office-Anwendungen nur über das Ausführen dieses Ladeprogramms entscheiden können. Wenn es gestartet wird, werden alle damit verbundenen Add-Ins ausgeführt, oder keines. Die Makrosicherheitsstufen greifen für diese Art der Add-Ins nicht, da sich die einzelnen Module nicht voneinander trennen lassen. Um genau zu sein, müsste der allgemeine .NET-Laufzeitlader MSCOREE.DLL signiert werden, um ein solches Add-In als signiert erscheinen zu lassen. Da dies eine zentrale Systemkomponente ist, würde dies kaum Sinn machen, da die Signatur bei einer Aktualisierung des Systems verloren gehen kann, Zudem würde dies ein größeres Sicherheitsloch öffnen, da dann allen durch MSCOREE.DLL geladenen Komponenten automatisch vertraut würde.
Bei Verwendung von Shims sieht es wiederum anders aus. Hier stellt jede individuelle Shim das Add-In aus Sicht von Office dar. Entsprechend lassen sich die einzelnen Shims signieren und individuell freigeben. In diesem Fall besitzt der Entwickler auch die Kontrolle über das Ladeprogramm, was bei der generischen Laderoutine nicht der Fall war. Da Shims nicht offiziell unterstützt werden, ist auch dieser Weg eher eine Notlösung.
Add-Ins, die mit VSTO 2005 erstellt wurden, besitzen ebenfalls ein eigenes Ladeprogramm. Dieses ist bereits mit einem Authenticode-Zertifikat von Microsoft signiert, so dass diese Add-Ins auch in den Sicherheitsstufen Hoch und Sehr hoch ausgeführt werden können. Gleichzeitig findet in diesen Add-Ins aber auch die .NET-interne Code Based Security Anwendung. Hierdurch lassen sich über .NET-Systemrichtlinien Ausführungsbeschränkungen festlegen. Den Add-Ins muss zur korrekten Ausführung das Privileg Full-Trust zugewiesen werden, was allerdings standardmäßig der Fall ist.
Mit Office 12 wird wahrscheinlich die erste Office-Version auf den Markt kommen, die zwar weiterhin im Wesentlichen auf Unmanaged Code beruht, deren Design aber auf die Existenz von .NET ausgelegt ist. Wie sich das in der Praxis auswirken wird, ob es beispielsweise eine direkte Schnittstelle für .NET-Add-Ins geben wird und wie die .NET-Sicherheitsarchitektur unterstützt wird, kann aber endgültig erst die veröffentlichte Version zeigen. Auf der anderen Seite werden die hier beschriebenen Schnittstellen bis auf weiteres unterstützt werden, so dass eine Entwicklung mit VSTO 2005 auch heute noch sinnvoll ist.
Zusammenfassung
In den vier Teilen dieser Serie wurde eine kurze Einführung in die Technologie der Outlook-Add-Ins gegeben. Bei der Erstellung von Client-Erweiterungen wirkt vor allem die komplexe Struktur der COM-Schnittstelle IDTExtensibility2 abschreckend. Zudem kamen in der Vergangenheit eine Reihe von technischen Problemen der Schnittstellen und Applikationen hinzu, die diese Art der Entwicklung zu einer Expertendisziplin machte. Die Einführung von .NET-basierten Add-Ins hat die Situation zunächst auch nicht verbessert.
Mit der Veröffentlichung der Visual Studio Tools für Office 2005 hat sich nun allerdings einiges getan. Zwar lassen sich hiermit ohne Programmierkenntnisse immer noch keine fertigen Add-Ins schaffen, aber der dort enthaltene Assistent löst die bekannten Probleme und reduziert gleichzeitig die Komplexität der IDTExtensibility2-Schnittstelle durch eine eigene einfachere Basisklasse. Zudem lassen sich durch mit VSTO entwickelte Add-Ins nun auch die Sicherheitsstufen von Office sinnvoll einsetzen.
Grundsätzlich unterscheidet sich der in Add-Ins notwendige Code vom technischen Anspruch nur wenig von dem in VBA-Makros. Die Integration in Visual Studio macht die Entwicklung in manchen Belangen sogar komfortabler als diejenige im Visual Basic-Makro-Editor. Mit VSTO sollte damit die Hürde, Add-Ins zu entwickeln, auch für weniger erfahrene Entwickler deutlich gesenkt sein. Für professionelle Entwickler ist es nun deutlich einfacher geworden, stabilen und wartbaren Code zu erstellen.
|
Objekt |
Eingeschränkte Eigenschaften |
Eingeschränkte Methoden |
|
Action |
Execute | |
|
AddressEntries |
Alle |
Alle |
|
AddressEntry |
Alle |
Alle |
|
AppointmentItem |
Body, Organizer, RequiredAttendees, |
Respond, SaveAs, Send |
|
ContactItem |
Body, Email1Address, Email1AddressType, |
SaveAs |
|
DistListItem |
Body |
GetMember, SaveAs |
|
Inspector |
HTMLEditor, WordEditor |
|
|
ItemProperties |
Für jede eingeschränkte Eigenschaft |
|
|
JournalItem |
Body, ContactNames |
SaveAs |
|
MailItem |
Body, HTMLBody, SenderEmailAddress, |
SaveAs, Send |
|
MeetingItem |
Body, SenderName |
SaveAs |
|
NameSpace |
CurrentUser, GetRecipientFromID |
|
|
PostItem |
Body, HTMLBody, SenderName |
SaveAs |
|
Recipient |
Alle |
Alle |
|
Recipients |
Alle |
Alle |
|
TaskItem |
Body, ContactNames, Contacts, Delegator, |
|
|
UserProperties |
Find | |
|
UserProperty |
Formula |