●米Microsoftは，使いやすさで勝るウインドウ・アプリケーションをWebアプリケーション並みに簡単に配布・管理できる仕組みを開発している。
●「ClickOnce」と呼ぶ仕組みで，自動的なバージョンアップも可能である。マニフェストと呼ぶ2つのXMLファイルを使って制御する。
●Visual Studio .NETの次期版は，マニフェストの自動生成機能を備える。
| ||
| ||
|
アプリケーションの管理をなるべく簡単にしたい――システム管理者ならば誰もが思うことだろう。そのため，最近の新しいシステムはWebアプリケーション＊として構築される例が多くなってきた。Webアプリケーションならクライアントにインストールする作業は必要ないし，バージョンアップ時はサーバーのアプリケーションだけを更新すれば済むからだ。
だが，うっかりBack Spaceキーを押すと前のページに戻って入力したデータが消えてしまったり，通信異常があると処理が中断してしまったりするなど，Webアプリケーションの操作性は必ずしもよいとはいえない（表1[拡大表示]）。
米Microsoftが開発中の「ClickOnce（クリックワンス）」と呼ぶ仕組みを使えば，通常のウインドウ・アプリケーションを，Webアプリケーション並みに簡単に配布・管理できる。特別なロジックを作り込む必要はない。通常の.NET＊対応ウインドウ・アプリケーションとして開発するだけで，サーバーを配布場所とし，自ら自動的にバージョンアップするクライアント・アプリケーションを作れるようになる。
ClickOnceは次期Visual Studio .NET＊（開発コード名Whidbey）で開発したウインドウ・アプリケーションを，配布・実行する1つの形態である。利用するには，クライアントに，2004年末から2005年初頭に出荷が始まる予定の.NET Framework＊ 2.0が必要である。一方，配布場所のサーバーには.NET Framework 2.0は不要で，WebサーバーやFTPサーバー，ファイル・サーバーなど，既存のシステムをそのまま利用可能である。
配布・管理の手間を軽減させるノータッチ・デプロイメントの進化形
アプリケーションの配布・管理の手間を軽減させるというClickOnceのコンセプトは，現在の.NET Framework 1.0/1.1のノータッチ・デプロイメントと同じだ。ClickOnceは，このノータッチ・デプロイメントをさらに発展させた仕組み。アプリケーションをクライアントにインストールし，バージョン管理機能を備える点が違う（設定によってクライアントにはインストールせずに，毎回ダウンロードして実行させることも可能）。
ClickOnceアプリケーションを最初にインストールする作業は，利用するユーザー自身が実行する。例えば，社内ポータルなどのWebサイトを使って配布する場合は，システム管理者があらかじめ作っておいたWebページ上のハイパー・リンクをユーザーがクリックすると，アプリケーションがサーバーからダウンロードされ，クライアントにインストールされる。インストール場所は各ユーザーのプロファイル情報を格納するフォルダ（標準のWindows XPの場合はC:\Documents and Settings）の中なので，管理者権限がないユーザーでもインストールできる。1つのクライアントPCを複数のユーザーで共用していても，アプリケーションはユーザーごとに別々にインストールされる。
バージョンアップ時には，管理者がサーバーの配布場所に置いたアプリケーションを更新するだけで済む。インストール後はスタート・メニューのアイコンから起動でき，そのときに最新版の存在をチェックする。サーバーに，より新しいバージョンがあればそれをインストールするよう促すメッセージが表示され，インストールを選べばローカルに新バージョンがインストールされて起動する（図1[拡大表示]）。
このとき古いバージョンを上書きせず，複数のバージョンが共存する。万が一，新バージョンに不具合が生じても，ユーザーはコントロール・パネルの［アプリケーションの追加と削除］で古いバージョンに戻せる。古いバージョンに戻したときは，配布場所のアプリケーションがさらに新しいバージョンにならない限り，新版のインストールを促すメッセージは出ない。
なお，ClickOnceアプリケーションを起動するとき，必ずしも配布場所のサーバーにアクセスできる必要はない。配布場所のサーバーがダウンしていたり，ノートPCなどを持ち歩いていたりしてオフラインで利用しているときでも，ローカルにインストール済みのアプリケーションを起動できる。
開発者と管理者が用意する2つのマニフェスト・ファイル
以上のような仕組みを可能にするため，ClickOnceでは「マニフェスト」と呼ぶXML＊ファイルを使う。自動的なバージョンアップなどは，マニフェスト・ファイルに記述された内容に従って実行される。
マニフェストには，「デプロイメント・マニフェスト」と「アプリケーション・マニフェスト」の2つがある。これら2つのマニフェストはClickOnceの“設定ファイル”ともいえる。アプリケーションを配布するときには，2つのマニフェスト・ファイルを，アプリケーションの実行ファイルと一緒にサーバーに置いておく。Webサイトで配布するときには，デプロイメント・マニフェストへのハイパー・リンクをWebページに作っておく。
デプロイメント・マニフェスト（拡張子.deploy）は，アプリケーションの配布を制御するためのものである。クライアントからサーバーへアプリケーションの更新をチェックする頻度などの設定が可能だ。アプリケーションのショートカット＊の役割も担っており，スタート・メニューに登録されるのはこのファイルである。サーバーにあるものがより新しいかどうかは，.NETの実行ファイル（アセンブリ）に埋め込まれているアセンブリ・バージョンによって判断される。
もう1つのアプリケーション・マニフェスト（拡張子.manifest）はセキュリティなどを制御するのに使う。これは通常の.NETアプリケーションと同じだ。.NETには元々ゾーンという概念があり，ゾーンに応じてアプリケーションの機能を制限できるようになっている。コード・アクセス・セキュリティと呼ぶセキュリティ機構によって，たとえ管理者権限を持ったユーザーが実行してもローカルのリソースを制御できないようにすることが可能だ。
例えば標準設定では，ClickOnceで配布したアプリケーションはローカルのファイルにアクセスできない。実行時にセキュリティ・エラーが発生する。だがアプリケーション・マニフェストの内容を変更すれば，プログラム・コードに手を加えなくてもアクセスできるようになる。同一ユーザーが，同一の環境で使う場合でも，アプリケーションに対して振る舞いを制限できる。適切に設定すれば，よりアプリケーションを安全に実行できる。
Whidbeyならマニフェストと公開ポイントを自動生成
.NET Framework 2.0と同時に出荷が予定されているWhidbeyを使えば，マニフェスト・ファイルや，アプリケーションを公開するWebページなどを自動生成できる。
Whidbeyではデプロイメント・マニフェストの内容を，プロジェクトのプロパティ・ページで設定する（図2[拡大表示]）。ここでは，アプリケーションの公開ポイントやインストール・モードなどを設定する。
インストール・モードでは，ローカルにインストールせずに毎回ダウンロードして起動するようにするかどうか（この場合はオフラインでは起動できない），ローカルにインストールしたときの新版を調べる頻度などを設定する。直接デプロイメント・マニフェストのXMLデータを編集すれば，さらに細かい設定が可能である。この作業は主にシステム管理者が担うことになるだろう。
完成したアプリケーションを公開するのもWhidbeyを使えば簡単だ。［Publish］メニューを使うと，公開ポイントに実行ファイルと2つのマニフェストがコピーされる。このときも古いバージョンを上書きすることはなく，複数のバージョンがサーバー上に存在することになる。配布場所のデプロイメント・マニフェストは最新版を指し示しているので，クライアントには最新版がダウンロードされる。
