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

●ClickOnce

　すでに米国でリリースされた.NET Framework 2.0には、ClickOnceという機能が新しくサポートされた。

　ClickOnceは、上述したAppUpdaterの考え方とWindowsインストーラ（MSIファイル）のインストール・パッケージを組み合わせた思想がベースになっているため*、WindowsインストーラやAppUpdaterの良い部分を取り込み、従来のノータッチ・デプロイメントを発展させたような仕組みになっている。

* これはAppUpdaterを開発したJamie Cool氏が現在ClickOnceチームに在籍していることも影響していると思われる。

　ClickOnceを利用できるのは.NET Framework 2.0上のみという制限は付くものの、従来のC/Sアプリが抱えていた配布の問題を随分と緩和してくれる機能であることは間違いない。

　ClickOnceを詳細に解説するとなると、それだけでかなりのボリュームになってしまうため、本稿ではClickOnceのメリットとデメリットだけをまとめておく。さらに詳細を知りたい場合は、以下のサイトが参考になるだろう。

• 「ASP.NET 2.0が変えるWebアプリ開発の世界」の「強化版ノータッチ・デプロイメント『ClickOnce』」の項

• Visual Studio 2005 技術情報 : 配置と配布

【ClickOnceを利用するメリット】

• アプリケーションへのショートカットが自動的に［スタート］メニューに登録される

• Webサーバ上のファイルが更新されているかどうかを自動的にチェックする。アプリケーションを、Webページのリンクから実行したときだけでなく、［スタート］メニューから起動した場合も、Webサーバにアクセスして更新状況をチェックし、更新されている場合は自動的に更新する

• CASによるセキュリティ・ポリシーをアプリケーション側で変更することができる。正確には、アプリケーション・マニフェストに記述されたいずれかの権限をアプリケーションに付与することができる

• ブートストラッパを使って.NET FrameworkやMDACのような、.NETで作成したアプリケーションの実行に必須なコンポーネントの自動セットアップが可能

• アプリケーションを以前のバージョンにロールバックすることができる

• 実装に必要な機能がVisual Studio 2005に統合されているため、各種設定をウィザードによって簡単に設定できる

• オフライン実行可能

【ClickOnceを利用するデメリット】

• 更新対象ファイルの選択ができない

各自動更新技術の比較

　ここまでで各自動更新技術の概要について解説してきたわけだが、では実際の業務アプリケーションの開発において一体どの更新技術を利用すればよいのだろうか？

　もちろん各自動更新技術はそれぞれに一長一短があり、しかも一口に業務アプリケーションの開発といっても、実際には業務要件がそれぞれ異なるわけで、一概にこれが1番よいとはいえないのだが、ここからはいくつかの条件下でどの自動更新技術を利用するのがベストなのかについて筆者なりの意見を述べていく。

　まず各自動更新技術を機能別に比較した表が以下になる。

機能	ノータッチ	LoadFrom	AppUpdater	UAB2.0	ClickOnce
オフライン実行			○	○	○
Webアプリ連携	○				○
マイクロソフトのサポート	○	○			○
CASによるセキュリティ制限	○	○			○
既存アプリへの影響度	小	中	大	大	小
更新対象ファイルの選択			△*1	○
ダウンロード後の任意処理の実行				○
スタート・メニューへの登録					○
以前のバージョンへのロールバック					○
必須コンポーネントのインストール					○
ファイル監視機能			○	○
リジューム機能				○
自動更新技術の機能別比較表
機能として分かりにくいものについては、以下で簡単に解説している。 ・Webアプリ連携とは、Webページからプログラムを直接実行できるかどうかを表している（例えばノータッチ・デプロイメントとClickOnceはWebページのリンクをクリックするだけでプログラムを起動できる）。 ・既存アプリへの影響度とは、既存のC/Sアプリに自動更新機能を追加実装する場合の作業コストや修正範囲などの影響度である。 ・ファイル監視機能とは、更新用のプログラムが更新対象のフォルダを常時監視して（AppUpdaterはstartup.exeが監視を行い、UAB2.0はWindowsサービスに登録した場合に監視を行う）、フォルダの中のファイルが更新されている場合は自動的に更新イベントを発生させる機能である。 ・リジューム機能とは、ダウンロード中に処理を中断しても次回実行時では差分のみをダウンロードできる機能である。 *1 UAB2.0は更新対象ファイルをManifest Editor Toolで選択可能だが、AppUpdatorの場合は、更新元フォルダへのファイルの配置でしか選択が行えないため（配置されているファイルのみ更新される）。

　ノータッチ・デプロイメントはアプリケーションをWebサーバ上に配置してしまえば、後はダウンロード用のページにそのアプリケーションのEXEファイルへのリンクを張るだけというシンプルな仕組みであるため、既存のアプリケーションを変更することなく自動更新機能を導入したい場合や、Webアプリと連携したい場合などに用いるとよいだろう。

　しかしオフライン実行ができないことや、特にCASのセキュリティ制限が掛かってしまうことから、クライアント環境のポリシーを変更しない限りデフォルトではほとんど使いものにならないことが多い。また、ダウンロード中は何もできなくなってしまうため、回線速度が貧弱な場合には注意する必要がある。

　Assembly.LoadFromメソッドはプログラムから更新処理を制御するため、例えばユーザーとアプリケーションが対話しながらアセンブリ・ファイルを少しずつダウンロードしていくような、ノータッチ・デプロイメントよりも柔軟な更新処理を行うことが可能になる。

　しかし更新処理そのものの振る舞いを変更したい場合はソース・コードを変更しなければならないため、Assembly.LoadFromメソッドはノータッチ・デプロイメントの更新処理をある程度カスタマイズしたい場合などに使うことになるだろう。

　AppUpdaterとUAB2.0はどちらも自動更新処理用のコンポーネントとして提供されており、ノータッチ・デプロイメントやAssembly.LoadFormメソッドと違ってオフライン時でもアプリケーションの実行を行うことができる。また、マイクロソフトの正式サポートはないものの、どちらもソース・コードが公開されているので自由に柔軟な拡張が行えるというメリットがある。

　両者の相違点としては、AppUpdaterではVS.NETのツールボックスに登録することでデザイン・ビューから各プロパティ設定を行うのに対して、UAB2.0ではConfigurationコンソールやManifest Editor ToolなどのGUI構成管理を利用することができる。

　このように、運用面の点に関してはUAB2.0の方が非常に柔軟な設定が可能になっているといえる。AppUpdaterだと構成ファイル自体を手動で記述しなければならないため、単純に両コンポーネントの機能だけを比較するとAppUpdaterを利用するメリットはそれほどないように思える。しかしUAB2.0は豊富な機能を持っている半面、AppUpdaterと比べるとやや複雑な仕組みになっており、しかもEntLibに依存することから.NET Framework 1.1上でしか使えない。

　これらのことから、AppUpdaterはUAB2.0ほどの機能を必要としない場合や、.NET Framework 1.0上で開発を行っている場合などに使うとよいだろう。

　UAB2.0は仕組みが複雑なだけあってやや導入の敷居は高いが、その分ほかの自動更新技術にはない多くの機能を備えている。中でもActivation Processor機能はダウンロード後に必要に応じて任意の処理を実行することが可能だ。例えばダウンロードしたアセンブリ・ファイルのGAC（Global Assembly Cache：グローバル・アセンブリ・キャッシュ）への登録、フォルダやファイルの操作、MSIインストーラ実行などさまざまな処理を実行することができる。

　このほかにもBITSを使ったダウンロード機能やWindowsサービスを使ったファイル監視機能などがあるが、何といってもUAB2.0の最大の特徴はEntLib対応になったことで、UAB1.0では手動だった構成管理をGUIのConfigurationコンソールである程度自動的に行えるようになったことだ。そして何よりも、ほかのEntLib対応のApplication Blockと同様の柔軟な拡張性を持つに至ったことだといえるだろう。

　確かにUAB2.0には、デフォルトではBITSを使ったダウンローダーしか実装されていないという制限も存在するが、付属のドキュメントにはUNCパス用のダウンローダーやレジストリ登録を行うActivation Processorのサンプルなどが掲載されていることからも拡張性の高さがうかがえる。

　これらの特徴から、UAB2.0はファイルの更新処理以外にもいろいろな処理を1度に行いたい場合などでは、唯一の選択肢といえるだろう。

　最後はClickOnceだが、結論からいえば.NET Framework 2.0上での開発であればアプリケーションの初期配布において、これ以上の選択肢はないだろう。ClickOnceはVisual Studio 2005に統合されていることから、導入に当たっての構成管理をウィザードを使った対話形式で進めることができる。さらには、従来のノータッチ・デプロイメントやカスタムの自動更新処理が抱えていた問題（セキュリティ、オフライン実行など）も解決していたりと、まさにアプリケーション配布の正当な進化系といえる。

●各自動更新技術のセキュリティ

　各自動更新技術のうち、ノータッチ・デプロイメント系（Assembly.LoadFromメソッドも含む）では、アプリケーションがアセンブリ・ダウンロード・キャッシュにインストールされるため、部分信頼アプリケーションとしてCASによるセキュリティ・チェックが行われる。

　これは悪質なプログラムによるローカル・リソースへのアクセスを制限することができるが、通常のアプリケーションにとっては逆に大きな足かせとなる。

　これに対してコンポーネント系（AppUpdater、UAB2.0）はアプリケーションが任意の場所にローカル・インストールされるため、完全信頼のアプリケーションとなる。この場合にはCASによるセキュリティ・チェックが行われず、悪質なプログラムであっても何ら制限を加えられないという問題が残る。

　もちろんその半面、基本的にはクライアントのセキュリティ・ポリシーを変更しなくてもアプリケーションはローカル・リソースへ自由にアクセスすることができる。

　これらに対してClickOnceは、ローカル・インストールされるにもかかわらずCASをサポートしており、さらにアプリケーション・マニフェストが発行者によって署名されている場合は、アプリケーション配置の際に特定のアプリケーションに対する権限を動的に変更（権限の昇格）することができる。

　自動更新技術の選択に当たってはこれらのCASに絡むセキュリティ制限についても考慮する必要があるだろう。

■

　本稿で取り上げた更新技術以外にも、アプリケーションの自動更新にはいくつかの方法がある。例えばマイクロソフトが提供するシステム管理用サーバのSystem Management Server 2003を使う方法や、マイクロソフト・アーキテクト・エバンジェリストの荒井省三氏によって提案された「クライアント・アプリケーション自動更新メカニズムの提案」のサンプル・アプリケーションを活用する方法などである。

　C/Sアプリの導入に当たっては、真っ先に議論される項目の1つがアプリケーションの配布にかかるコストの問題であることが多い。その結果ユーザーからC/Sアプリ並みのリッチなUIをWebアプリに求められ、随分と開発に苦労したプロジェクトも多いことだろう。

　しかしここで挙げた更新技術をうまく用いればC/Sアプリ導入に当たっての開発コストと運用コストを低減させることができ、結果としてユーザビリティの向上へとつなげることができるだろう。本稿が少しでもその手助けとなったなら幸いである。

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

　

更新履歴

【2006/04/03】以下のような記述がありましたが、これは原稿執筆時点の.NET Framework 2.0 ベータ版での ClickOnceに関するもので、最終的な.NET Framework 2.0 RTM版ではこの制限はなく なったため、記述を削除しました。なお.NET Framework 2.0 RTM版では、更新されていないアプリケーション・ファイルはローカル環境内で自動的にコピーされ、それ以外の更新されたアプリケーション・ファイルのみがダウンロードされるという差分ダウンロー ドがサポートされています。 削 除 　しかしClickOnceを使った更新処理は、初期配布後の自動更新時に問題になる場合がある。 　これはどういうことかというと、仮にA.exe、B.dll、C.dllという3つのアセンブリ・ファイルで構成されるアプリケーションがあったとして、その後の更新でB.dllのバージョンだけが上がっていたとしても、ClickOnceは更新対象となるファイルを個別に指定することができない。このため、常にすべてのアセンブリ・ファイルをダウンロードしなければならないのである。これはアプリケーションのサイズが比較的大きく、さらに同時にダウンロードしてくるユーザー数が多い場合などに、パフォーマンスの問題を引き起こす恐れがあるという点に注意する必要があるだろう。

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