●米Microsoftは,使いやすさで勝るウインドウ・アプリケーションをWebアプリケーション並みに簡単に配布・管理できる仕組みを開発している。
●「ClickOnce」と呼ぶ仕組みで,自動的なバージョンアップも可能である。マニフェストと呼ぶ2つのXMLファイルを使って制御する。
●Visual Studio .NETの次期版は,マニフェストの自動生成機能を備える。

表1●Webアプリケーション,ウインドウ・アプリケーション,ClickOnceアプリケーションの比較
図1●ClickOnceアプリケーションの仕組み
スタート・メニューに登録されているアプリケーションを選ぶと((1)),サーバーにより新しいバージョンがないかを調べ((2)),もし新しいバージョンがあればその場でダウンロードし,インストールしてからアプリケーションが起動する((3))。インストール済みのアプリケーションが最新の状態なら,そのまま起動する。最初に実行するときは,ポータル・サイトからダウンロードしてインストールする。CD-ROMなどで配布してもよい。
図2●Visual Studio .NETの次期版(テクノロジ・プレビュー版)の設定画面
ClickOnceによってアプリケーションを配布するのに必要なマニフェストを自動生成できる。

 アプリケーションの管理をなるべく簡単にしたい――システム管理者ならば誰もが思うことだろう。そのため,最近の新しいシステムは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つのマニフェストがコピーされる。このときも古いバージョンを上書きすることはなく,複数のバージョンがサーバー上に存在することになる。配布場所のデプロイメント・マニフェストは最新版を指し示しているので,クライアントには最新版がダウンロードされる。

(山口 哲弘=yama@nikkeibp.co.jp)
出典:2004年4月号 11ページ
記事は執筆時の情報に基づいており、現在では異なる場合があります。