特集 .NETアプリケーション自動更新技術の比較 市川 龍太（Microsoft MVP 2005 − Solutions Architect） 2005/11/12

Page1 Page2 Page3

　企業システムにおけるアプリケーションの配布・更新は管理者にとって大きな問題である。業務アプリケーションの形態がクライアント／サーバ・アプリケーション（以下C/Sアプリ）からWebアプリケーション（以下Webアプリ）へと移り変わったのも、いまスマート・クライアントが注目されているのも、それが大きな要因の1つであることはいまさら説明するまでもない。

　結局のところ、多くの業務アプリケーションにおいては、自動配布とバージョンアップの際に必要な自動更新を備えたWindowsアプリケーションが、ユーザーや管理者にとって現実的でベストなソリューションといえるだろう。

　そしてこのソリューションを実現するために、.NETにはすでに何種類もの仕組みが用意されている。既存のクライアント／サーバ・システムに適応できるコンポーネントや、スマート・クライアントを実現するためノータッチ・デプロイメント、ClickOnceなどである。

　本稿ではこのような「アプリケーションの配布・更新」に関する問題を解決するための実現手法を紹介し、さらにそれらを比較することで各手法の最適な利用方法について解説していく。

　なお、本稿ではスマート・クライアントに分類されるVisual Studio Tools for Office（VSTO）ソリューション、InfoPath、Microsoft Office SystemのWord／Excelについては触れないが、興味があれば以下の記事を参考にするとよいだろう。

• Office 2003で変わる業務アプリケーション
• InfoPathの衝撃
• Office 2003のXMLスキーマ・サポートがもたらすインパクト

アプリケーションの配布方式

　本稿では、以下のアプリケーション配布技術について取り上げる。

• ノータッチ・デプロイメント
• Assembly.LoadFromメソッド
• .NET Application Updaterコンポーネント
• Updater Application Block 2.0（Enterprise Library対応版）
• ClickOnce

　これらの配布技術にはそれぞれ一長一短があり、用途に応じて向き不向きがあるのだが、まずはそれぞれの配布技術についての概要と、利用に当たってのメリットとデメリットを解説する。

●ノータッチ・デプロイメント

　ノータッチ・デプロイメントとは、IE（Internet Explorer）とWindowsシェル統合によって実現されているソフトウェア展開技術の総称であり、.NET Framework 1.1にはこのノータッチ・デプロイメントを使った自動更新機能がサポートされている*。

* 実際には.NET Framework 1.0からサポートされているが、デフォルトではこの機能がオフになっているため、実質的には利用できない。

　この機能を利用すればHTTP／HTTPSプロトコルを使用し、Webサーバから各クライアントに対してアプリケーションを配布することが可能になる。ノータッチ・デプロイメントの仕組みを簡単にまとめると以下のようになる。

1. 配布対象のプログラム（EXEファイル）をWebサーバ上に配置し、そのファイルへのリンクを任意のWebページに貼り付ける。ユーザーがIEでそのページを開き、リンクをクリックすることによりプログラムのダウンロードが始まる。

2. ダウンロードされたプログラムは、ローカル・マシンのアセンブリ・ダウンロード・キャッシュに配置され、その場所からIE実行シェル（IEExec.exe）により起動される（正確にはアセンブリ・ダウンロード・キャッシュに登録されるのはEXEファイルやDLLファイルなどのアセンブリのみであり、アプリケーション構成ファイル（<アプリケーション名>.exe.config）はIEのキャッシュに置かれる）。

3. 次回以降ユーザーがページのリンクをクリックすると、Webサーバ上のアセンブリ・ファイルが更新されていない場合にはアセンブリ・ダウンロード・キャッシュ内のプログラムが起動され、アセンブリ・ファイルが更新されている場合は自動的に更新処理が実行される。

　プログラムの実行に際しては、コード・アクセス・セキュリティ（以下CAS）と呼ばれる技術を使用してCLR（共通言語ランタイム）によりセキュリティ・チェックが行われる。このためプログラムでは、管理者や開発者が事前に割り当てたセキュリティ・ポリシーで許可された操作のみが実行できるようになっている。

【ノータッチ・デプロイメントを利用するメリット】

• .NET Framework 1.1でサポートされており、導入が簡単

• CASによるセキュリティ制限が適用できる

【ノータッチ・デプロイメントを利用するデメリット】

• CASによるセキュリティ制限によるローカル・リソースへのアクセス制限
  　デフォルトのセキュリティ・ポリシー（インターネット・ゾーン時）では、ファイルへの書き込み、レジストリへの読み書き、DB（データベース）アクセス、クリップボードからの読み込み、印刷出力、イベント・ログへの書き込みなどが実行できないようにローカル・リソースへのアクセスが制限されている。このため、これらの機能が必要なアプリケーションを配布する場合は、結局「Microsoft .NET Framework 1.1 構成」ツールなどを使って各クライアントのセキュリティ・ポリシーを変更する必要がある。

• オフラインでの実行が不可能
  　ユーザーが手動でIEの「オフライン作業」を設定した場合にのみ、アプリケーションをオフラインで使用できるが、アプリケーションからはこの設定を変更できない。

• 更新処理のロールバックができない
  　配布されるアプリケーションはファイル単位で更新が行われる。このため、いくつかのファイルの更新に失敗すると、異なるバージョンのファイルで構成されたアプリケーションを実行することになってしまう。

　ノータッチ・デプロイメントについてさらに詳細を知りたい場合は「特集：ノータッチ・デプロイメント」が参考になるだろう。

●Assembly.LoadFromメソッド

　.NET Frameworkのクラス・ライブラリにはアセンブリを扱うためのAssemblyクラスが用意されている。このクラスはSystem.Reflection名前空間に属するクラスであり、そのLoadFromメソッドは任意のアセンブリ・ファイルをアプリケーションの実行時に動的に読み込むことができる。使い方は簡単でLoadFromメソッドのパラメータに読み込みたいアセンブリ・ファイルへのパスを渡すだけである。

System.Reflection.Assembly asm =     System.Reflection.Assembly.LoadFrom (@"C:\Download\Test.dll");

AssemblyクラスのLoadFromメソッドの利用例（C#）

　この例ではパラメータとしてUNCパスを渡しているが、ここにWebサーバ上に配置したファイルのURLを指定することで、ノータッチ・デプロイメントと同様にHTTP／HTTPSプロトコルを使用してWebサーバ上のファイルを読み込むこともできる。

　この仕組みを利用すれば、更新対象となるアセンブリ・ファイルをWebサーバに配置することにより、ファイアウォールを越えてアプリケーションの配布が可能になる。

　この場合、.NET Frameworkは目的のアセンブリがクライアント上に存在するかどうかを、アセンブリ・ダウンロード・キャッシュをチェックすることによって確認し、アセンブリ・ファイルがそこにない場合は、Webサーバからそのアセンブリ・ファイルを取得し、アセンブリ・ダウンロード・キャッシュにコピーが作成されるという仕組みになっている。

　アセンブリ・ダウンロード・キャッシュにコピーされているアセンブリ・ファイルは、グローバル・アセンブリ・キャッシュ・ツール（Gacutil.exe）にldlオプションを指定することで確認することができる。

gacutil.exe /ldl

アセンブリ・ダウンロード・キャッシュの確認方法（コマンドライン）

【Assembly.LoadFromメソッドを利用するメリット】

• ノータッチ・デプロイメントよりも、より柔軟な更新制御が可能

• DLLファイルやCABファイルをダウンロードすることが可能

【Assembly.LoadFromメソッドを利用するデメリット】

• 自動更新処理の振る舞いを変更したい場合は、ソース・コードを修正する必要がある

• オフラインでの実行が不可能

• 事前に初期バージョンのアプリケーションをクライアントに配置しておく必要がある

INDEX
	[特集] .NETアプリケーション自動更新技術の比較
	1. ノータッチ・デプロイメント、Assembly.LoadFromメソッド
	2. .NET Application Updaterコンポーネント、Updater Application Block 2.0
	3. ClickOnce、各自動更新技術の比較

　

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

は.NET開発者中心に生まれ変わりました