発行ウィザードを使わない場合でも、ClickOnce発行のための基本設定は同じだ。次の画面はプロジェクト・プロパティの[発行]ページでその基本設定を行っているところだ。
基本的なClickOnce発行手順
プロジェクト・プロパティの[発行]タブを開いて、ClickOnce発行のための基本設定を行っているところ。
(1)発行場所の指定は、先ほどの発行ウィザードの場合と同じだ。[...]ボタンをクリックすると、「発行するパス/URLを指定するための参照用ダイアログ」(=[Web サイトを開く]ダイアログ)が表示される。
(2)配置場所(=インストールのURL)の指定も、先ほどと同じだ。
(3)インストール・モードの指定も、先ほどと同じである。
(4)発行するバージョン(以降、発行バージョン)は、ClickOnceでのバージョン管理で使用されるバージョンのことで、実際のアセンブリ・バージョンとは異なる(だが、基本的にこの両者はそろえておいた方が混乱が生じなくてよいだろう)。またここで指定したバージョン番号は、前回の「ClickOnceアプリのフォルダ/ファイル構成」で説明したフォルダ名やファイル名にも使用される(ちなみに同じように名前として使用されるアセンブリ名は、プロジェクト・プロパティの[アプリケーション]ページの[アセンブリ名]の値が使われている)。なお[発行ごとにリビジョンを自動的にインクリメントする]にチェックを入れておくと、発行が完了するたびにリビジョン番号が1つずつ増えていく。
(5)[アプリケーション ファイル]ボタンをクリックすると、[アプリケーション ファイル]ダイアログが表示される(詳細後述)。
(6)[必須コンポーネント]ボタンをクリックすると、[必須コンポーネント]ダイアログが表示される(詳細後述)。
(7)[更新]ボタンをクリックすると、[アプリケーションの更新]ダイアログが表示される(詳細後述)。
(8)[オプション]ボタンをクリックすると、[発行オプション]ダイアログが表示される(詳細後述)。
(9)[今すぐ発行]ボタンをクリックすると、即座に発行作業が開始され、(先ほどの発行ウィザードと同様に)[出力]ウィンドウにその内容が出力される。
(9)の[今すぐ発行]ボタンをクリックすると、即座に発行作業を実行できる。
なお、ここで指定する[発行]ページの内容は先ほどの発行ウィザードとほぼ同じなので詳細な説明は割愛する(ちなみに発行ウィザードで実際に発行を行うと、その設定内容が自動的に保存されて、ここの基本設定に反映される)。違うのは、発行バージョンが指定できることだ。発行バージョンは、ClickOnceアプリの発行をバージョン管理するためのもので、新しい発行を行う場合にはその発行バージョンを必ずインクリメントしなければならない。
ClickOnceテクノロジでは、さまざまなアプリケーションの配置と更新のオプションが提供されており、アプリケーション利用者のネットワーク環境などに合わせた配置/更新ストラテジを(配置/更新オプションとして)適切に選択できるようになっている。これらは、上記の画面の(5)(6)(7)(8)の各ボタンから実行される機能により指定できる。
まずは(8)の[オプション]ボタンをクリックすると表示される[発行オプション]ダイアログで設定できる配置オプションの内容から見ていこう。
●配置オプション
次の画面は[発行オプション]ダイアログを表示したところだ。
ClickOnce配置の発行オプションの設定
プロジェクト・プロパティの[発行]ページで[オプション]ボタンをクリックして、[発行オプション]ダイアログを表示したところ。このダイアログで配置(=配布)に関するオプション設定を行える。
(1)多言語対応アプリケーションの場合、発行するClickOnceアプリの言語コードを指定することができる。これにより適切な言語コードのサテライト・アセンブリが配布されることになる。多言語対応アプリケーション以外の場合、「(既定値)」のままで変更する必要はない。
(2)発行者名(=基本的には会社名)を指定する。指定しない場合、Windows OSに登録している会社名が暗黙的に代用される。この情報は、ClickOnceアプリ・インストール用のWebページのタイトル項目名やコントロール・パネルの[プログラムの追加と削除]での項目名となる。
(3)製品名。指定しない場合、アセンブリ名が暗黙的に代用される。この情報も、ClickOnceアプリ・インストール用のWebページのタイトル項目名やコントロール・パネルの[プログラムの追加と削除]での項目名となる。
(4)サポートURL(=製品のサポート情報を掲載しているWebサイトのURL)を指定する。この情報は、ClickOnceのインストールや更新中に表示されるダイアログやコントロール・パネルの[プログラムの追加と削除]での項目のサポート情報として使われる。さらに、[スタート]メニューに[<製品名> オンライン サポート]というショートカット項目が追加され、それを選択して実行すると、サポートURLがWebブラウザにより開かれる。
(5)配置Webページは、ここまで「ClickOnceアプリ・インストール用のWebページ」と呼んでいたものである。デフォルトでは、「publish.htm」という名前のファイルが自動的に生成され、配置後にInternet Explorer(Webブラウザ)で開くようになっている。ここで、ファイル名を変更したり、自動生成の有無、配置後のWebブラウザ表示の有無などを切り替えたりできる。
(6)デフォルトはオフになっているが、これをオンにすると、配置Webページ(=ClickOnceアプリ・インストール用のWebページ)の[インストール]ボタン(や[起動]というリンク)をクリックしても、ClickOnceアプリのインストールはできるが、「アプリケーションのデスクトップ アイコンをクリックするか、[スタート]メニューから選択してください」というメッセージが表示されて起動ができなくなる(ちなみにデスクトップへのショートカット・アイコンはClickOnceでは作成されない)。また、これがオフの場合は、ClickOnceアプリをインストールした後、それが自動的に実行されるが、これがオンの場合には「アプリケーションのインストールが正常に完了しました。[スタート]メニューからアプリケーションのライセンス認証を行えます。」というメッセージが表示されて、アプリケーションは実行されない。
(7)これにチェックが入っていると(デフォルト)、ClickOnceで配布するすべてのアプリケーション・ファイルの名前に「.deploy」というサフィックス(=拡張子)を付ける。これは前回でも説明したように、セキュリティ上の対策である。
(8)URLに含めたクエリ文字列パラメータをコマンドライン引数としてアプリケーションに渡せるようにするかどうかを指定する。デフォルトではオフになっている。実際にコマンドライン引数として利用する方法は次回以降で説明しよう。
(9)配置場所として「(C)CD-ROM/DVD-ROMなどのローカル環境上の場所」を選択した場合にオンにする(デフォルトはオフ)。これにチェックを入れると、autorun.infファイルが生成されるようになる。このautorun.infはCD-ROMなどのメディアをドライブに挿入した際に自動的にセットアップを起動させるために必要となる(詳細後述)。
(10)これがオンの場合、すべてのファイルが発行場所に配置された後、それらが配置場所(=インストールのURL)からダウンロード可能かチェックする。チェック状態は、[出力]ウィンドウに「WindowsApplication1.exe.deploy を確認しています... (4 / 5)」のように表示される。ダウンロードできないファイルについては、出力ウィンドウで「警告: 'WindowsApplication1_1_0_0_0/WindowsApplication1.exe.deploy' を http://dapc88/WindowsApplication1/ からダウンロードできませんでした。」のように表示される。
配置オプションの指定で注意すべき点の1つは、配置場所として「(C)CD-ROM/DVD-ROMなどのローカル環境上の場所」を選択した場合に、(デフォルトではオフとなる)(9)の[CD からインストールする場合、CD が挿入されるときにセットアップを自動的に開始する]にチェックを入れた方がよいことだ。これによりautorun.infファイルが生成されるようになる。
CD-ROMやDVD-ROMなどのメディアでClickOnceアプリを配布する場合、発行場所として指定したディレクトリ・パス(=フォルダ)に生成されたすべてのファイルを、CD-ROMやDVD-ROMなどのメディア(基本的にそのルート)に焼く。そのメディアをドライブに挿入すると、もしメディアのルートにautorun.infファイルがあれば、(Windowsのデフォルト設定では)その記述内容に従った処理が実行される。このautorun.infファイルには、setup.exeファイル(=ClickOnceアプリのインストーラ)を実行するように記述されているため、自動的にClickOnceのインストーラが走るようになるわけだ*1。
*1 ただし(現在の)日本語版ClickOnceでは、生成されるこのautorun.infファイルの文字コードがUTF-8(BOM付き)になっているため、実際には自動起動されないという問題がある。これを回避するには、手動でautorun.infの文字コードを日本語Windowsのデフォルト文字コードであるShift-JISに変更する必要がある。
そのほかの各項目の内容については上記の説明を参照してほしい。
●更新オプション
次に[更新]ボタンをクリックすると表示される[アプリケーションの更新]ダイアログで設定できる更新オプションの内容を見てみよう。次の画面は実際に[アプリケーションの更新]ダイアログを表示したところだ。
ClickOnceの更新オプションの設定
プロジェクト・プロパティの[発行]ページで[更新]ボタンをクリックして、[アプリケーションの更新]ダイアログを表示したところ。このダイアログで更新に関するオプション設定を行える。
(1)ここにチェックを入れると、アプリケーションの更新を確認するようになる(=アプリケーションの自動更新を行うようになる)。デフォルトでここはオンになっている。このオプションは、例えば更新する必要のない電卓のようなアプリケーションなどでの配布で役立つだろう。なお、配置場所として「(C)CD-ROM/DVD-ROMなどのローカル環境上の場所」を選択した場合は、注意が必要だ。具体的には、(5)の[更新の場所]を指定しない場合、[このアプリケーションの更新を確認]のチェックを外す必要がある。というのも、(5)の[更新の場所]を指定しない場合、配置場所(=インストールのURL)と同じURLが使われるが、CD-ROMなどからインストールした場合、基本的にその配置場所がネットワーク上にないからだ。前回でも述べたが、更新は常にネットワークからしか行うことができない。
(2)アプリケーションの更新を確認する方法を、[アプリケーションの開始後に行う]もしくは[アプリケーションの開始前に行う]から選択する。デフォルトで選択されるのは、アプリケーションの開始前(=起動時)に更新を確認する後者の方法だ。アプリケーション起動時に更新の確認を行う場合、毎回の起動時に更新を行う(更新確認のタイミングは変えられない)。一方、アプリケーションの開始後(=実行中)に更新を確認する前者の方法の場合、更新確認のタイミングを(3)の「更新の確認を実行する頻度」の設定によりカスタマイズできる。
(3)アプリケーション開始後に更新の確認を行うように設定し場合、その更新確認の頻度を指定できる。頻度としては、毎回もしくは一定期間おき(例えば、3時間おき、3日おき、3週間おきなど)を指定できる。
(4)[このアプリケーションに最低限必要なバージョンを指定してください]というオプションはデフォルトでオフとなっているが、これをオンにすると、ユーザーに更新(のためのバージョン・チェック)を回避できないように強制すること(=必須更新。ユーザーに更新を行うかどうかを尋ねずに自動的に更新すること)ができる。これは、次回の実行からは必ず最新バージョンを使用してもらうよう、ユーザーに徹底する必要性があるときに役立つ(例えば旧バージョンのソフトウェアに致命的なバグが見つかってしまい、一刻も早くユーザーに最新バージョンに切り替えてもらう必要がある場合など)。注意点として、更新の強制を利用する際には(2)で[アプリケーションの開始前に行う]オプションを選択しておかなければ、必須更新の意味があまりないことが挙げられる。もちろん[アプリケーションの開始後に行う]オプションを使っても必須更新を行うことは可能だが、旧バージョンを確実に実行できなくするためには、起動時に毎回、更新を確認する選択が不可欠となる。
(5)更新用のClickOnceアプリを置く場所(=更新場所)をURLやUNCパスで指定する。指定しない場合、配置場所に指定されたURLやUNCパスで代用される。
この更新オプションで注意すべきなのは、(2)の「アプリケーションの更新を確認する方法」と(3)の「更新を確認する頻度」の指定だ。これらの指定は、あくまで更新<確認>のタイミングを指定するためのもので、実際の<ダウンロード>と<アップデート>のタイミングを指定するものではない。ClickOnceでは更新処理(ダウンロードとアップデート)は基本的に起動時に行われる。これは現在のClickOnceではBITS(バックグラウンド・インテリジェント転送サービス)などに対応していないため、暗黙的にアプリケーション全体をダウンロードする機能が弱いためだ。
アプリケーションの開始前(=起動時)に更新の確認を行う場合、アプリケーションを起動する前に明示的にサーバに確認しに行き、更新がある場合はすぐにユーザーに通知する。一方、アプリケーションの開始後(=実行中)に更新の確認を行う場合は、アプリケーションの実行中にバックグラウンドで暗黙的にサーバにアクセスして、更新がある場合は<次回>起動時にユーザーに通知する。このため、どちらの場合も基本的に、起動時にユーザーの承認を得て、アプリケーションの更新を行うのである。
なお、ClickOnceではこのような定期的な更新確認だけではなく、System.Deployment名前空間のAPIを用いて更新確認のコードをClickOnceアプリ内に実装することで、任意のタイミングで更新確認を行うことも可能だ(プログラミング方法は次回以降で紹介)。
これらの更新確認のタイミングを選択する基準を次の表にまとめた。
更新確認のタイミング |
選択基準 |
(a)アプリケーション起動時に毎回確認 =(1)[アプリケーションの開始前に行う] →確認後すぐにダウンロードして更新する。 |
高速なネットワークに接続されていて、軽量なアプリケーションの場合に最適(※低速な接続で使用すると、アプリケーションの起動が異様に遅くなる可能性がある)。ClickOnceアプリの更新を確実に行わせたいようなクリティカルな状況ではこれを選択しなければならない。VS 2005のClickOnceではデフォルトでこれが選択される |
(b)アプリケーション実行中に定期的に確認 =[アプリケーションの開始後に行う] →次回起動時にダウンロードして更新する。 |
起動時の確認作業を省くことで起動スピードを上げられるので、低速なネットワークに接続されている大規模なアプリケーションの場合に最適。実行中にバックグランドで更新を確認するので、特にオフライン利用時にスムーズにアプリケーションを利用できるようになる。また、たいていの場合は、それほど頻繁にアプリケーションが更新されるわけではないので、一定期間ごとの更新チェックでも十分だと考えられる |
(c)任意のタイミングで確認 →任意のタイミングでダウンロードして更新する。 |
アプリケーションの更新タイミングを完全に制御したい場合に最適。例えば、ユーザーごとに異なる更新方法が必要な場合など |
更新確認方法の選択基準 更新確認のタイミングを決めるうえで、その基準となりそうなものをまとめた。 |
●アプリケーション・ファイルとダウンロード・グループ
次に[アプリケーション ファイル]ボタンをクリックすると表示される[アプリケーション ファイル]ダイアログについて説明しよう。次の画面は実際にそれを表示したところだ。
アプリケーション・ファイル(&ダウンロード・グループ)のオプション設定
プロジェクト・プロパティの[発行]ページで[アプリケーション ファイル]ボタンをクリックして、[アプリケーション ファイル]ダイアログを表示したところ。一覧表にClickOnceアプリとして配布されるすべてのファイルが表示される。
(1)[発行の状況]列でファイルの配布形態を選択する。選択できる項目は基本的に「追加」「データ ファイル」「除外」である。また、「必須コンポーネント」という選択項目が現れる場合がある。これらの配布形態は、拡張子などに基づき自動的に選択されている。自動選択された項目には「(自動)」という表記が後ろに付くのですぐに分かる。
(2)[ダウンロード グループ]列では「(必要)」「(新規作成)」と既存の「<グループ名>」(この例では「DownloadLater」というグループがある)からグループを選択できる。基本的に「(必要)」が選択され、最初のインストールでダウンロードされるようになるが、「<グループ名>」を選択しておけば、そのダウンロード・グループが要求されるまでダウンロードは行われない。このようにすることで、任意のグループ単位でClickOnceアプリをダウンロードできるようになり、起動スピードや実行パフォーマンスを向上させられる。ダウンロード・グループは、「(新規作成)」を選択すると、新たに作成できる。ダウンロード・グループを使った任意のタイミングでのダウンロード手順は次回以降で説明する。
(3)[発行の状況]列で「除外」が選択された項目は一覧表示から隠されるが、この[すべてのファイルを表示]にチェックを入れると見えるようにすることができる。その際、「除外」項目の行の背景は黄色になる。
(4)ダイアログ上で変更したすべての内容を破棄して、元に戻す。
[アプリケーション ファイル]ダイアログでは、配布するClickOnceアプリに含めるファイルやデータ・ファイルを指定する。この一覧表に表示されるファイルは次のいずれかの条件を備えたものである。
- プロジェクトがビルドにより生成・出力するファイル
→(例えば、「SampleApplication.exe」「SampleApplication.exe.config」「SampleApplication.exe.pdb」など)
- プロジェクトが参照しているアセンブリ・ファイル
→(例えば、「ClassLibrary1.dll」など)
- プロジェクトで「コンテンツ」としてビルドされたファイル
→(例えば、「TextFile1.txt」「XMLFile1.xml」「AdventureWorks_Data.mdf」など)
プロジェクト内にあるファイルを「コンテンツ」としてビルドするには、そのファイルを[ソリューション エクスプローラ]で選択して、[プロパティ]ウィンドウで[ビルド アクション]を「コンテンツ」に変更すればよい。この作業により、任意のファイルをClickOnceアプリで配布することができる。
この一覧表で表示されるファイルは、拡張子などに基づき配布形態(=発行の状況)が自動的に選択されている。その自動選択の基準は次のようになっている。
- 通常:→アプリケーション・ファイルとして「追加」
- .pdbファイルなど:→アプリケーション・ファイルから「除外」
- .xmlファイルや.mdfファイルなど:→「データ ファイル」*2として追加
- プロジェクトが参照するアセンブリ(.dllファイル)でローカルにコピーしないもの:→「必須コンポーネント」*3として追加
*2 データ・ファイルはClickOnceデータ・ディレクトリにインストールされる。ClickOnceデータ・ディレクトリは、ClickOnceアプリケーション・ストア(ClickOnceキャッシュ領域)と同じく、 ユーザーごとの「C:\Documents and Settings\<ユーザー名>\Apps\2.0」配下にある。
*3 必須コンポーネントは、ClickOnceではコピーされないため、エンド・ユーザーが自分でインストールしなければならない。このファイルがGAC(グローバル・アセンブリ・キャッシュ)にない場合は、インストールはブロックされる。なお、必須コンポーネントとなるアセンブリは厳密名で署名されている必要がある。
また、ここでダウンロード・グループを指定できる。このダウンロード・グループを設定すると、そのグループ単位で効率的にClickOnceアプリをダウンロードするようにできる。これはClickOnceの「オンデマンド配置」と呼ばれる機能だ。オンデマンド配置はプログラミング・コードで実装する必要がある。その実装方法については次回以降で解説する。
●必須コンポーネント
最後に[必須コンポーネント]ボタンをクリックすると表示される[必須コンポーネント]ダイアログについての説明だ。
ここでいう必須コンポーネントは、別名で「ブートストラッパ」(Bootstrapper)と呼ばれ、アプリケーションが実行される要件となるコンポーネント(例えば.NET Framework 2.0」など)をインストールするための機能だ。先ほど出てきた「アプリケーション・ファイルとしての必須コンポーネント」とは異なるので、注意してほしい(通常は、必須コンポーネントといえば、こちらの「ブートストラッパ」を指す)。
次の画面は実際に[必須コンポーネント]ダイアログを表示したところである。
必須コンポーネント(ブートストラッパ)のオプション設定
プロジェクト・プロパティの[発行]ページで[必須コンポーネント]ボタンをクリックして、[必須コンポーネント]ダイアログを表示したところ。このダイアログではClickOnceアプリをインストール、実行する前に、あらかじめインストールしておくことが必要なコンポーネント(=必須コンポーネント。例えば、.NET Framework 2.0など)を指定できる。なお、ここで選択可能な必須コンポーネントは自作することもできる(詳細次回以降)。
(1)デフォルトでチェックはオンになっているが、これをオフにするとClickOnceのsetup.exeファイルが生成されなくなる(=必須コンポーネントがインストールできなくなる)。
(2)ClickOnceアプリが実行するのに必要なコンポーネントを一覧から選択する。一覧のデフォルトの内容は次のとおりだ。
・Microsoft Data Access Component 2.8
・.NET Framework 2.0
・Microsoft Visual J# 再頒布可能パッケージ 2.0
・Microsoft Visual Studio 2005 レポート ビューア
・Visual C++ ランタイム ライブラリ (x64)
・Visual C++ ランタイム ライブラリ (x86)
・Windows インストーラ 2.0
・Windows インストーラ 3.1
・SQL Server 2005 Express Edition
(3)必須コンポーネントのインストール場所(=必須コンポーネントを置いている配布場所)を「開発元のWebサイト」「ClickOnceの配置場所と同じ」「任意の場所」の3種類から選択できる。デフォルトでは開発元のWebサイトが選択される。つまり、.NET Framework 2.0の場合はその開発元のマイクロソフトのWebサイトが使われるわけだ。
必須コンポーネントにより、ユーザー環境へのClickOnceアプリの導入がスムーズに実現できるようになり、インストール作業によるアプリケーション配布コストを気にする必要が少なくなる。ただし、ユーザーのWindows OSの種類によっては標準で用意されている必須コンポーネントで対応できないことがある。これについては次回以降の運用に関する説明で触れることにする。
また必須コンポーネントは、独自のものを作成して、この一覧の中に追加することもできる。このカスタム必須コンポーネントは、開発したアプリケーションに特殊な前提要件となるコンポーネントを、ClickOnceアプリ配布時にインストールさせたい場合に便利だ。この実装方法についても次回以降で説明する。
以上が、一通りのVS 2005のIDEによるClickOnceの利用方法だ。これ以外のClickOnce機能としてはプログラミングを活用することになるが、それについては次回以降解説する予定である。
ClickOnceテクノロジは、汎用的なソフトウェア展開をシンプルにまとめた機能なので、ある程度の柔軟性は備えているものの(例えば、ダウンロード・グループによるオンデマンド配置やカスタムの必須コンポーネントなど、プログラミングで拡張できる部分もある)、どうしても融通の利かない部分はある。代表的なものとしては、次のような制約を挙げることができる。
- 制約:[スタート]メニューに登録されるショートカットのカスタマイズ
→ClickOnceのインストール/アンインストール処理の前後に独自の処理を追加できないため、[スタート]メニューのショートカット項目として、例えばアンインストール・プログラムやヘルプ・ファイルなどへのショートカットを追加することはできない。実行時やカスタムの必須コンポーネントで追加するような方法も考えられるが、アンインストール時に削除されないという問題が残る。
- 制約:インストール時のレジストリ登録(ファイル拡張子の関連付けなど)
→先ほどの制約と同じように、ClickOnceのインストール/アンインストール処理の前後に独自の処理を追加できないため、ファイルの拡張子の関連付けといったレジストリ登録処理がインストール時に行えない。アプリケーション起動時などにこれを行ってもよいが、その場合アンインストールしても拡張子の関連付けが残ってしまう。なおかつ、前回でも説明したように、ClickOnceアプリは通常の実行は.appref-msファイルなどから起動されるため、ファイルの拡張子の関連付けを行うと、アプリケーションがClickOnceの仕組みの外で動作するという問題がある。従って、例えばMicrosoft WordやExcelのように独自のドキュメント形式を扱うアプリケーションは、現在のClickOnceでは基本的に配布できないと考えた方がよい。
- 制約:インストール時のUIのカスタマイズ
→インストール時に表示される各種ダイアログのUIはカスタマイズできない(これにより、すべてのClickOnceアプリで操作性が共有されて、ユーザビリティが増すとも考えられているが……)。このため、ユーザーとの対話形式でインストール・オプションを決定するようなことは不可能だ。
- 制約:インストール場所の指定
→ClickOnceアプリは、常に固定的にClickOnceキャッシュ領域(ClickOnceアプリケーション・ストア)にインストールする仕様となっている(これにより、アプリケーションの安全性やロールバック機能、管理容易性を高めている)。ちなみに、ClickOnceキャッシュ領域自体の場所も変更できない。
- 制約:すべてのユーザーへのインストール
→ClickOnceアプリは、前回説明したように、ユーザーごとのClickOnceキャッシュ領域にインストールする仕様となっている。このため、1回のインストールですべてのユーザーが利用できるようにすることはできない。
これらの制約がどうしても問題となる場合は、ClickOnceによるソフトウェアの配布・更新はあきらめざるを得ない。代替の展開テクノロジとしては、.MSIファイルによるセットアップやEnterprise LibraryのUpdater Application Blockなどがある。これらの展開テクノロジを活用したい場合は、次のWebページが参考になるだろう。
今回はClickOnceの発行手順や発行オプションの選択ポイントなどについて解説した。次回は、ClickOnce独特の開発ポイントやカスタマイズ方法、実運用の手順などを解説する予定だ。お楽しみに。
「連載 ClickOnceの真実」