Office のサーバーサイド オートメーションについて

開発者は、Microsoft Office でのオートメーションを使用して、Office 製品の組み込み機能を使用したカスタム ソリューションを構築できます。このようなプログラミングによって開発した機能は、クライアント システムに比較的簡単に実装できますが、Microsoft ASP (Active Server Pages)、ASP.NET、DCOM、Windows NT サービスなど、サーバーサイドのコードからオートメーションを起動する際に多数の問題が発生する可能性があります。

この資料では、開発者が直面することがある問題について説明します。またこの資料では、パフォーマンスを向上できるオートメーションの代替策についても説明します。ただし開発者は、この資料で示す設定方法の例は情報提供のみを目的としていることに注意する必要があります。マイクロソフトは、Office のサーバーサイド オートメーションの推奨もサポートも行っていません。

注 : この資料では、ユーザーがログオンしている対話型のステーション以外の Windows ワークステーションからコードが実行されているのであれば、Windows ワークステーション上で実行されるコードに対しても "サーバーサイド" という用語を使用します。たとえば、タスク スケジューラによって SYSTEM アカウントの下で実行されるコードは、"サーバーサイド" ASP コードまたは DCOM コードと同じ環境で実行されます。このため、この資料で説明されている問題の多くが発生する場合があります。Windows ワークステーションおよび COM については、「詳細」および「関連情報」を参照してください。

現在のすべてのバージョンの Microsoft Office は、クライアント ワークステーション上でエンドユーザー製品として実行するように設計、テスト、および構成されています。これらの製品では、対話型デスクトップおよびユーザー プロファイルを想定しています。無人実行されるように設計されたサーバーサイド コンポーネントの必要性を満たすのに必要なレベルの再入可能性やセキュリティは提供されません。

マイクロソフトは、現在のところ、無人の非対話型クライアント アプリケーションまたはコンポーネント (ASP、ASP.NET、DCOM、および NT サービスを含む) からの Microsoft Office アプリケーションのオートメーションに関して、推奨もサポートも行っていません。それは、このような環境で Office を実行した場合、Office で不安定な動作やデッドロックが発生する可能性があるためです。

サーバーサイド コンテキストで実行するソリューションを構築する場合、安全に無人実行できるコンポーネントを使用する必要があります。または、少なくとも、コードの一部をクライアントサイドで実行できる代替策を探す必要があります。サーバーサイド ソリューションから Office アプリケーションを使用すると、アプリケーションでは正常な実行のために必要な機能の多くが失われます。また、ソリューション全体の安定性を損なう危険性があります。

Office のオートメーションをサーバーサイドで使用する際の問題

Office をサーバーサイド ソリューションで使用する開発者は、環境によっては Office が予想外の動作をする、主に 5 つの領域があることを認識しておく必要があります。コードを正常に実行するには、これらの問題を解決し、その影響を最小限に抑える必要があります。アプリケーションの構築にあたってはこれらの問題を慎重に検討します。これらの問題をすべて解決する方法はありません。設計が異なる場合は、要素の優先順位付けを変える必要があります。

• ユーザー ID : Office アプリケーションは、オートメーションから起動された場合でも、実行時にはユーザー ID を使用します。アプリケーションでは、アプリケーションを起動したユーザーのユーザー レジストリ ハイブの設定に基づいて、ツール バー、メニュー、オプション、プリンタ、およびアドインの初期化が行われます。多くのサービスは、ユーザー プロファイルがないアカウント (SYSTEM アカウント、IWAM_[servername] アカウントなど) で実行されます。そのため、起動時に Office が適切な初期化に失敗する場合があります。この場合、Office は CreateObject 関数または CoCreateInstance 関数のエラーを返します。Office アプリケーションを起動できた場合でも、ユーザー プロファイルがなければ、その他の関数が適切に動作しないこともあります。
• デスクトップでの対話的処理 : Office アプリケーションは、対話型デスクトップで実行されることが想定されています。場合によっては、何らかのオートメーション機能を適切に実行するために、アプリケーションには表示が必要になることがあります。Office は、予期しないエラーが発生した場合、または機能の実行に必要なパラメータが未指定になっている場合には、ユーザーに操作内容を確認するモーダル ダイアログ ボックスが表示されるように設計されています。非対話型デスクトップでのモーダル ダイアログ ボックスは閉じることができません。これが原因となり、そのスレッドが応答しない (ハング) ままになります。コードを工夫することで、このような状態に陥る可能性を低減することはできますが、完全に防止することはできません。このことだけを取り上げても、サーバーサイド環境からの Office アプリケーションの実行は危険であり、このような実行はサポートされません。
• 再入可能性とスケーラビリティ : サーバーサイド コンポーネントは、複数のクライアントに対してオーバーヘッドが最小でスループットが高い、高い再入可能性を持つ、マルチスレッド COM コンポーネントである必要があります。Office アプリケーションは、ほとんどすべての点でサーバーサイド コンポーネントと対照的です。Office アプリケーションは、リソースを多用する各種機能を単一のクライアントに提供するように設計された、再入不可能な、STA ベースのオートメーション サーバーです。アプリケーションでは、サーバーサイド ソリューションとしてのスケーラビリティはほとんど提供されません。また、メモリなどの重要な要素に対する制限は固定されています。構成を使用して制限を変更することはできません。さらに重要なことに、アプリケーションは、メモリ マップ ファイル、グローバル アドインまたはテンプレート、共有オートメーション サーバーなどのグローバル リソースを使用します。これにより、同時実行可能なインスタンス数が制限されることがあり、マルチクライアント環境で構成されている場合には競合が発生する可能性があります。Office アプリケーションの複数のインスタンスの同時実行を計画する開発者は、Office アプリケーションへのアクセスの "プール" またはシリアル化を検討して、デッドロックまたはデータ破損の可能性を回避する必要があります。
• 障害許容力と安定性 : Office 2000、Office XP、Office 2003、および Office 2007 では、Microsoft Windows インストーラ (MSI) テクノロジを使用して、エンド ユーザーがより簡単にインストールおよび自己修復できるようにしています。MSI には "初めて実行するときにインストール" という概念が導入されています。これにより、システム、または多くの場合は特定のユーザーが、実行時に動的に機能をインストールしたり構成したりすることができます。このため、サーバーサイド環境では、パフォーマンスが低下し、インストールの確認またはインストール ディスクの提示をユーザーに求めるダイアログ ボックスが表示されることが多くなります。エンドユーザー製品としての Office の障害許容力を高めるためにこのような設計になっていますが、Office に MSI 機能が実装されていると、サーバーサイド環境では生産性が低下します。さらに、Office はサーバーサイドでの使用に合わせて設計またはテストされていないため、Office をサーバーサイドで実行した場合、一般に安定性は保証できません。Office をネットワーク サーバー上のサービス コンポーネントとして使用した場合、そのコンピュータの安定性を損ない、その結果、ネットワーク全体の安定性を損なう場合があります。
• サーバーサイドのセキュリティ : Office アプリケーションでは、サーバーサイドでの使用が想定されていません。そのため、Office アプリケーションでは、分散コンポーネントが直面するセキュリティ問題に関しては考慮されていません。Office では、着信要求の認証を行いません。また、Office では、マクロが誤って実行されたり、マクロを実行する可能性のある別のサーバーがサーバーサイド コードから起動されたりすることを防止できません。匿名 Web サイトからサーバーにアップロードされたファイルを開かないようにしてください。最後に設定されたセキュリティ設定に基づいて、サーバーはすべての権限を持つ Administrator または System のコンテキストでマクロを実行し、ネットワークを危険にさらす可能性があります。また、Office では、処理効率の向上のために、クライアントの認証情報をキャッシュできるクライアントサイド コンポーネント (Simple MAPI、WinInet、MSDAIPP など) を多用します。Office がサーバーサイドでオートメーションによって呼び出されている場合、1 つのインスタンスで複数のクライアントにサービスを提供することがあります。認証情報がそのセッション用にキャッシュされている場合、あるクライアントが別のクライアントのキャッシュされた認証情報を使用できます。そのため、クライアントは、別のユーザーになりすますことによって、許可されていないアクセス権限を取得する可能性があります。

技術的な問題の他にも、ライセンスの問題を考慮する必要もあります。現在のライセンス ガイドラインでは、クライアント自身に Office のライセンスを受けたコピーがない場合は、サーバー上で Office アプリケーションを使用してクライアント要求に対するサービスを提供することは許可されません。サーバーサイド オートメーションを使用して、ライセンスを受けていないワークステーションに Office 機能を提供することは、使用許諾契約書 (EULA) には含まれていません。

このような問題以外にも、オートメーションによってサーバーサイドで Office を呼び出したときに、次のいずれかのエラーが共通して発生することがあります。

• CreateObject 関数および CoCreateInstance 関数が次のいずれかの実行時エラー メッセージを返し、オートメーションに対して起動できません。
  
  
  メッセージ 1
  実行時エラー '429': ActiveX コンポーネントはオブジェクトを作成できません。
  メッセージ 2
  実行時エラー '70': 書き込みできません。
  メッセージ 3
  CO_E_SERVER_EXEC_FAILURE (0x80080005): サーバーの実行に失敗しました
  メッセージ 4
  E_ACCESSDENIED (0x80070005): アクセスは拒否されました
• Office ドキュメントを開くときに、以下のいずれかのエラー メッセージが表示されます。
  
  
  メッセージ 1
  実行時エラー '5981' (0x800A175D): マクロの記憶領域を開くことができません。
  メッセージ 2
  実行時エラー '1004': ~' メソッドは失敗しました: '~' オブジェクト
• CreateObject 関数および CoCreateInstance 関数が応答を停止して終了しないか、復帰に時間がかかります。サーバーによっては、作成は即座に行われたにもかかわらず、Windows イベント ログに、アプリケーションが停止したことを示す 1004 エラーが表示される場合もあります。
• ある種の関数は、ユーザー警告、またはユーザーの注意を必要とするその他のダイアログ ボックスにより、突然失敗したり、無限に応答を停止したりします。
• 複数の要求を実行した場合、または負荷テストを実施した場合、Office アプリケーションの作成時または終了時にコードが失敗、応答停止、またはクラッシュします。この問題が発生すると、メモリ内でプロセスが実行されたままの状態になり終了できなくなるか、それ以降オートメーションで呼び出されるアプリケーションのインスタンスがすべて失敗します。

ここに示す以外にも、その他の問題が発生したりメッセージが表示されたりすることもありますが、これらの問題は通常、この資料で前に示した 5 つの主要な問題の結果として生じるものです。

サーバーサイド オートメーションの代替策

マイクロソフトは、サーバーサイド ソリューション開発の必要がある開発者には、Office のオートメーションの代替策を探すことを強くお勧めします。Office の設計には制約があるため、Office の構成に変更を加えてもすべての問題を解決するには不十分です。マイクロソフトは、サーバーサイドに Office をインストールする必要がなく、オートメーションより効率よく迅速に共通のほとんどのタスクを実行できるいくつかの代替策を強くお勧めします。 Office をサーバーサイド コンポーネントとしてプロジェクトに含める前に、代替策について検討してください。

ほとんどのサーバーサイド オートメーションのタスクには、ドキュメントの作成または編集が含まれます。Office 2007 では、開発者がサーバー サイドでファイル コンテンツを作成、編集、読み込み、および変換できる新しい Open XML ファイル形式がサポートされています。これらのファイル形式は、Microsoft .NET 3.x Framework で System.IO.Package.IO 名前空間を使用して、Office クライアント アプリケーション自体を使用せずに Office ファイルを編集します。これが、サービスから Office ファイルへの変更を処理するための推奨されるサポートされた方式です。

Open XML ファイル形式は公開標準です。仕様のコピーを入手するには、以下の Web サイトを参照してください。マイクロソフトは、.NET 3.x Framework から Open XML ファイル形式を操作するための SDK を提供しています。SDK の詳細、および SDK を使用して Open XML ファイルを作成または編集する方法の詳細については、以下の MSDN (Microsoft Developer Network) Web サイトを参照してください。 例として .NET 3.0 Framework から Open XML を使用する方法の関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。 以前のバージョンの Office (Office 2000、Office XP、および Office 2003 など) を実行しているユーザーは、マイクロソフト Web サイトから無料の互換機能パックをインストールすると、Open XML ファイルを表示および編集することができます。互換機能パックをダウンロードしてインストールするには、次のマイクロソフト Web サイトを参照してください。ASP または ASP.NET から Open XML ファイルをストリーム出力する場合は、ストリーム出力するコンテンツ用の適切な MIME (Multipurpose Internet Mail Extension) の種類を用意する必要があります。Office 2007 ファイル用の MIME の種類の一覧については、次の Web サイトを参照してください。Office 2007 よりも前のクライアントのみを対象としていて、ソリューションで Open XML を使用する必要がない場合、HTML、XML、RTF など、その他の非バイナリ Office ファイル形式を使用することができます。続いて、結果のテキストが Office で表示されるように、MIME の種類を使用することでこれらのファイルをクライアントにストリーム出力することができます。サーバー上で ASP を使用することにより、ドキュメントを編集したり保存したりするだけでなく、サーバーに返すこともできます。

これらのトピック、および実装方法の例の関連情報を参照するには、以下の「サポート技術情報」 (Microsoft Knowledge Base) をクリックしてください。 業務上、サーバーサイドで Office 97、Office 2000、Office XP、および Office 2003 のバイナリ ファイル形式を作成する必要がある場合は、サードパーティ ベンダが提供する役立つコンポーネントがあります。マイクロソフトはこのようなコンポーネントを提供しないため、自身でソリューションを構築するか、サードパーティ ベンダからソリューションを購入する必要があります。数多くのさまざまなサードパーティ製品が利用できます。すべてのソリューションを調べて、業務に最も合致するベンダを探すことをお勧めします。 Office 97、Office 2000、Office XP、および Office 2003 のバイナリ ファイル形式を直接編集する独自のソリューションを構築する必要がある場合は、Microsoft Open Specification Promise (OSP) の条項の下で無料であるファイル形式の仕様を入手できます。ユーザーが作成するドキュメントまたは製品に対するテクニカル サポートは提供されませんが、ドキュメントの利用は可能です。詳細については、以下の Web サイトを参照してください。また、サーバーサイド ソリューションでは、ファイルをアップロードすることをユーザーに許可し、Web などのメディアで表示するためにサーバーでファイルを作成することが必要な場合があります。現時点でマイクロソフトはこのような機能を提供するための作業を行っています。また Microsoft Excel Services でこの機能の初期バージョンを提供しています。

Excel Services は、Microsoft Office SharePoint Server 2007 に搭載されている新しいサーバー テクノロジで、Office SharePoint Server 2007 での Excel ブックの読み込み、計算、および表示を可能にします。Excel Services の詳細については、以下の MSDN (Microsoft Developer Network) Web サイトを参照してください。この資料で説明した方法のうち、どの方法が必要性を満たし、ソリューション展開に最善なものであるかを評価する必要があります。この資料で説明した内容によって、すべてのクライアントのあらゆる問題が解決されるかどうかは保証されません。十分にソリューションをテストしてから展開してください。