ClickOnce によるクライアントアプリケーションの配置の紹介

ClickOnce によるクライアントアプリケーションの配置の紹介

"ClickOnce" によるクライアントアプリケーションの配置の紹介

Duncan Mackenzie Non-MS link
Microsoft Developer Network

October 2003 PDC
日本語版最終更新日 2003 年 12 月 9 日

概要 : Duncan Mackenzie が、Addison Wesley から近刊予定の『Essential ClickOnce』の草稿から、"ClickOnce" が Visual Studio 2005 アプリケーションのクライアントの配置をいかに単純にするかを説明します。

はじめに

Web アプリケーションは多くの点で制限を受けていますが、今後数年で数多くの Web アプリケーションがビルドされ、将来にはさらに多くの Web アプリケーションが開発され続けるでしょう。企業は豊富なクライアントエクスペリエンスを持ちながら、Web ベースのソリューションを選択するのはなぜでしょう? いくつかのもっともな理由がありますが、これまで聞いた中で一番の理由は配置にあります。

企業が従業員向けに新しいアプリケーションを作成することを決めるとき、デザインされるシステムの種類とは無関係に、結局は、議論は配置の問題に行き着きます。システムを対象とするユーザーに公開する必要があり、またバグの解決や新機能のリリースなど、稼動中の更新を処理するための適切な計画が必要になります。大部分の開発者や IT 担当者は、デスクトップアプリケーションの公開に関する長年の経験により、クライアント配置に伴う苦労を痛感し、結局は Web アプリケーションがより安易な道であると感じています。もちろん、機能豊富なクライアントアプリケーションに比べて、ブラウザベースの Web アプリケーションでは妥協すべき点はありますが、配置の懸念により、通常、このような妥協は許容範囲になります。実際に必要なのは、Web アプリケーションの配置と同程度に容易かつ安全なクライアントアプリケーション配置のモデルであり、アプリケーション機能の妥協のニーズを排除することです。これこそ、"ClickOnce" が実現しようとしていることです。

"ClickOnce" は、次期バージョンの Microsoft® Visual Studio® .NET および Microsoft® .NET Framework の一連の機能のコードネームです。この機能セットにより、安全かつシステムに制御されるインストールによって配置され、必要に応じて集中管理される場所から自動的に更新されるデスクトップアプリケーションの作成が可能になります。 ClickOnce の機能の説明やサンプルのビルドに入る前に、クライアント配置に現在存在する問題点と Web ベースのソリューションの欠点をいくつか説明します。

クライアント配置が困難な理由

ClickOnce はクライアント配置を単純にするために存在しますが、これは何を意味するのでしょうか? ClickOnce はどのような問題を回避するのでしょうか? クライアント配置は潜在的に多くの場所で、多くのクライアントそれぞれに対して行われ、コードやすべての関連コンポーネントがすべての対象コンピュータで機能する必要があるので、困難になります。

10,000 クライアントの中規模アプリケーションの配置を考えてみましょう (企業内のビジネスアプリケーションにとっては、それほど多い数ではありません)。デスクトップアプリケーションにとっては、少しずつソフトウェア構成が異なる 10,000 台の異なるコンピュータが存在することになります。 Web アプリケーションの場合は、1 台のサーバーから、コンピュータの小さな "Web ガーデン'" まで、どこにでも存在する可能性があり、配置の範囲には大きな違いがあります。したがって、それぞれの場合に、コードが次のような要件を満たしていることを確認する必要があります。

コードが各対象コンピュータで実行されること。
コードをインストールすることにより、既存のソフトウェアの機能を停止させないこと。
その後の任意のソフトウェアのインストールによって、コードの機能が停止しないこと。

10,000 台のコンピュータに対応するのは、実に大変な作業です。可能性のあるソフトウェアの組み合わせをすべて含めるには、テストにどのような影響を与えるでしょうか? 要件の一覧の最後の 2 項目は、親しみを込めて "DLL Hell" と呼ばれています。あるアプリケーションの DLL のインストールまたは削除により、他のアプリケーションが機能を停止する可能性があるためです。アプリケーション間の競合の可能性を軽減するための多くの方法がありますが、クライアントコンピュータに配置する際には、依然として競合が発生する可能性があります。このような問題点のすべてにより、Web アプリケーションが魅力的に見えます。結局、Web アプリケーションが最後にデスクトップの機能を停止させたのは、いつだったでしょうか?

ソフトウェアを最初にインストールする操作、または将来更新をインストールする操作もまた問題になります。 Web サーバーの場合は、それぞれのコンピュータまで行ってセットアッププログラムを実行するように誰かに依頼し、インストールを手動で行うことができます。これは、10,000 台のクライアントに対しては実現不可能な方法です。数多くのクライアントを扱うときは、初期インストールを実行したり、アプリケーションが稼動している間、更新ごとに新しいインストールプログラムを実行するために、何らかの操作を行うようにユーザーに依頼する必要があります。このアプローチは、既に数多くの場面で適切に利用されていますが、アプリケーションのリリースや各更新を複雑にしています。

セキュリティも、アプリケーションのインストールに関する問題の 1 つです。当該の企業のポリシーにもよりますが、一般ユーザーは従来のアプリケーションインストールを実行するのに十分な権限を持っていない場合があります。

注意 Microsoft® System Management Server やその他の同様のシステムにより、企業でのアプリケーションの配置の課題が緩和されますが、クライアントインストールの望ましくない副作用の問題がなくなるわけではありません。このようなシステムは、デスクトップが正確な仕様で作成され、更新が厳格なリリース手順で行われる、非常に高度に管理された環境で最適に機能します。

ブラウザベースのアプリケーションの制限事項

私は Web を毎日使用しており、多くの点で優れていると感じていますが、Web ベースのアプリケーションには制限があります。ブラウザベースのシステムには、いくつかの明らかな問題点があります。 Web バージョンの Microsoft® Outlook® のオフラインサポートの不足は、私にとってはこれが十分役割を果たしていないことを意味します。また、大部分の人気のあるサイトでさえも、Web アプリケーションに関する多くの問題点を見ることができます。

オンラインショッピングサイトでクレジットカード情報を入力した後に、"精算" または "送信" をクリックする操作を考えてみましょう。 "ページが見つかりません" や "サーバーが応答しません" といったブラウザエラーが、その瞬間に表示されることがよくあります。送信した注文はどうなるのでしょうか? うまくいったのでしょうか、それともうまくいかなかったのでしょうか? この種の混乱を電子メールによる確認やその他の方法によって軽減することはできますが、開発者の誤りではないので、Web アプリケーションではこの種の混乱を回避するのは困難です。これはむしろ、Web のシンクライアントアーキテクチャの副作用です。

クライアントアプリケーションでも同様の問題が発生することがありますが、多くの場合、これらは制限事項またはバグと見なされ、適切に対処できます。クライアントアプリケーションの開発者は、注文をローカルに保存し、ネットワーク接続が失われた後のトランザクションを定期的に再試行したり、トランザクションの状態を照会するという選択肢があります。このような選択肢は、Web アプリケーションにはありません。 Web アプリケーションについての説明に、これ以上時間を費やすのはやめておきます。 Microsoft® Windows® アプリケーションの開発と配置を行う理由はそれぞれなので、ClickOnce がいかに目標の実現を容易にするかに重点を置いて説明します。

ClickOnce はどちらのモデルにも最適

クライアントコンピュータ向けではなく、Web 向けに開発を行う主な理由は 2 つあります。

第 1 の理由は、ネットワークにアクセスできるほぼすべてのデバイスに到達するために、最低限の共通基準 (Web ブラウザ) にアプリケーションを制限する必要性です。 Web アプリケーションは、"機能の豊富さ" ではなく、"到達" を目標にしており、一部の機能を犠牲にして広範なクライアントをサポートします。
第 2 の理由は、インストールと稼動中の更新の容易性です。 1 台のクライアントごとに新しいコードを適用することを要求するのではなく、1 台のコンピュータまたはコンピュータの小規模集団にバグの解決を適用する機能は、アプリケーションの保守時間を大幅に節約します。

Web に接続できるほぼすべてのデバイスで利用できることを目標としているならば、到達を追及することが重要になります。しかし、"企業の従業員とパートナー" といったやや狭い対象ユーザーを扱うならば、到達はあまり問題にはなりません。対象ユーザーを減らせば、".NET Framework をサポートできる Windows コンピュータ" のように対象プラットフォームを制限でき、その後、完全なデスクトップアプリケーションをビルドすることによって、そのプラットフォームを利用できます。 ClickOnce により、アプリケーションの容易なインストールと自動的な更新という方程式の第 2 項を提供することによってこれを行うことができます。

この資料の後半では、Web、ClickOnce、および MSI を使用した完全なクライアントインストールの 3 つの異なる配置モデルがどのように関係し、特定のアプリケーションにとって最適な選択肢を判断する方法を説明します。ここでは、以下の表で各配置モデルの機能を説明し、ClickOnce が従来の Web とクライアント環境のギャップを橋渡しする方法を説明します。

機能	Web	ClickOnce	MSI/クライアント
到達性	Y
自動配置	Y	Y
システムへの影響の低さ	Y	Y
ユーザーごとのインストール/実行	Y	Y
機能の豊富さ/対話的エクスペリエンス		Y	Y
オフライン		Y	Y
Windows シェル統合		Y	Y
制限のないインストール			Y

.NET での既存の配置の強化

ClickOnce は、次期バージョンの CLR と .NET Framework の新機能ですが、マネージコードに既に存在する多くの側面により、ClickOnce が可能になります。初期バージョン 1.0 リリースの .NET でも、アプリケーション分離と影響がまったくない配置 (xcopy 配置と説明されることがよくあります) 向けにマネージアプリケーションがデザインされていたので、アプリケーションのインストールや更新をかつてないほど容易にしていました。

.NET の最初のリリースでは、アプリケーションが常に最新であることを保証するために、Web サイト (http://mysite/myapp.exe) からアプリケーションを直接実行することもできました。それにもかかわらず、このアプローチの技術的な制限事項は重大でした。 Href-exe (既知の HTTP アドレスから実行されるアプリケーション) は、多くの場合、クライアントのセキュリティポリシーの変更を必要としました (これは、アプリケーションが機能するようになる前に、.MSI が実行される必要があることを意味します)。 Href-exe は、ローカルにインストールされた同じアプリケーションよりも実行速度が遅く、ユーザーエクスペリエンスが不足しており (新しいアセンブリを Web サーバーからの読み込む必要があるとき、UI がしばらく応答を停止することもありました)、本当の意味のオフラインモデルではありませんでした。

Jamie Cool の "AppUpdater" と MSDN でリリースされた Updater Application Block の 2 つの自動更新ソリューションが利用できるようになり、開発者やエンドユーザーのエクスペリエンスが向上しました。どちらのソリューションでも、アプリケーションがローカルコンピュータにインストールされるので、href-exe のパフォーマンスやセキュリティの問題はなくなり、アプリケーションのオフラインでの使用をサポートできるようになりました。

本書の付録 A では、バージョン 1.1 の .NET Framework を使用していても利用可能な配置手法に関する詳細を説明しています。 ClickOnce はこのサポート層に基づいて作成されており、配置をより容易にしています。

ClickOnce の基本的な概念

Windows アプリケーションにとってより適切な配置モデルが必要な理由をいくつか説明したので、ClickOnce がこれに対応する方法を説明します。 ClickOnce は、.NET ランタイム (CLR) の一連の機能と Visual Studio .NET の統合デザイン時サポートを組み合わせたものです。その機能と IDE ツールを組み合わせて使用することにより、自動的にインストールおよび更新されるアプリケーションを作成できます。アプリケーションが配置、起動、更新される方法に関して、大きな柔軟性があります。このような各トピックについては、今後の章でさらに詳しく説明しますが、これらのオプションについてここで簡単に説明します。

配置オプション

ClickOnce アプリケーションは、Web 上の場所、UNC 共有、または CD-ROM などのファイル上の場所から、クライアントコンピュータに配置できます。このような方法で Web 上の場所からアプリケーションを配置するときは、ユーザーは Web ページ上のリンクをクリックすることになります。その結果、アプリケーションのダウンロードが開始され、クライアントコンピュータにアプリケーション自体がインストールされます (インストール完了時には、[スタート] メニューのショートカットや [アプリケーションの追加と削除] ダイアログボックスの行が追加されます)。インストールが完了してしばらくすると、ダウンロードおよびインストールされたアプリケーションが表示されます。

また、ClickOnce アプリケーションは、クライアントコンピュータに配置しないで実行できます。つまり、クライアントに影響を与えずに、UNC パスや http URL などのネットワーク上の場所から直接起動できます。このような方法で起動したアプリケーションは、ローカルにキャッシュされますが、従来の感覚のようにはインストールされません。本書の第 3 章「'ClickOnce' Scenarios」で、さまざまな配置オプションの詳細を説明しています。

クライアントコンピュータに影響を及ぼすようなインストールを必要とする場合 (ファイル関連付けの作成、MSDE のインストール、またはその他同様の操作の実行)、依然として .MSI ファイルによりそのようなインストールを扱う機能があります。もちろん、通常の ClickOnce 配置プロセス外で行ったすべてのことは、ClickOnce の機能を低下させる可能性がありますが、必要であれば可能です。

起動または配置されるアプリケーションが機能するためには、対象のコンピュータに .NET Framework が必要になります。状況によって異なりますが、インストールの前に、またはインストール自体の一部として、コンピュータに .NET Framework を取得するためのさまざまな方法があります。 .NET Framework の配置固有のトピック、および高度なインストールの一般的な概念は、どちらも、第 4 章「Advanced Deployment Concepts」で説明しています。

アプリケーションの更新

更新には配置オプションと同様の柔軟性があります。(アプリケーションの開始時など) 特定の時点に更新できます。また、アプリケーション開発者が適切な更新 API を呼び出すことを選択したときはいつでも更新できます。特定の更新が必須であることを指定し、ユーザーが利用可能な更新を無視できないようにすることも可能です。稼動中の更新を管理し、ユーザーベース全体を新しいバージョンに適宜、確実に移行するためには、この必須更新機能が重要になります。

更新プロセスのその他の重要な機能には、クライアントまたはサーバーのどちらかでアプリケーションリリースのロールバックを行う機能があります。サーバーをロールバックする場合は、この管理機能により、不具合のある更新の迅速な削除、および以前のバージョンへのクライアントの自動ダウングレードが可能になります。クライアント側のロールバックは、常時接続を行わないクライアントにとって重要な機能になります。このようなクライアントが、新しいバージョンのアプリケーションがコンピュータ上で破損していることを見つけるためだけに、接続し、更新し、切断する場合、再接続することなく以前のバージョンにロールバックできます。利用可能なすべてのオプションを使用すれば、必要とする特定の更新機能は何でも実現できますが、その概念は 1 つの章を必要とするほど複雑です (第 6 章「Application Updates」)。

マニフェストファイル

配置と更新の動作は、システムのコンポーネントおよび行うべき配置操作を記述する 1 組の XML マニフェストファイルを使用することにより制御できます。アプリケーションマニフェストは、Visual Studio .NET の補助により開発者が記述し、アプリケーションのファイル、依存関係、および基本セキュリティ要件を詳しく説明します。配置マニフェストは、管理者が作成することを意図したもので (開発者は、開発の早期段階で、必ずこのマニフェストを作成することになりますが)、アプリケーションが配置および更新される方法を詳しく説明します。各 ClickOnce アプリケーションにはこれら 2 つのマニフェストファイルが関係してくるので、これらのマニフェストファイルとすべてのそのオプションを本書全体にわたって目にすることになりますが、第 8 章「Digging into the Manifest files」で詳しく説明しています。

図 1. マニフェストファイルは協調動作し、ClickOnce アプリケーションのインストールと更新を可能にします。

この章の後半で、簡単な ClickOnce アプリケーションを作成する際に、Visual Studio .NET により作成された基本的な 1 組のマニフェストファイルの内容を示します。マニフェストファイルは、次期バージョンの Visual Studio .NET 2005 の PDC リリースでは公開されませんが、その機能は今後のバージョンに存在することになるでしょう。

セキュリティの概念

ClickOnce 以前、href exe をクライアントコンピュータで適切に実行できるようにする際に、セキュリティは大きな課題の 1 つでした。セキュリティは ClickOnce アプリケーションにとっても依然として重要な概念です。幸いなことに、アプリケーションを実行できるセキュリティ "sandbox" の規模は拡大されており、このような sandbox の境界は、理解や調査が大幅に容易になっています。 ClickOnce アプリケーションの自動インストールや自動更新の機能によって、安全な配置モデルをサポートすることが意図されます。配置されたコード、または自動的にダウンロードされたコードは、どのような情報にアクセスでき、どのような動作を実行できるかが制限されます。アプリケーションを URL から起動しようと、CD-ROM から配置しようと、対象のコンピュータ上で完全に信頼されているとは見なされません。

アプリケーションの自動更新の既定の sandbox の制限事項は少なくなっていますが、これまではセキュリティが低減された状況でのみ発生する問題のトラブルシューティングは困難でした。 Visual Studio .NET の 2005 リリースでは、セキュリティが低減された状況で、デバッグツールを使用しながら IDE 内からアプリケーションを実行できるようになります。この新機能により、アプリケーションの開発中に、さまざまなセキュリティ設定や制限事項のシミュレーションが行えるようになります。セキュリティの問題点を明らかにするために、テストコンピュータにアプリケーションを配置する必要がなくなります。

第 5 章「Security in 'ClickOnce' Applications」では、さまざまな配置オプションの既定のセキュリティ制限事項を説明し、このような制限内でのプログラムの作成方法に関するガイダンスをいくつか提供します。第 5 章では、既定の制限内でアプリケーションを実行できない場合の、セキュリティポリシーの調整方法および管理者によるクライアントコンピュータへの公開方法も説明しています。セキュリティポリシーの変更や、その変更の配置が実際的でない状況では、権限の昇格 (Permission Elevation) という新しいセキュリティ機能があります。このことについても、第 5 章で触れています。これにより、ユーザーは特定のアプリケーションについて信頼できる決定を行うことができます。

Visual Studio 統合

ClickOnce は Visual Studio 2005 の重要な機能です。つまり、Visual Studio 2005 バージョンの Visual Studio .NET に緊密に統合され、ドキュメント化され、サポートされることになります。プロパティダイアログボックスを使用して、上記の 2 つのマニフェストファイルの作成に使用される、さまざまな ClickOnce の情報を指定できます。この情報には、発行の詳細が含まれます (図 2 参照)。

図 2. このプロパティダイアログボックスで、またはアプリケーションを発行する際に実行するウィザードの一部として、ファイルの発行場所およびアクセス元の場所を指定できます。

Visual Studio .NET 統合は、IDE 内で詳細情報の発行や更新の構成だけでなく、さらに拡張されています。 [プロジェクト] メニューの [Publish (発行)] をクリックし、オプションのウィザードを簡単に設定することにより、IDE 内からアプリケーションを直接発行することもできます。この章の後半でこのプロセスを行いますが、実に簡単に使用できます。

特に ClickOnce ユーザー向けというわけではありませんが、Visual Studio .NET のその他の優れた機能により、希望するセキュリティコンテキストで、デバッガを使いながら、アプリケーションを IDE 内で実行できるようになります。この機能は、アプリケーションが実行されるセキュリティ制限を理解するのに実に役立ちます。また、Visual Studio .NET IDE のすべてのツールを使用して、セキュリティ関連の問題点を適切にデバッグするのにも役立ちます。

簡単な ClickOnce のサンプルのビルド

ClickOnce を支える基礎を説明したので、デモに進みましょう。本書の後半ではさらに高度な例を紹介しますが、ここでは、.NET Framework の範囲内に収まる要件しか持たない、かなり簡単なアプリケーションに注目します。

注意ここでの指示、スクリーンショット、およびその他の詳細は、Visual Studio 2005 の PDC 2003 リリースと対応するバージョンの .NET Framework に基づいています。ユーザーインターフェイスの要素と手順の正確な詳細は、今後変更される可能性があります。

最初の "リリース" では、完全に空のアプリケーションから開始します (これ以上簡単にはできませんよね?)。その後、次のリリースとして、自動更新機能および更新の公開の基本的なプロセスを確認できるように、いくつか単純な機能を追加します。

必要条件

このデモの唯一の実際の必要条件は、次のとおりです。

開発コンピュータに PDC バージョンの Visual Studio .NET。
ファイルの格納とディレクトリの作成が可能な Web サーバー。
PDC バージョンの .NET Framework がインストールされたクライアントコンピュータ。

すべての目的に 1 台のコンピュータを使用する場合は、必要な項目をすべて保持する必要があります。 Web サーバーが Microsoft® Windows Server™ 2003 を実行している場合は、1 つ簡単な構成変更を行う必要があることがあります。既定では、Windows Server 2003 は、既知のファイルの拡張子を持つあらゆるファイルのダウンロードをブロックします。 ClickOnce アプリケーションの発行にこのサーバーを使用する場合、Microsoft® インターネットインフォメーションサービス (IIS) の設定を変更して、拡張子 .deploy と .manifest を持つファイルのダウンロードを可能にする必要があります。この問題は、Microsoft サポート技術情報の資料 327283 (英語) に記載されており、新しいファイルの種類 (および関連付けられる拡張子) を IIS の設定に追加する方法を説明しています。ファイルの種類が .deploy の場合は、MIME の種類 "application/deployment" でファイルを登録することをお勧めします。

アプリケーションの作成

前述したように、最初のリリースでは、空のアプリケーションをビルドし、発行します。[新しいプロジェクト] をクリックして、[プロジェクトの種類] で [Windows アプリケーション] を選択し、空のアプリケーションを作成します (図 3 参照)。選択する言語は、この時点ではあまり重要ではありません。C# と Microsoft® Visual Basic® .NET の両方で、2 番目のリリースのコードを提供するので、使いやすい言語を使用してください。

ms996413.clickonce_fig3(ja-jp,MSDN.10).gif
図 3. 新しい空の Windows アプリケーションのプロジェクトの作成

ここでは、何も追加せずに、新しいアプリケーションの配置設定の構成に進みます。

配置オプションの構成

[プロジェクトのプロパティ] ダイアログボックスは、Visual Studio .NET 2003 から少し変更されました。変更点の一部に、アプリケーションの発行の設定用のプロパティページの追加があります。[プロジェクト] メニューの [<プロジェクト名> のプロパティ] メニュー項目からプロパティダイアログボックスを開くか、またはソリューションエクスプローラでプロジェクトを右クリックし、[プロパティ] メニュー項目をクリックします。左側の [Publish (発行)] をクリックすると、大変興味深い、アルファバージョンの一連のオプションが表示されます (前の図 2 参照)。

注意通常、基本的な ClickOnce の設定では、このプロパティダイアログボックスは使用しません。代わりに、発行ウィザード (Publish Wizard) の一部として配置場所やインストールモードオプションを設定します。発行ウィザードは、アプリケーションの発行を選択すると必ず実行されます (図 6 参照)。詳細設定オプションを設定するには、この [プロジェクトのプロパティ] ダイアログボックスを使用する必要がありますが、すべての設定を一度に説明できるように、すべてのプロパティをこのダイアログボックスで設定することにしました。

[Publish my application to ...(アプリケーションの発行先)] プロンプトの下のテキストボックスで、アプリケーションの配置場所を指定します。既定の配置場所は http://localhost/... です。 Web サーバーがその Web アドレス経由の接続をサポートしていない場合、同じ Web フォルダ (\\duncanmawhidbey\wwwroot$\sampleapp) または FTP アドレスに対応するファイルの場所を指定することもできます。実際のプロジェクトでは、サーバー名がプロジェクトファイルに格納され、プロジェクトと共にさまざまなコンピュータに移動するので、この設定で使用するサーバー名について少し考慮することをお勧めします。実際のサーバー名を使用すれば、Visual Studio .NET がインストールされているのと同じコンピュータでも、さまざまな開発コンピュータ間を移動した場合でも、同じ Web サーバーを指し示し続けることができます。また、複数の開発者がプロジェクトで共同作業を行っている場合、Web 上の共有場所を使用したくないことがあります。このような場合、localhost ベースの URL を指定することにより、各開発者はアプリケーションの更新を発行するたびに URL を変更することなく、独自の IIS インスタンスを実行できるようになります。

次に、[Install Mode (インストールモード)] オプションボタンが、[Install the application...(クライアントにアプリケーションをインストールして、スタートメニューにショートカットを作成する)] に設定されていることを確認してください。[Install Mode (インストールモード)] オプションボタンは、アプリケーションがネットワーク上の場所から起動されるか、ローカルにインストールされ、Web 上の場所から更新されるかの選択肢を示します。このサンプルアプリケーションの場合は、通常の "Windows アプリケーション" スタイルでインストールされるシステムを示します。発行されるアプリケーション用に Web ページを作成するオプションがオンになっていて、Web ページ名のテキストボックスに適切な名前が入力されていることを確認します。ここでは、発行フォルダの既定のページになるように "default.htm" を使用しますが、どのようなファイル名でも入力できます。

[Application Updates...(アプリケーションの更新)] ボタンをクリックして、希望する更新頻度とオプションを設定します (図 4 参照)。

ms996413.clickonce_fig4(ja-jp,MSDN.10).gif
図 4 [Application Updates (アプリケーションの更新)] ダイアログボックスにより、いつ、どの程度の頻度で、アプリケーションがソース場所で新しいバージョンを確認するのかを指示できます。

ダイアログボックスの下部にある 2 つの設定、[Required update (必須の更新)] と [Update from...(以下の場所から更新する)] を使用して、アプリケーションの更新を必須とするか、以前のリリースとは異なる更新場所で更新するかを構成します。設定をまだ行っていない場合は、図 4 での設定に合わせて値を設定し、[Application Updates (アプリケーションの更新)] ダイアログボックスを閉じます。

[Prerequisites (必須コンポーネント)] ボタンをクリックすると、アプリケーションを実行するために必要な基本コンポーネントを指定できます (図 5 参照)。コンポーネントを必須コンポーネントとして指定すると、そのコンポーネントがセットアッププログラムに集められ、アプリケーションを実行する前に対象のコンピュータで実行可能になります。このサンプルでは、.NET Framework だけを選択状態で残し、[Prerequisites (必須コンポーネント)] ダイアログボックスを閉じます。

ms996413.clickonce_fig5(ja-jp,MSDN.10).gif
図 5. [Prerequisites (必須コンポーネント)] ダイアログボックスで、アプリケーションの基本的な必要条件を指定します。

[Application Files (アプリケーションファイル)] ボタンにより、アプリケーションに必要なファイルを指定できます。このサンプルでは、一覧されるファイルは .exe だけになるので、この時点ではあまり注目するオプションではありません。

アプリケーションの発行

すべての設定を構成したら、[プロジェクト] メニューの [Publish (発行)] をクリックすることにより、IDE からアプリケーションの発行を開始できます (このメニュー項目は、ソリューションエクスプローラのプロジェクトの右クリックメニューからも利用できます)。これによりウィザードが開始します (図 6 参照)。ウィザードでは、[プロジェクトのプロパティ] ダイアログボックスで既に設定済みの設定の一部を、指定または変更できます。

ms996413.clickonce_fig6(ja-jp,MSDN.10).gif
図 6. 発行ウィザード (Publish Wizard) により、[プロジェクトのプロパティ] ダイアログボックスでの発行に関する設定を一部変更できます。

このウィザードには、次の 3 つのステップがあります。場所、配置の種類 (起動かインストールか)、および最後の設定の要約の 3 つのステップです。 [プロジェクトのプロパティ] ダイアログで既に発行オプションを設定しているので (図 2 参照)、[完了] をクリックして、Visual Studio が Web サーバーに接続して新しいディレクトリを作成し、一連のファイルをアップロードするのを見ているだけになります。自動的に作成された Web ページ (publish.htm) とアプリケーションの必須コンポーネントをインストールできる setup.exe プログラムと共に、配置マニフェストが指定されたディレクトリのルートに格納されます。最上位レベルのディレクトリの下に、現在のバージョンのアプリケーション用にディレクトリが作成され (.exe ファイルとアプリケーションマニフェストを含む /WindowsApplication1_1.0.0.0/)、必須コンポーネントのインストーラが使用する再配布可能な .NET Framework を格納するためのディレクトリが作成されます。

発行ウィザード (Publish Wizard) が完了するときに、自動生成された Web ページ (図 7 参照) が自動的に表示されます。このページは、ClickOnce アプリケーションをインストールまたは起動するためにエンドユーザーにクリックさせる .deploy ファイルへのリンクを提供します。

ms996413.clickonce_fig7(ja-jp,MSDN.10).gif
図 7. ASP.NET Web サービス用に作成したページに似た、自動生成された Web ページ。アプリケーションの配置マニフェスト (.deploy ファイル)、とアプリケーションの必須コンポーネントのインストーラへのリンクを提供します。

.NET Framework がインストールされていないコンピュータから Web ページにアクセスする場合、実際のアプリケーションをインストールする前に、"click here to install prerequisites (ここをクリックして必須コンポーネントをインストールしてください)" リンクをクリックする必要があります。 .NET Framework がインストールされていないと、クライアントのシステムは .deploy というファイルの種類を扱う方法が分からないので、単にマニフェストを開くか、または保存するかを問い合わせます。

アプリケーションの実行

アプリケーションを実行するには、WindowsApplication1.deploy ファイルへのリンクをクリックします。この時点で、.NET ランタイムが引継ぎ、行われようとしているアプリケーションインストールを確認するように求めます (図 8 参照)。

ms996413.clickonce_fig8(ja-jp,MSDN.10).gif
図 8. アプリケーションがコンピュータ上の何かを変更する必要があるとき、インストールを確認するように求められます。

注意この場合、アプリケーションが [スタート] メニューに追加され、この動作にはユーザーの承諾を必要とするので、この確認ダイアログボックスが必要になりました。アプリケーションを [スタート] メニューに追加する必要がない場合は、問い合わせなしに実行されます。

アプリケーションをインストールすることを確認したら、インストールプロセスに移行し、[スタート] メニューにショートカットが追加され (図 9 参照)、アプリケーションが起動されます。適切な企業名を提供するように、サンプルアプリケーションのさまざまなプロパティを更新しなかったので、[スタート] メニューのショートカットは Microsoft という名前の下に設定されますが、インストールの場所はまったく制限されません。

図 9. インストールするアプリケーションを構成する際、単に起動されるだけではなく、[スタート] メニューにショートカットが作成されます。

これで正しくアプリケーションが配置されたので、稼動中の自動更新の機能に変更を加え、結果を見てみましょう。

アプリケーションの更新の発行

サンプルアプリケーションに戻り、最初のバージョンと更新したバージョンを明確に区別するために、簡単な変更を加えます。容易に区別できるものなら何でも良いのですが、簡単なメッセージを表示するボタンを追加することにしました。このサンプルに従っている場合、同じように明確な追加をアプリケーションに行うか、以下のコードブロックを使用してまったく同じ追加を行ってください。


'Visual Basic .NET コード
Private Sub Button1_Click( _
        ByVal sender As System.Object, _
        ByVal e As System.EventArgs) _
        Handles Button1.Click
    MessageBox.Show( _
        "Greetings!", "New Version", _
        MessageBoxButtons.OK, _
        MessageBoxIcon.Information)
End Sub

//Visual C# コード
private void button1_Click( 
      object sender, 
      System.EventArgs e)
{
   MessageBox.Show("Greetings!", 
      "New Version", 
      MessageBoxButtons.OK,
      MessageBoxIcon.Information)
}

この追加を行った後、AssemblyInfo ファイルで、アプリケーションのバージョンを 1.1.0.0 に増加します。その後、[Publish (発行)] メニュー項目を使用して、このアプリケーションの新たな発行プロセスを開始し、再度すべてのオプションを同じにします。ウィザードが完了すると、新たなバージョンを格納するために Web サーバー上に新しいフォルダが作成されます (図 10 参照)。さらに、1.1.0.0 が全員が実行すべきバージョンであることが配置マニフェストによって指示されるようになります。

図 10. アプリケーションの新しいバージョンは、.deploy ファイルへの変更と新しいサブフォルダの追加を必要としますが、自動生成された Web ページの更新は必要ありません。

新しいバージョンがサーバー上で利用可能になると、アプリケーション更新の設定に基づいて、クライアントアプリケーションは自動的に更新を開始します。

クライアントの更新

新しい .deploy ファイルが利用可能になり、元のサンプルを実行すると自動更新が行われます。更新用に指定した設定 (アプリケーション起動時に更新を確認するための設定) を使用して、新しいバージョンにアップグレードするかどうかを確認するようにユーザーに求めます (図 11 参照)。クライアント更新の UI はアルファ版での状態であり、今後のビルドでは変更されることになるでしょう。

ms996413.clickonce_fig11(ja-jp,MSDN.10).gif
図 11. 更新が利用可能なときにユーザーに通知され、ユーザーは新しいバージョンを受け入れるか、または無視することを選択できます。

ユーザーが [Yes (はい)] をクリックすると、プログレスバーが表示され (これは非常に小さなアプリケーションなので、プログレスバーは表示後すぐに消え、それに気付く時間がほとんどありません)、新しいバージョンがダウンロードされ、実行されます。もちろん、この更新は既定の設定のみを使用して実行されます。利用可能なすべてのさまざまなオプションを検討すれば、より多くの制御が可能になります。

注意 ClickOnce アプリケーションの配置で問題が発生した場合は、対象のコンピュータに作成されるログを利用します。現在のユーザーの個人用設定フォルダ (たとえば、c:\documents and settings\duncanma) を見ると、\Local Settings\My Applications\ フォルダにログがあります。

"Longhorn" での ClickOnce

Windows クライアントの次期リリースである、コードネーム "Longhorn" には、アプリケーション配置に対する多くの変更が含まれます。ただし、ClickOnce で開発を行っている場合、"Longhorn" アプリケーションと ClickOnce アプリケーションは多くの特性や動作を共有しているので、多くの場合、このような変更は既になじみのものであることが分かります。

まず、"Longhorn" アプリケーションは、ここまで説明してきたのと同じ "アプリケーションマニフェスト" と "配置マニフェスト" モデルを使用します。また、ClickOnce アプリケーションと同様の 2 つの配置方法 (ローカルコンピュータへの "配置"、またはリモートの場所からの "起動") をサポートします。 ClickOnce 配置のその他の重要な側面である、実行するために配置または起動されるアプリケーション用のセキュリティ "sandbox" の使用も、"Longhorn" に当てはまります。実際には、"Longhorn" はこの概念を拡張しています。"Longhorn" の sandbox は "セキュリティで保護された実行環境" と呼ばれており、すべてのアプリケーションで既定で使用されます。

"Longhorn" は、依然として自動配置や更新を使用しているときに、.MSI 配置の従来の動作の一部を実行するようなインストール機能を含め、数種類の方法で現在の ClickOnce の機能セットを拡張します。一例として、Web サイトからユーザーのデスクトップに自動配置される "Longhorn" アプリケーションは、セキュリティで保護された実行環境外の追加権限を要求することなく、ファイルの関連付けを行うことができます (特定のファイルの種類のハンドラとして、自分自身を登録します)。また、"Longhorn" はアプリケーションマニフェストの一部としてプライバシー情報の概念を追加します。アプリケーションの作成者は、情報ストレージ、再利用などに向けたプライバシーポリシーを記述できます。もちろん、これは "Longhorn" のリリースにはまだ早すぎるので詳細情報は制限されていますが、ClickOnce を使用するアプリケーション (および開発者) は、明らかに "Longhorn" への移行に適応しておく必要があります。

ms996413.clickonce_fig12(ja-jp,MSDN.10).jpg
図 12. "Longhorn" の PDC リリースで実行される簡単な ClickOnce アプリケーション

サンプルの ClickOnce アプリケーションを作成する手順 (図 12 参照) は、"Longhorn" を対象とする場合でも同じです。したがって、この章で示したのと同じプロセスに従うことによって、Windows フォームアプリケーションを記述および配置できます ("Longhorn" と Visual Studio 2005 の両方が利用可能である場合)。ただし、Windows Server 2003 のみに関しては、ダウンロードが正しく機能するために、IIS の MIME の種類の設定に .deploy ファイルと .manifest ファイルの種類を追加する必要があります。

まとめ

可能性のある更新や配置のシナリオ、ClickOnce アプリケーションのセキュリティ制限内での作業、自動更新システムの開発と管理に関する高度なトピックなど、ClickOnce に関する詳細が、この本の残りの部分に書かれています。この紹介の章では、ClickOnce の基本と、このテクノロジがアプリケーション配置の問題にどのように役立つかについて、いくつかの考え方を説明しました。

著者について

Duncan Mackenzie は、日中は Microsoft Visual Basic .NET と Microsoft Visual C# の MSDN の Content Strategist であり、深夜は熱心なコーダーになります。彼はアールグレイティーがなければ、まったく仕事が手につかないことをほのめかしましたが、そのことには気付かなかったことにしましょう。 Duncan について詳しいことをお知りになりたい場合は彼のサイト Non-MS link (英語) を参照してください。

_________________________

詳細については、http://www.awprofessional.com/msdotnetseries/ Non-MS link (英語) を参照してください。

ページのトップへ

プロファイル (個人情報) の管理 | お問い合わせ先 | MSDN Flash ニュースレター | 日本での個人情報の取り扱い | サイトマップ

目次