Visual Studio 2005 Tools for Office での Outlook アドインサポートのアーキテクチャ

Visual Studio 2005 Tools for Office...

Andrew Whitechapel
Microsoft Corporation

June 2005
日本語版最終更新日 2005 年 12 月 6 日

適用対象:
    Microsoft Visual Studio 2005 Tool for the Microsoft Office System
    Microsoft Visual Studio 2005
    Microsoft Office Outlook 2003

概要 : Microsoft Office Outlook 2003 のマネージアドインの新サポートについて説明します。これは、Microsoft Visual Studio 2005 Tool for the Microsoft Office System で導入されたものです。

メモこの記事はリリース前のドキュメントであり、今後のリリースで変更される可能性があります。Visual Studio 2005 Tools for Office Beta 2 は、Microsoft Visual Studio 2005 Beta 2 に付属しています。Visual Studio 2005 Tools for Office Beta 2 用の Outlook アドインサポートのベータ版は、Microsoft Visual Studio 2005 Tools for the Microsoft Office System (Beta) として別途用意されているものをダウンロードすることができます。

はじめに

Microsoft Office System 用の Microsoft Visual Studio 2005 Tool (Visual Studio 2005 Tools for Office) は、マネージコードを使用する Microsoft Office Outlook 2003 用のアプリケーションレベルのアドインを作成するためのサポートを装備しています。それには、次のような設計時および実行時の両方のサポートも含まれます。

Visual Studio プロジェクトテンプレート。これは、Outlook アドインとアドインセットアッププロジェクトの構築に役立ちます。
専用のアドインローダーコンポーネント (AddinLoader)。これは、各アドインごとに別々の AppDomain を作成し、厳格なセキュリティポリシーを実施し、切断されたアドインをアンロードします。

AddinLoader コンポーネントは、Visual Studio 2005 Tools for Office ランタイムエンジンを使用します。それによって、文書レベルのカスタマイズとアプリケーションレベルのアドインの両方を読み込むための、単一の一貫性あるメカニズムが Microsoft Office アプリケーションに提供されます。最初は、強く型付けしたマネージアドインを作成して、それを高セキュリティ設定のもとで簡単に配置および実行することができます。

Outlook アドインソリューションをお使いになる前に

Microsoft Visual Studio 2005 には、Outlook アドインプロジェクトという新しいプロジェクトタイプが組み込まれています。 Microsoft Office Outlook アドインソリューションを作成して、Microsoft Visual Studio 2005 でそれがどのようになるかを見てみましょう。図 1 に示されているとおり、Microsoft Visual C# および Microsoft Visual Basic .NET のどちらでも、この新しいプロジェクトタイプは、[新しいプロジェクト] ダイアログボックス内の [Office] タブの下に置かれています。

図 1. [新しいプロジェクト] ダイアログボックス (クリックすると拡大表示されます)

このオプションを選択すると、Visual Studio によって次のような 2 つのプロジェクトがソリューション内に作成されます。

アドインプロジェクトには、アドインの開始コードが入っていて、そこにはアプリケーションマニフェストが入っています。
アドインの開発を完了し、それを配置したい場合に、セットアッププロジェクトを使用します。セットアッププロジェクトは Microsoft Installer (MSI) ファイルを作成します。このファイルは、レジストリ内にエントリを挿入し、ソリューションファイル (アセンブリおよびマニフェスト) を配置します。

アドインプロジェクトには、IStartup インターフェイスを実装するためのアドイン用のプライマリクラスが組み込まれています。部分的クラスを使用して、生成されたこのコードは、2 つのファイルに分かれるクラスで表わされます。それは、Visual Studio 2005 Tools for Office 文書のカスタマイズとの一貫性を保つためです。シンプルな「Hello World」アドイン用のアドインプロジェクトによって作成されるコードの例が、図 2 に示されています。

図 2. ThisApplication コード (クリックすると拡大表示されます)

Microsoft Office Word または Microsoft Office Excel 用の Visual Studio 2005 Tools for Office プロジェクトを作成すると、生成されるプライマリクラスは、文書またはワークシートを表します。 Outlook アドインの場合、プライマリクラスは Outlook アプリケーションを表します。なぜなら、このアドインは、文書レベルではなくアプリケーションレベルで稼動するからです。このクラスは、図 3 に示されているとおり、Outlook アプリケーションオブジェクトに対する非常に軽量なラッパーとして機能します。

ThisApplication IntelliSense

図 3. ThisApplication IntelliSense

図 2 を見てお分かりのとおり、プロジェクトウィザードはクラス内に 2 つのメソッドを生成します。それらは、アドインの入り口点および出口点となる予定の ThisApplication_Startup および ThisApplication_Shutdown です。これらは、カスタムコードに追加できる最初と最後の地点を表します。このシンプルなアドインを完成するために、ThisApplication_Startupメソッドに次のようなコードを追加します。

MessageBox.Show("Hello World");

ソリューションを作成および実行すると、Visual Studio は Outlook を起動し、Outlook はアドインを読み込みます。読み込みの完了直後に、アドインは [Hello World] メッセージボックスを表示します。気を付けていただきたいのは、Outlook がアドインを読み込むには、レジストリ情報と Microsoft .NET コードのアクセスセキュリティポリシーという、さらに別の 2 種類のデータも揃っていなければならないことです。開発の手間を合理化するために、Visual Studio ではソリューションの作成時にそれらのデータが追加されます。当然、ターゲットユーザーに対してアドインを配置するときは、セットアッププロジェクトを使用して、レジストリとコードアクセスセキュリティ情報を追加します。

メモコードアクセスセキュリティの詳細は、[HOWTO] アセンブリ制約のためにコードアクセスセキュリティポリシーを使用する方法を参照してください。

AddinLoader コンポーネントを設計した理由

多くのアプリケーション (特に、Office などの情報担当者の生産性アプリケーション) は、任意のやり方でカスタマイズまたは拡張できるように設計されます。ただし、Office の場合、カスタマイズに対して一連の標準インターフェイスが定義されています。もっともよく使用されるのは、IDTExtensibility2 です。エンドユーザーのソリューション開発者および独立ソフトウェア販売会社 (ISV) は、このインターフェイスを使用して、マネージコードまたはアンマネージコード内にアドインを実装します。そのときに、マネージコードを使用するケースがますます多くなっています。その理由は、Microsoft .NET Framework実行時ライブラリおよびクラスライブラリの機能が豊富であり、Visual Studio 2005 の開発実績が豊富であるからです。

Visual Studio 2005 Tools for Office の AddinLoader コンポーネントのリリース前は、以下の 3 種類の標準方式のうちの 1 つを使って、実行時に Office アプリケーションにマネージ拡張を読み込んでいました。

シムなし。 COM を使用して、マネージアドインを登録することができます (デフォルトどおりに、InprocServer32 鍵セットを、.NETベースの共通言語ランタイムエンジンである MSCorEE.dll に設定したままにします)。すると、ホストは、MSCorEE.dll を読み込んで、アドインの CLSID (クラス ID) を渡します。 MSCorEE.dll はレジストリを検査して、渡された CLSID のコードベース (アセンブリのパス) を見つけ出し、アドインをデフォルトの AppDomain に読み込みます。
単純 COM シム。管理者は、マネージアドインを登録する代わりに、各アドインごとにアンマネージシムコンポーネントを登録することができます。ホストがシムを読み込むと、そのシムは、自身の作成対象であったマネージアドインを読み込みます。レジストリには、そのシムのみに関する情報が保管されています。各アドインごとに、別々にシムを作成して登録する必要があります。
OTKLoadr。 Microsoft Office 2003 アプリケーションは、Microsoft Visual Studio Tools for the Microsoft Office System バージョン 2003 ローダー (OTKLoadr.dll) を使用して、Microsoft Visual Studio Tools for the Microsoft Office System バージョン 2003 のカスタマイズ、特定のマネージスマートタグ、およびマネージスマート文書を読み込みます。 OTKLoadr は、マネージアドインを読み込むために設計されたものではありません。
メモシムが組み込まれていないアドインを使用しないでください。その理由の説明と、Visual Studio 用の COM シムおよび COM シムウィザードの詳細は、Isolating Office Extensions with the COM Shim Wizard (英語) および Using the COM Add-in Shim Solution to Deploy Managed COM Add-ins in Office XP (英語) を参照してください。

どのアプローチにも、長所と短所があります。 Visual Studio 2005 Tools for Office の AddinLoader コンポーネントには、さまざまな利点 (これのみにとどまりません) が盛り込まれていて、これらのアプローチの短所を回避または解決します。

従来の Outlook アドインモデルの問題点

よく見ると、拡張を読み込む 3 つの標準方式にはいずれも制限事項が付帯しています。

シムなしの場合の不具合

大半のマネージ COM アドインは、Visual Studio で共有アドインプロジェクトタイプを使用して作成されています。そのため、MSCorEE.dll を使用するアドインの登録は、シムなしでセットアップされることになり、次のような深刻な問題を生じます。

マネージアドインは、シムの入っていない他のすべてのマネージアドイン (スマートタグおよびリアルタイムのデータコンポーネントも含む) と同じ AppDomain に読み込まれるので、他のアドインから分離したり単独でアンロードしたりできません。同じ AppDomain に読み込まれるために、別のアドインが正しく機能していないと、障害を生じやすくなります。 (たとえば、別のアドインが ReleaseComObject メソッドをループで呼び出すことがあります。)
同じ AppDomain 内のすべてのアドインは、同じセキュリティコンテキストを共有します。
シムを組み込まれていないマネージアドイン用のホストが読み込む登録済みのアドイン .DLL は、通常は、ブートストラップアプリケーションとして機能する .NET ベースの .DLL である MSCorEE.dll です。高セキュリティ　モードで稼動する Office ホストの場合、[マクロセキュリティ] ダイアログボックスの [インストールされたアドインとテンプレートをすべて信頼する] をクリアすると、登録済みのアドインの .DLL をデジタル署名するようにホストから要求されます。ただし、MSCorEE.dll に署名することはできません。 MSCorEE.dll は、すべてのマネージアドイン用の .DLL としてリストされるので、これに署名すると、すべてのマネージアドインは元来信頼してよいものとして以後は検査されなくなるので、セキュリティモデルは根底から覆されてしまいます。これで、管理者はジレンマに陥ります。すなわち、MSCorEE.dll には署名できないので、セキュリティレベルを中または低に引き下げるか、またはインストールされたアドインとテンプレートをすべて信頼するしかないからです。どちらのオプションも満足できるものではありません。

シムに対するデフォルトサポートはない

Visual Studio の COM シムウィザードおよびプロジェクトのセットを Microsoft からダウンロードし、これを使って、マネージアドイン用のアンマネージシムを作成することができます。このアプローチによって、シムを組み込まれていないマネージアドインでの問題の一部は解決されますが、次のようないくつかの問題点が残ります。

このアプローチは Microsoft ではサポートされていません。
このアプローチの場合、アンマネージシムコンポーネント以外に、インストール要件のそれぞれ異なる 1 つ以上のマネージコンポーネントを配置する必要があります。これによって、保守を担当する管理者 (および開発者) が混乱させられることがあります。
シム (ウィザード生成の) は C++ で書かれています。これは、必ずしもマネージアドインの開発者が慣れ親しんでいるとはかぎらない開発言語です。
このモデルでは、すべてのシムを通してコードの 99% 以上が同じであっても、各アドインごとにそれに関連付けられたシム DLL が必要です
シムは、IDTExtensibility2、ISmartTagRecognizer、ISmartTagAction、または IRtdServer を実装するアドインのみをサポートすることができます。他の種類のアドインに対してや、それらのインターフェイスを使用する予定のないホストに対して使用することはできません。

OTKLoadr に絶対的な重点を置く

OTKLoadr は、別個の AppDomains の作成において優れた働きをします。それによって、厳密なセキュリティポリシーが必ず守られるようにし、マネージ拡張の完全アンロードを行えるようにします。しかし OTKLoadr は、きわめて決まりきった用途で設計されたものです。その用途とは、Microsoft Visual Studio Tools for the Microsoft Office System バージョン 2003、文書レベルのカスタマイズ、マネージスマートタグ、およびマネージスマート文書を読み込むことです。すなわち、アドインを読み込むためのものではありません。

IDTExtensibility2 および Outlook アドインの問題点

Office アプリケーションは、長い間 IDTExtensibility2 インターフェイスをサポートしてきました。これは、Office においてアドインが実装しなければならないプライマリインターフェイスでした。 Office では、ISmartTagRecognizer、ISmartTagAction、ISmartDocument、および IRtdServer をはじめとする他の拡張インターフェイスもサポートされます。 Visual Studio 2005 Tools for Office の導入とともに、IStartup インターフェイスも Office で間接的にサポートされるようになりました。

複数の Office ホストが IDTExtensibility2 をサポートし、しかも複数のホストへの読み込みが可能な IDTExtensibility2 アドインを作成できる設計になっています。ですから、IDTExtensibility2 は強く型付けされたインターフェイスではありません。たとえば、OnConnection メソッドでは、ホストへの参照がアドインに渡されますが、その際、一般オブジェクトとして渡されます。ユーザーの責任のもとに、当然取得するはずの型に対してこのオブジェクトをキャストしてください。開発者によってはこの機能の利点が活かされますが、これは通常は資産というより債務とみなされます。このアプローチでの 1 つの問題として、アドインは必ずしも冗長機能を組み入れるとはかぎらないという点があります。アドインが、たとえば Word、Excel、および Outlook をターゲットとする場合に、Word で稼動すると、Excel および Outlook の独自のコードはすべて、通常は使用されません。

これに対して、Visual Studio 2005 Tools for Office モデルは強く型付けされています。 Visual Studio を使用して Visual Studio 2005 Tools for Office ソリューションを作成すると、Word または Excel に特有の開始コードがプロジェクトウィザードで生成されます。 Office ホストが Visual Studio 2005 Tools for Office のカスタマイズ内容を読み込むと、強く型付けされた Excel または Word のアプリケーションオブジェクトと、Excel ワークブックまたは Word 文書オブジェクトが、Visual Studio 2005 Tools for Office ランタイムから渡されます。このような強い型付けには、いくつかの利点があります。設計段階では、Microsoft IntelliSense およびオートコンプリートの利点を活かすことができ、定義済みの型に対して早期バインドするので、書くコード量が減ることを意味します。実行段階では、コードの冗長性が減少してメモリ使用量が改善し、コードパスの複雑さが緩和されてパフォーマンスが向上します。

別の考慮事項として、IDTExtensibility2 には 5 つのメソッドがあるという点があげられます。開発者は通常はそれらをすべては使用しないで、それらを 2 つのメソッドにまとめます。 Visual Studio 2005 Tools for Office の IStartup インターフェイスは、よりシンプルでしかもより合理化されたインターフェイスであり、開発者が通常必要とする 2 つのメソッドしか備えていません。表 1 と 2 は、開発者が IDTExtensibility2 をアドイン中に実装する通常の方法と、それらが IStartup にどのように対応するかを示しています。

表 1. アドインの読み込みメソッド

IDTExtensibility2 メソッド	通常の実装法	IStartup メソッド
OnConnection	通常、開発者は、ホストの始動中に OnConnection が呼び出されるかどうかをテストして判別します。他の時点で OnConnection が呼び出される場合、カスタム初期化メソッドを呼び出します。ホストの始動中に OnConnection が呼び出される場合、カスタム初期化メソッドは OnStartupComplete によって呼び出されます。	Startup
OnAddInsUpdate	始動中にアドインが追加または除去されるときに OnAddInsUpdate が呼び出されます (通常は複数回)。アドイン開発者が OnAddInsUpdate を使用するのはきわめてまれです。	(なし)
OnStartupComplete	通常、開発者は、このメソッドでは作業しません。すなわち、OnConnection において条件付きで呼び出されるのと同じカスタム初期化メソッドを代わりに呼び出します。	(なし)

表 2. アドインのアンロードメソッド

IDTExtensibility2 メソッド	通常の実装法	IStartup メソッド
OnBeginShutdown	OnBeginShutdown が呼び出されるのは、ホスト自身のシャットダウン時にホストがアドインの接続を切断する場合です。	(なし)
OnDisconnection	OnDisconnection が呼び出されるのは、アドインの切断時です。それは、ホストのシャットダウン中にアドインが切断されるときも含め、アドインがメモリからアンロードされる直前です。通常、開発者は、すべてのクリーンアップタスクをここで実行します。	Shutdown

これらの表から、5 つのメソッドのうちの 4 つを実装しても、通常は 2 つしか必要ないことが分かります。開発者が OnConnection と OnStartupComplete において同じタスクを実行して、アドインを初期化することがよくあります。また、OnBeginShutdown と OnDisconnection においても同じタスクを実行して、アドインのアンロード時のクリーンアップを行うこともよくあります。したがって、通常必要なのは、5 種類の別々の一連の動作ではなく、「始動」と「シャットダウン」の 2 つの動作だけです。

開発者によっては、2 種類より多い IDTExtensibility2 メソッドを使用しますが、そのような状況はまれです。 5 つの IDTExtensibility2 メソッドを使用する作業を開発者に強要することは、妥当とはいえません。通常はそのうちの 3 つは未使用のままになるからです。それよりも単純で分かりやすい IStartup インターフェイスに取り換えれば、開発者の生産性が向上し、アドインの設計が簡素化され、サポートおよび保守の手間が軽減されます。 AddinLoader コンポーネントは IDTExtensibility2 のプロキシを Office に設定し、2 つの使用メソッドを、IStartup アドインが実装する 2 つの IStartup メソッドにマップします。

Outlook アドインのアンロードの問題点

Outlook にはよく知られた変則的なアンロードアドインがあり、それによってアドインの開発がとりわけ困難になります。これは、Outlook チームにとって周知の問題ですが、慎重な検討の結果、修正するにはアプリケーション全体にわたって大幅な変更を加える必要があることも明らかになりました。　当然、それは甚大なリスクを伴い、開発者も依存している Outlook 内のプログラム可能環境の他の局面も被害を被る可能性があります。この問題によって影響を受けるユーザーシナリオの数は比較的少数ですが、Outlook チームは事態を改善するための積極的な取り組みを行っています。

現在の問題は、場合によっては Outlook はアドインを正常にシャットダウンできないことにあります。すなわち、Outlook オブジェクトに対する参照を保有し続けている未解決の変数がアドインにあると、Outlook は OnDisconnection メソッドを呼び出しません。これは実質的なデッドロックです。つまり、アドインは、OnDisconnection 呼び出しを取得しない限り参照を保有し続けますが、アドインがこのように参照を保有し続けるために、Outlook は OnDisconnection 呼び出しを行いません。

非常にシンプルなアドインでは、すべての参照を使用し終わったらすぐにそれらの参照を丹念にクリーンアップすることで、このような事態に陥らないようにすることができます。ただし、もっと込み入った機能ともっと多数のオブジェクト参照が付帯する現実のアドインでは、たいていの場合はこの方法は実際的ではありません。通常は、イベントハンドラをアクティブのままにしておくために、オブジェクトに固執することになります。多くの場合、アドインの機能をかなり限定しないと、問題を回避できません。

AddinLoader コンポーネントの利点

Visual Studio 2005 Tools for Office の AddinLoader コンポーネントはシンプルですが、開発者および管理者が遭遇する今日の問題の大半を解決します。 AddinLoader コンポーネントには、次のようないくつかの大きな長所があります。

AppDomain の分離。 AddinLoader コンポーネントには、COM シム (および OTKLoadr) のすべての利点が備わっています。すなわち、別個のAppDomains、アドインの分離、およびアドインの切断時のアドインとその AppDomain 全体の完全なアンロード機能があります。
厳格なセキュリティ。 Visual Studio 2005 Tools for Office では、カスタマイズを実行するためには、文書レベルカスタマイズの明示的な FullTrust 許可を事前に受けている必要があります。それによって、このようなソリューションのセキュリティが高まります。また、同じポリシーが、AddinLoader コンポーネントを使って読み込まれるアドインに対しても適用されます。アドインに FullTrust 許可が与えられていないと、読み込みに失敗します。
シングルシム。冗長コードを使用して別個のシムコンポーネントを各マネージアドインごとに作成する代わりに、それらすべてに対して AddinLoader コンポーネントを使用することができます。
シムのサポート。 COM シムとは違って、Visual Studio 2005 Tools for Office の AddinLoader コンポーネントは、Microsoft によって完全にサポートされています。
一貫性のあるローダー。 AddinLoader は、実質的にブートストラップアプリケーションであり、インターフェイスプロキシであります。 AppDomains の作成、セキュリティポリシーの設定、およびアドインの読み込みとアンロードといった複雑な作業は、Visual Studio 2005 Tools for Office ランタイムによって行われます。したがって、文書レベルカスタマイズとアプリケーションレベルのどちらのアドインでも、同じランタイムエンジンが使用されます。
一貫性のあるインターフェイス。 Visual Studio 2005 Tools for Office のカスタマイズでは、IStartup インターフェイスが使用されます。よって、AddinLoader コンポーネントによって読み込まれるマネージアドインも、IStartup を実装していなければなりません。実装していれば、Visual Studio 2005 Tools for Office ランタイムエンジンの全利点を活用することができ、開発者が開発時に使用するインターフェイスがより合理化されます。また、文書レベルおよびアプリケーションレベルのアドインどうしの間の一貫性も高まります。
慣れ親しんだ配置モデル。実行時に活用できるすべての利点に惹かれて AddinLoader コンポーネントを使用する場合でも、そのメカニズムでは、Office の開発者および管理者がすでによく知っているものと同じ基本配置モデルが使用されます。それはつまり、従来の方式でのアドインの登録です。
Office には変更なし。 AddinLoader コンポーネントと IStartup アドインのサポートのために Office 実行可能ファイルを変更する必要はありません。したがって、Office はこれまでとまったく同じように機能します。 Visual Studio 2005 Tools for Office ランタイムとアドインを正しく配置し終わったら、従来の IDTExtensibility2 ベースのアドインの読み込みと同じやり方で、その新規のアドインが Office に読み込まれます。 Office は、レジストリを調べてそのアドインの読み込みを要求します。この時点で AddinLoader コンポーネントは、Office からはまったく見えない方法で Visual Studio 2005 Tools for Office ランタイムエンジンを使用します。
Outlook のシャットダウン。 AddinLoader コンポーネントには、アドインの読み込み時でも Outlook を正常にシャットダウンする機能を強化するために、標準の対処法が実装されています。また、たとえ自動化されている状況下でも Outlook のシャットダウンをサポートするための拡張機能も取り込まれています。
設計時のサポート。 Visual Studio 2005 には、AddinLoader コンポーネントおよび Visual Studio 2005 Tools for Office ランタイムを使用するマネージアドインを作成できるように、設計時サポートが組み込まれています。 Visual Studio 2005 には、アドインの作成用のプロジェクトテンプレートだけでなく、アドイン用のセットアップパッケージを作成するための Visual Studio セットアッププロジェクトも備えられています。

Outlook アドインローダーのアーキテクチャ

ここで提案しているシステムに装備されたランタイム機能の大半は、Visual Studio 2005 Tools for Office ランタイムによって提供されます。このエンジンは、過去 2 年間にわたって開発されてきたものであり、ある範囲のホストアプリケーションのカスタマイズのベースとなると思われます。

忘れてならないのが、AddinLoader.dll という、1 つの新規の Visual Studio 2005 Tools for Office ランタイムコンポーネントです。これは、アンマネージ COM 登録の DLL です。このコンポーネントは、以下の 2 つの論理機能で構成されています。

アドインの読み込み。これは、きわめて小さい機能です。それは、ローダーは、Visual Studio 2005 Tools for Office ローダーをブートストラップするからです。ローダーは、AppDomains の作成、マニフェストの解析、セキュリティの検査、およびターゲットアセンブリの読み込みの諸作業をすべて行います。
IDTExtensibility2 プロキシ。このプロキシは、Visual Studio 2005 Tools for Office ランタイムへの IDTExtensibility2 のマッピングを担当します。 Office では、アドインは IDTExtensibility2 を実装しているものとみなされるのに対して、ランタイムでは、アドインは IStartup を実装しているものとみなされます。このプロキシは、この 2 つのインターフェイスどうしを互いにマップします。

このシステムに関与するさまざまな部分を図 4 に要約してあります。アドイン開発者が作成する部分のみが、マネージアドインそのものであることに注意してください。他のすべての局面は、Office または Visual Studio 2005 Tools for Office ランタイムの部分です。 AddinLoader.dll ファイルそのものは、ランタイムと一緒に配布されます。

図 4. AddinLoader のアーキテクチャ (クリックすると拡大表示されます)

AddinLoader コンポーネントに対するセキュリティ上の利点

従来のマネージアドインおよび Visual Studio 2005 Tools for Office のカスタマイズでは、2 種類のセキュリティモデルが使用されていました。これまでは、Office のセットアップに対してマネージアドインを配置する場合に、その Office が、高いセキュリティまたは非常に高いセキュリティを使って実行されていると、そのアドインを実行できるようにするには、事前にそのアドインに署名する必要がありました。 (上記の、シムなしのマネージアドインに関する制限事項についての説明を参照してください。) これに対して Visual Studio 2005 Tools for Office のカスタマイズでは、.NET ベースのコードアクセスセキュリティが使用されます。具体的に言うと、デフォルトのローカルコンピュータポリシー FullTrust 許可は取り消されて、明示的に FullTrust許可を与えるコードアクセスセキュリティが配備されている場合のみ、カスタマイズを行うことができるということです。

AddinLoader コンポーネントを使って読み込まれたマネージアドインは、Visual Studio 2005 Tools for Office セキュリティモデルを使用します。明示的に認可された FullTrust 許可がないかぎり、このアドインを実行することはできません。これには、次のような 2 つの明白な利点があります。

明示的な FullTrust ポリシーを必要とするために、ソリューションのセキュリティが大幅に強化される。
セキュリティと配置 (およびセキュリティと配置に関するすべての管理プロセス) は、マネージアドインおよび Visual Studio 2005 Tools for Office のカスタマイズなどの、あらゆる種類の拡張を通して同じである。

AddinLoader.dll ファイルそのものは、Microsoft 証明書を使って Authenticode 署名されます。この署名があれば、ユーザーは、インストール時に信頼すること (コンポーネントをインストールするかどうか) を決定できます。旧モデルでの問題の 1 つは、MSCorEE.dll に署名できないことにあります。署名すると、インストール済みのアドインを、以後は検査しないで実質的にすべて信頼することになるからです。新規の AddinLoader モデルでは、AddinLoader.dll に署名して信頼しても、すべのアドインを自動的に信頼することにはなりません。なぜなら、コードアクセスセキュリティポリシーを使って、各アドインを明示的に信頼する必要があるからです。

メモ Visual Studio 2005 Tools for Office のセキュリティモデルの論理的根拠については、ブログエントリ Channel 9 Video: .NET Code Access Security and Visual Studio 2005 Tools for Office Solutions (英語) に説明されています。

Outlook アドインの読み込み

Outlook などの Office アプリケーションを開始すると、レジストリがスキャンされて、読み込む必要のあるアドインのリストが検索されます。そのリスト中の各アドインごとに、登録済みの DLL が読み込まれて、その DLL に対して、アドイン用の IDTExtensibility2 ポインタをアプリケーションに戻すよう指示が出されます。新しいアーキテクチャでは、各アドインは AddinLoader.dll に対して登録されます。したがって、Outlook は、AddinLoader.dll を読み込んで、各アドイン用の IDTExtensibility2 ポインタを要求します。

AddinLoader コンポーネントは、アドインの読み込みを指示されると、そのアドイン用の IDTExtensibility2 プロキシを作成し、このプロキシを指すポインタを Office アプリケーションに戻します。次に、そのアドイン用の登録マニフェストを取得し、Visual Studio 2005 Tools for Office ランタイムにそのマニフェストを渡します。このランタイムは、DefaultDomain と呼ばれるデフォルトの AppDomain 内に別個に存在します。このランタイムは、マニフェストを解析し、正しいセキュリティポリシーがそろっていることを確認し、新規の AppDomain を作成し、指定されたアドインアセンブリをその AppDomain に読み込みます。この後すぐに Office アプリケーションは、IDTExtensibility2 ポインタを使ってアドインを呼び出します。それは実際にはプロキシの呼び出しであるため、AddinLoader コンポーネントはそれを、アドインで実装されている Startup メソッドの呼び出しに変換します。

アドインの読み込みでのランタイムの動作を図 5 に要約してあります。

Visual Studio 2005 Tools for Office の AddinLoader コンポーネントはシンプルで、開発者および管理者が遭遇する今日の問題の大半を解決します。。

図 5. アドインの読み込み (クリックすると拡大表示されます)

この設計によって、Office アドインとカスタマイズを読み込むための単一の一貫したメカニズムが確保されます。このメカニズムでもまた、Visual Studio 2005 Tools for Office ランタイムエンジンの多様なサービスが活用されます。マネージアドインと Visual Studio 2005 Tools for Office のカスタマイズはどちらも、同じランタイムと同じ基本読み込みメカニズムを使用します。

アプリケーションマニフェストと AddinLoader コンポーネント

AddinLoader コンポーネントは、Visual Studio 2005 Tools for Office ランタイムのブートストラッピングアプリケーションとして機能し、このランタイムでは、アプリケーションマニフェスト (シンプルな XML 構成ファイル) がどのカスタマイズにも添付されているものとみなされます。これは、レジストリから、もっと積極的なマニフェストベースの構成モデルへの移行を表します。これは、ClickOnce で使用されるモデルです (ただし Visual Studio 2005 Tools for Office ソリューションでは、ClickOnce そのものは使用されません)。このモデルは、文書レベルのカスタマイズと、アプリケーションレベルのアドインの両方に対して使用されます。マニフェストを使うアプローチは、レジストリに再度手を加えないで保守と更新を行う際の柔軟性を高めるための間接的手法として機能します。したがって、AddinLoader コンポーネントによって読み込まれるどのアドインも、アプリケーションマニフェストを使って配置する必要があります。

Office アプリケーションを開始すると、レジストリから読み込む必要のあるアドインリストがこのアプリケーションで判別されます。 AddinLoader コンポーネントは、同じやり方で新規の IStartup アドインを登録します。違う点は、レジストリエントリはアプリケーションマニフェスト (アセンブリではなく) を指し、そのマニフェストが、アセンブリのロケーションを指定することにあります。

アプリケーションマニフェストの例を以下に示してあります。このマニフェスト中の重要な値は、マネージアドインアセンブリ (太字で示されています) への URL です。この例では、マニフェストと同じフォルダ内にアセンブリがあると想定されています。ただし、コードのベース値は、ローカルファイルシステムまたはネットワーク共有上の任意の場所への相対パスまたは絶対パスのどちらでもかまいません。

<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" manifestVersion="1.0">
  <assemblyIdentity name="HelloWorldAddin.manifest" version="1.0.0.0" />
  <asmv2:entryPoint name="Startup" dependencyName="dependency0">
    <asmv2:clrClassInvocation class="HelloWorldAddin.ThisApplication" />
  </asmv2:entryPoint>
  <asmv2:dependency asmv2:name="dependency0">
    <asmv2:dependentAssembly>
      <assemblyIdentity name="HelloWorldAddin" version="1.0.0.0" culture="neutral" />
    </asmv2:dependentAssembly>
    <asmv2:installFrom codebase="HelloWorldAddin.dll" />
  </asmv2:dependency>
</assembly>

メモマニフェストの配置と更新のメカニズムに関する詳細は、Visual Studio Tools for Office を使用した Outlook アドインのセットアップと配置を参照してください。

Visual Studio 2005 Tools for Office マニフェストの詳細は、Application Manifests for Office Solutions (英語) および Deployment Manifests for Office Solutions (英語) を参照してください。

AddinLoader レジストリエントリ

AddinLoader のメカニズムは、ホストの Office アプリケーションからは見えません。ホストの Office アプリケーションは、このメカニズムでは従来の IDTExtensibility2 COM アドインが読み込まれると信じ込んでいます。どのアドインにも、Office にとっては当然の書式の従来どおりのレジストリエントリがあります。このレジストリエントリには、アドイン用のマニフェストの URL という、追加情報が入れられます。 Office アプリケーションが AddinLoader コンポーネントを使ってアドインを読み込むときは、図 6 に示されているとおり、どのアドインを読み込むかを確かめるためにさまざまなレジストリエントリが使用されます。

図 6. レジストリのマッピング (クリックすると拡大表示されます)

プロジェクトウィザードで生成したセットアッププロジェクトによって、レジストリエントリが構成されます。すべてのエントリを連結したものが、以下に一覧で示されているレジストリファイル内に示されています (ただし、レジストリファイルは実際には使用されません)。このレジストリ情報には、マネージアドインアセンブリは含まれていません。 AddinLoader DLL へのパスと、マニフェストへのパス (どちらも太字で示されています) が、代わりに組み込まれています。

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Outlook\Addins\HelloWorldAddin]
"FriendlyName"="HelloWorldAddin"
"Description"="This is sample com addin using AddinLoader.dll"
"LoadBehavior"=dword:00000003
"CommandLineSafe"=dword:00000001

[HKEY_CLASSES_ROOT\HelloWorldAddin]
@="Sample COM Addin"
[HKEY_CLASSES_ROOT\HelloWorldAddin\CLSID]
@="{F0E54810-A875-4c54-9697-0AE40DAA7317}"

[HKEY_CLASSES_ROOT\CLSID\{F0E54810-A875-4c54-9697-0AE40DAA7317}]
[HKEY_CLASSES_ROOT\CLSID\{F0E54810-A875-4c54-9697-0AE40DAA7317}\InprocServer32]
@="C:\\Program Files\\Common Files\\Microsoft Shared\\VSTO\\8.0\\AddinLoader.dll"
"ManifestLocation"="c:\\temp"
"ManifestName"="HelloWorldAddin.manifest"
"ThreadingModel"="Both"
[HKEY_CLASSES_ROOT\CLSID\{F0E54810-A875-4c54-9697-0AE40DAA7317}\ProgID]
@="HelloWorldAddin"
[HKEY_CLASSES_ROOT\CLSID\{F0E54810-A875-4c54-9697-0AE40DAA7317}\Programmable]
[HKEY_CLASSES_ROOT\CLSID\{F0E54810-A875-4c54-9697-0AE40DAA7317}\
VersionIndependentProgID]
@="HelloWorldAddin"

前のサンプルでは、AddinLoader.dll そのものは、以下の事前割り当ての場所に配置されると想定されていることに注意してください。

%CommonProgramFiles%\Microsoft Shared\VSTO\8.0\

これは、Visual Studio 2005 Tools for Office ランタイムの DLL の配置先と同じ場所です。 AddinLoader.dll に対して登録済みのアドイン用のレジストリエントリは、従来の COM アドインのレジストリエントリと同じレジストリ場所に作成されます。

Outlook アドインのアンロード

新規モデルは、アドインのアンロード (ユーザーが [COM アドイン] ダイアログボックスを使用してアドインの切断を選択すると起動されます) もサポートします。これは、これまでのアドインモデルには取り入れられていなかった機能です。ホスト Office アプリケーション (この場合は Outlook) がアドインを切断したい場合、そのアドインに対して OnDisconnection メソッドを呼び出します。この呼び出しはプロキシを通して送達されるため、AddinLoader コンポーネントが制御権を得ることができます。 AddinLoader コンポーネントは OnDisconnection 呼び出しを、アドインで実装されている Shutdown メソッドの呼び出しに変換します。

次に、AddinLoader コンポーネントは、Visual Studio 2005 Tools for Office ランタイムを呼び出して、アドインの読み込み先の AppDomain をアンロードします。これによって、アドインアセンブリそのものがアンロードされます。この点に関するかぎりでは、Visual Studio 2005 Tools for Office ランタイムは、文書レベルのカスタマイズおよびアプリケーションレベルのアドインのどちらに対しても同じ働きをします。アドインのアンロードでのランタイムの動作は、図 7 に要約されています。

図 7. アドインのアンロード (クリックすると拡大表示されます)

Outlook のシャットダウンの妨害

前述のとおり、Outlook がアドインと対話するこれまでのやり方には、周知の変則性があります。つまり、Outlook オブジェクトに対する参照を保有し続けている未解決の変数がアドインにあると、Outlook は OnDisconnection メソッドを呼び出しません。しかし周知の対処法も存在するので、このような想定外の動作を訂正して、発生の頻度を減らすかまたは無くすことができます。この対処法は、AddinLoader.dll および Visual Studio 2005 Tools for Office ランタイム内に組み込まれています。 AddinLoader コンポーネントは、それが Outlook 内で稼動中かどうかを判別し、もし稼動中であれば、該当するイベントをリッスンして、アドインが正しくクリーンアップされるようにします。具体的に言うと、プロキシは Outlook の Explorer.Close、Inspector.Close、および Application.Quit イベントをリッスンします。 AddinLoader コンポーネントは、Explorer およびインスペクターのカウントの追跡記録をとりつづけます。 Application.Quit が呼び出されるか、または Close イベントが起動された場合に、Explorer もインスペクターももう開いていない (カウントはゼロ) と、Outlook はシャットダウン中であると確信できます。この場合、AddinLoader コンポーネントはアドインに実装された IStartup に対して Shutdown を呼び出してから、AppDomain をアンロードすることによって、Outlook が活動中のままになる原因の参照をクリーンアップします。こうすれば、ほぼすべての状況下で Outlook は正常にシャットダウンすることができます。

Outlook アドインの無効化

現在、Office ホストは、「ハード」および「ソフト」という 2 通りの方法でアドインを無効にすることができます。ユーザーが Office の [COM アドイン] ダイアログボックスを使ってアドインの接続を単に切断した場合か、またはアドインが自身の読み込み時に未処理例外をスローした場合、アドインはソフトに無効化されます。アドインは、自身の読み込み時にホストアプリケーションを破壊した場合はハードに無効化されます。 (ホストの始動後のアドインのオンデマンドの読み込みも、このような事態に含まれます。) ハードな無効化は、Office の「復元モデル」とも呼ばれます。その理由は、アドインにおける障害時に Office アプリケーションを復元できるようにするからです。

アドインがソフト無効化された場合、ユーザーは、Office の [COM アドイン] ダイアログボックスを使ってその再有効化を試みることができます。アドインがハード無効化された場合、ユーザーは、Office の [使用できないアイテム] ダイアログボックスを使ってその再有効化を試みることができます。

Office は、各アドインごとに LoadBehavior レジストリサブキーを使って、ソフト無効化されたアドインを識別します。 Office は、StartupItems レジストリキー内のエントリを使って、ハード無効化されたアドインを識別します。これは、Office によって DisabledItems キー内のエントリに変換されます。

AddinLoader コンポーネントは、Office のハード無効化の動作 (復元モデル) をまったく変更しません。つまり、アドインは、MSCorEE.dll に対してではなく AddinLoader.dll に対して登録されますが、AddinLoader.dll がブロックされるのを防ぐものは何もないということです。それによって、現在のユーザーおよび管理者の見込みどおりの動作が確保されます。

AddinLoader.dll に対して登録されたアドインは、LoadBehavior に対する Office のアルゴリズムを変更しません。これまでの COM アドインと同じ LoadBehavior のセマンティクスに追従します。登録済みのアドインは、LoadBehavior の値に応じて、始動時または要求時に読み込まれないことも、またはまったく読み込まれないこともあります。

Office アプリケーションは、従来のアドインの読み込みに失敗したときには、Visual Studio 2005 Tools for Office のカスタマイズ内容の読み込みの失敗時のものとは異なるユーザーインターフェイスを表示します。 Visual Studio 2005 Tools for Office カスタマイズの読み込みに失敗すると、ユーザーフレンドリなエラーメッセージを示したダイアログボックスが表示されます。アドインの読み込みが失敗しても、UI の表示はありません。ただし、ユーザーはその後 [COM アドイン] ダイアログボックスに移動 (しかも明示的に)し、そこでどのアドインが読み込まれたかを確かめることができます。 AddinLoader コンポーネントを使って読み込んだアドインの場合、Visual Studio 2005 Tools for Office の文書のカスタマイズで使用するのとまったく同じダイアログボックスが用意されています。このダイアログには、問題の簡単な説明が付けられていて、問題が発生したスタックが示されます。

デフォルトでは、エンドユーザーに対してはこのダイアログボックスは表示されません。これは、現在のアドインの動作と一貫しています。このダイアログボックスが用意されているのは、主としてデバッグ中の開発者をサポートするためです。ただし、エンドユーザー (またはその管理者) が使用可能にすることを選択した場合は、エンドユーザーもこのダイアログボックスを使うことができます。以下のどちらか一方または両方の条件が成立した場合、ダイアログボックスは活動化されます。

マネージデバッガまたはアンマネージデバッガを使ってホストアプリケーションをデバッグしている。
VSTO_SUPPRESSDISPLAYALERTS 環境変数が 0 に設定されている。

Visual Studio アドインプロジェクトの作成

セットアッププロジェクトは、アドインプロジェクトからのプライマリ出力などで構成されます。セットアッププロジェクトを作成すると、MSI ファイルには以下のものが入ります。

アドインアセンブリ
すべての従属アセンブリは CopyLocal=true を設定します。通常、これらは、グローバルアセンブリキャッシュ内にはない任意の依存関係です。
アプリケーションのマニフェストファイル
必要なレジストリエントリ

Outlook アドインプロジェクトに対しては、Visual Studio 2005 の [発行] オプションも使用できます。このオプションを選択すると、Visual Studio は以下のアクションを実行します。

配置マニフェストを生成する。
アドインアセンブリ、すべての依存関係、アプリケーションマニフェストと配置マニフェストを、選択された場所にコピーする。
配置マニフェストの場所をアプリケーションマニフェストに書き込むことで、アプリケーションマニフェストと配置マニフェストの間の関係を確立する。

配置マニフェストを指定して発行されたアドインを読み込むための操作シーケンスを図 8 に図示してあります。

図 8. 発行されたアドインの読み込み (クリックすると拡大表示されます)

AddinLoader コンポーネントがアプリケーションマニフェストの名前と場所を Visual Studio 2005 Tools for Office ランタイムに渡すと、このランタイムは、そのアプリケーションマニフェストから配置マニフェストの場所を抽出します。次に、その配置マニフェストを検査して、更新バージョンのアプリケーションマニフェスト (したがって、おそらく更新バージョンのアセンブリも) があるかどうかを判別します。ある場合、更新済みのアプリケーションマニフェストと、更新済みのアプリケーションマニフェストが指すアセンブリを読み込みます。この後、アプリケーションマニフェストのローカルコピーは、最新バージョンによって上書きされます。

典型的な配置マニフェストを以下に一覧で示してあります。最新バージョンのアプリケーションマニフェストへの参照は、太字で示されています。

<?xml version="1.0" encoding="utf-8"?>
<asmv1:assembly xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1
assembly.adaptive.xsd" manifestVersion="1.0"
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns="urn:schemas-
microsoft-com:asm.v2" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1"
xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"
xmlns:xrml="urn:mpeg:mpeg21:2003:01-REL-R-NS"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <assemblyIdentity name="HelloWorldAddin.application" version="1.0.0.0"
  publicKeyToken="0000000000000000" language="neutral"
  processorArchitecture="msil" xmlns="urn:schemas-microsoft-com:asm.v1" />
  <description asmv2:publisher="VPCs Inc" asmv2:product="HelloWorldAddin"
  xmlns="urn:schemas-microsoft-com:asm.v1" />
  <deployment install="true" />
  <dependency>
    <dependentAssembly dependencyType="install" allowDelayedBinding="true" 
   codebase="HelloWorldAddin_1.0.0.0\HelloWorldAddin.dll.manifest" 
   size="1492">
      <assemblyIdentity name="HelloWorldAddin.manifest" version="1.0.0.0" />
      <hash>
        <dsig:Transforms>
          <dsig:Transform Algorithm="urn:schemas-microsoft-
com:HashTransforms.Identity" />
        </dsig:Transforms>
        <dsig:DigestMethod
        Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
        <dsig:DigestValue>2W4LgekQ5+O4biOA1nRyajoUjxM=</dsig:DigestValue>
        </hash>
    </dependentAssembly>
  </dependency>
</asmv1:assembly>

HelloWorld アドインを発行すると、それに対応するこのソリューション用のアプリケーションマニフェストが更新されて、配置マニフェスト (太字で示されています) の参照が組み入れられます。

<assembly xmlns="urn:schemas-microsoft-com:asm.v1"
xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" manifestVersion="1.0">
  <assemblyIdentity name="HelloWorldAddin.manifest" version="1.0.0.0" />
  <asmv2:entryPoint name="Startup" dependencyName="dependency0">
    <asmv2:clrClassInvocation class="HelloWorldAddin.ThisApplication" />
  </asmv2:entryPoint>
  <asmv2:dependency asmv2:name="dependency0">
    <asmv2:dependentAssembly>
      <assemblyIdentity name="HelloWorldAddin" version="1.0.0.0"
      culture="neutral" />
    </asmv2:dependentAssembly>
    <asmv2:installFrom codebase="HelloWorldAddin.dll" />
  </asmv2:dependency>
  <asmv2:installFrom 
codebase="C:\ManagedAddins\HelloWorldAddin\HelloWorldAddin.application" />
</assembly>

開発者のコンピュータで作業している間は、アドインソリューションを作成すると、ローカルコンピュータ上でコードアクセスセキュリティポリシーが Visual Studio によってセットアップされることに注意してください。ただし、アドインを発行する (開発者のコンピュータ上であっても) ときは、新しい場所に適したコードアクセスセキュリティポリシーを手動でセットアップする必要があります。

Visual Studio Tools for Office を使用した Outlook アドインのセットアップと配置

従来のマネージアドインを作成すると、IDTExtensibility2 共有アドインプロジェクトウィザードによって、ホスト固有のレジストリエントリが設計時に挿入されます。その後、アドインの作成時に RegAsm が呼び出されて、汎用の COM 表示のレジストリエントリが挿入されます。さらに、アドインプロジェクトの作成時に自動生成されたセットアッププロジェクトによって MSI が作成されます。この MSI は、ホスト固有のレジストリエントリを収容していて、汎用レジストリエントリを挿入するときに RegAsm を呼び出します。

この動作には、以下の 2 つの問題があります。

コンピュータからコンピュータにプロジェクトを移動する (たとえば、別の開発者のソース管理のソリューションコードを検査する場合など) と、混乱を生じることがあります。なぜなら、ホスト固有のエントリは、プロジェクトがもともと作成されたコンピュータ上にしか存在しないからです。これに対処する対策案としては、必ず開発のステップとして MSI を作成して実行するようにしてください。元のウィザード生成のレジストリエントリに頼らないでください。
MSI プロジェクトにはいくつかの明示的なレジストリ設定値が入っているのに、他のレジストリ設定値の RegAsm の呼び出しに依存するという事実も、混乱を生じる原因になります。

新規のモデルでは、マネージアドイン用のプロジェクトを作成すると、2 つのプロジェクトが作成されます。一方はアドインそのもの用、もう一方はそのアドインのセットアップ用です。セットアッププロジェクトは、作成する必要のあるすべてのレジストリエントリを合体させます。登録は、MSCorEE.dll に対して登録されているシムが組み込まれていないマネージアドインと同じですが、AddinLoader.dll に対して登録される点と、マニフェスト URL を指定するエントリが追加される点が異なります。

この新しいプロジェクトシステムは、IDTExtensibility2 共有アドインプロジェクトとは違って、プロジェクトの作成時にレジストリエントリを挿入しません。レジストリエントリは、プロジェクトの作成時に挿入されます。つまり、ソリューションをソース管理にチェックインおよびチェックアウトしたり、ある 1 つの開発者コンピュータから別のものに移動したりしても、ソリューションを作成するときに必要なレジストリエントリはすべて得られるという意味です。必要があれば、開発中に MSI を作成および実行するオプションはいつでも選択できます。また、場合によっては、セットアッププロジェクトをテストするためにのみ選択してもかまいません。

Visual Studio 2005 Tools for Office の文書レベルのカスタマイズでは、サーバー側の配置モデルがサポートされます。つまり、カスタマイズを表すマネージアセンブリ (およびすべての従属アセンブリ) をサーバー上に配置することができます。 Visual Studio 2005 Tools for Office のアプリケーションレベルのアドインの場合も、このモデルがサポートされます。ローカルコンピュータまたはサーバーのどちらにアドインがあっても、ローカルのインストールがやはり必要です。ローカルのインストールでは、マニフェストを参照するレジストリエントリをインストールする必要があり、ローカルコンピュータ上にコードアクセスセキュリティポリシーを配置する必要があります。アプリケーションマニフェストは、ローカルコンピュータまたはサーバーのどちらにインストールしてもかまいません。マニフェストが、アドインアセンブリへのパスを指定します。このアセンブリも、ローカルコンピュータまたはサーバーのどちらにあってもかまいません。

このモデルには、Visual Studio 2005 Tools for Office の文書レベルカスタマイズとの一貫性があります。中心的な違いは、文書レベルカスタマイズではマニフェストは文書またはワークブックに組み込まれているのに対して、アプリケーションレベルのアドインでは、マニフェストはファイルシステム上の別個のファイルになっていて、アプリケーションレベルのワークブックには、レジストリエントリが必要であるという点にあります。

AddinLoader コンポーネントに対して登録されたアドインの場合、AddinLoader.dll を正しくコンピュータに配置する必要があるのは明らかです。 AddinLoader コンポーネントは、Visual Studio 2005 Tools for Office ランタイムに依存します。このランタイムは、共通言語ランタイム (CLR) のバージョン 2.0 に依存します。 AddinLoader コンポーネントに対してアドインを登録しても、AddinLoader.dll または依存関係チェーン内の他の何かが使用可能でないと、そのアドインの読み込みは失敗します。エラーメッセージがオンになっていない場合には、その失敗は、[COM アドイン] ダイアログボックス内のチェックボックスがクリアされることで表されます。

IStartup ベースのアドインが順調に働くためには、以下のコンポーネントがコンピュータ上にそろっている必要があります。

Microsoft .NET Framework バージョン 2.0
Outlook 2003 Service Pack 1
Outlook 2003 Primary Interop Assemblies
メモ現在、Office 2003 Primary Interop Assemblies は、ソリューション開発者向けの再配布パッケージに入れて提供されます。これをダウンロードするには、Office 2003 Update: Redistributable Primary Interop Assemblies (英語) を参照してください。
Visual Studio 2005 Tools for Office ランタイム
該当するコードアクセスセキュリティポリシー
アドイン DLL そのもの、従属するすべての DLL、アプリケーションマニフェストと配置マニフェスト、およびレジストリエントリ

管理者にとって配置を可能なかぎりシンプルにするために、アドインのセットアッププロジェクトには、Visual Studio 2005 Tools for Office ランタイムがまだターゲットコンピュータにない場合にこのランタイムを配置するためのステップが付け加えられています。

Visual Studio 2005 Tools for Office ソリューションのセットアップと配置に関する詳細は、 Deploying Office Solutions (英語) を参照してください。

アプリケーションマニフェストを使用した Outlook アドインの更新

Visual Studio 2005 Tools for Office の文書レベルカスタマイズは、更新をサポートします。そのメカニズムには、配置マニフェストを指すローカルアプリケーションマニフェストが備えられています (通常はサーバー側に)。配置マニフェストは、サーバー上の最新バージョンのアプリケーションマニフェストを指します。アプリケーションマニフェストには、アセンブリの最新バージョンとその場所に関する情報が入っています。断続的に接続が切断されるケースをサポートするために、このメカニズムでは、新バージョン (サーバー側のアプリケーションマニフェストとアセンブリの) が利用可能になったときにローカルのアプリケーションマニフェストが更新 (上書き) されます。

アプリケーションレベルのアドインでも更新がサポートされます。それには、既存の文書レベルメカニズムとほぼ同じメカニズムが使用されます。 2 つの主な配置オプションが、表 3 に一覧で示されています。

表 3. 配置オプション

メカニズム	ローカルコンピュータ	サーバー	更新
MSI	レジストリ設定、コードアクセスセキュリティポリシー、アプリケーションマニフェスト、配置マニフェスト、およびアドインアセンブリ	(なし)	除去、再インストール
MSI、.reg、と (または) スクリプト	レジストリ設定、コードアクセスセキュリティポリシー、およびアプリケーションマニフェスト	配置マニフェストおよびアドインアセンブリまた、最新バージョンのアプリケーションマニフェスト	Xcopy を使用して、新しいバージョンのアセンブリをコピーできます。マニフェストを直接編集できます。

ここでのセットアッププロジェクトを介して、もっともよくある配置シナリオをサポートすることができます。そのサポートには次の 2 通りがあります。

ローカルコンピュータインストール (通常は、制御下にないデスクトップへソリューションを配布する ISV によって使用されます) の場合、アドインアセンブリ、アプリケーションマニフェストと配置マニフェストの両方、レジストリエントリ、およびコードアクセスセキュリティポリシーのすべてを組み込んだセットアッププロジェクトが用意されています。
サーバーインストール (通常は、社内のデスクトップを制御下に置いている企業で使用されます) の場合、管理者は Xcopy を使用して、アドインアセンブリと両方のマニフェストをサーバーにコピーします。また管理者は、ローカルコンピュータのレジストリ設定、アプリケーションマニフェストのローカルコピー、およびコードアクセスセキュリティポリシーも配置する必要があります。

ほぼすべての更新シナリオでは、管理者はレジストリに触れることなく、アセンブリ、アプリケーションマニフェスト、または配置マニフェストを手動で自由に変更できます。管理者がレジストリ設定を変更する必要がある唯一のシナリオは、ローカルアプリケーションマニフェストへのパスが変更された場合です。

まとめ

Outlook アドインサポートの導入によって、Microsoft の Visual Studio 2005 Tools for Office テクノロジの機能性が拡張され、文書レベルのカスタマイズだけでなくアプリケーションレベルのマネージ Office アドインもその対象となりました。 AppDomain の分離、タイプセーフなコードモデル、および厳格なコードアクセスセキュリティモデルを使用する Office 用のマネージアドインを作成するための、堅実かつサポートされている手段が初めて開発者の手に入りました。

追加資料

Outlook アドインツールの詳細は、以下の資料を参照してください。

Outlook でのプログラムの可能性に関する詳細は、以下の資料を参照してください。

ページのトップへ

プロファイル (個人情報) の管理 | お問い合わせ先 | MSDN Flash ニュースレター | 日本での個人情報の取り扱い | サイトマップ

目次