"ClickOnce" を使用したクライアントアプリケーションの配置の概要

[アーティクル]
01/18/2008

Duncan Mackenzie
Microsoft Developer Network

2003 年 10 月 PDC

概要： このドラフトの章では、次の Addison Wesley タイトルの Essential ClickOnce、Duncan Mackenzie で、"ClickOnce" が Whidbey アプリケーションのクライアント展開を簡略化する方法について説明します。* (18 ページ印刷)

内容

はじめに
.NET での既存の展開の機能強化
ClickOnce の基本的な概念
単純な ClickOnce サンプルの作成
ロングホーンの ClickOnce
まとめ

はじめに

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のインストールまたは削除が別のアプリケーションを壊す可能性がある「DLL Hell」と愛情を込めて知られています。アプリケーション間の競合の可能性を減らす方法は多数ありますが、クライアントコンピューターに展開する場合は引き続き発生する可能性があります。これらの問題はすべて、Web アプリケーションを非常に魅力的に見せることができます。結局のところ、Web アプリケーションが最後にデスクトップを壊したのはいつですか?

ソフトウェアを初めてインストールする行為、または将来の更新プログラムをインストールする行為も課題です。 Web サーバーの場合は、インストールを手動で処理するだけで、各コンピューターに移動してセットアッププログラムを実行するユーザーを割り当てることができます。これは、10,000 のクライアントでは実現できないプロセスです。多数のクライアントを処理する場合は、最初のインストールを実行するために何らかのアクションを実行し、アプリケーションの有効期間中に更新ごとに新しいインストールプログラムを実行するために、ユーザーに頼る必要があります。このアプローチは数え切れない場面で既に正常に使用されていますが、アプリケーションのリリースと更新ごとに複雑さが増します。

セキュリティは、アプリケーションのインストールにも問題があります。問題の会社のポリシーによっては、通常のユーザーが従来のアプリケーションのインストールを実行するための十分なアクセス許可を持っていない可能性があります。

メモ Microsoft® System Management Server やその他の同様のシステムは、企業全体にアプリケーションを展開する際の苦労を軽減するのに役立ちますが、不要なクライアントインストールの副作用の問題は削除されません。このようなシステムは、デスクトップが正確な仕様に従って作成され、更新プログラムが厳密なリリース手順を実行する非常に高度に管理された環境でも最適に動作する傾向があります。

Browser-Based アプリケーションの制限事項

私は毎日Webを使用していますが、多くのことに素晴らしいですが、Webベースのアプリケーションには限界があります。ブラウザーベースのシステムには明らかな問題がいくつかあります。オフラインサポートだけでは、Microsoft® Outlook® の Web バージョンでは不十分であり、Web アプリケーションに関する多くの問題は、最も一般的なサイトでも確認できます。

クレジットカード情報を入力したら、オンラインショッピングサイトで [チェックアウト] または [送信] をクリックする行為を検討してください。その正確な時点で、多くの場合、「ページが見つかりません」または「サーバーが応答していません」というブラウザエラーを受け取っています。それは私の注文にとって何を意味しますか? それは通過したかどうか? この種の混乱は、Web アプリケーションでは避けるのは難しいですが、電子メールの確認やその他の方法で軽減できますが、開発者側の間違いではありません。むしろ、Web のシンクライアントアーキテクチャの副作用です。

クライアントアプリケーションでもこのような問題が発生する可能性がありますが、ほとんどの場合、これらは制限またはバグと見なされる必要があります。それはより良いことができます。クライアントアプリケーションの開発者は、注文をローカルに保存し、定期的にトランザクションを再試行するか、ネットワーク接続が失われた後にトランザクションの状態を照会するか、Web アプリケーションで使用できない選択肢を選択できます。 Web アプリケーションの説明にこれ以上時間を費やすつもりはありません。 Microsoft® Windows® アプリケーションを開発して展開する独自の理由があると確信しています。そのため、ClickOnce を使用して目的を達成しやすくする方法に焦点を当てます。

ClickOnce は両方のモデルのベストを提供します

クライアントコンピューターではなく、Web 用に開発する理由メイン 2 つあります。

最初の理由は、ネットワークにアクセスできるほぼすべてのデバイスに到達するために、アプリケーションを最低共通分母 (Web ブラウザー) に制限する必要があるということです。 Web アプリケーションは、"リッチ" ではなく "リーチ" を目指し、一部の機能を犠牲にして最も多くのクライアントをサポートします。
2 つ目の理由は、インストールの容易さと継続的な更新です。 1 台のコンピューターまたは少数のマシンにバグ修正を適用する機能は、すべてのクライアントに新しいコードを適用する必要がある代わりに、アプリケーションのメンテナンスに時間を節約できます。

Web に接続できるほぼすべてのデバイスで可用性を確保することが目標ですが、"会社の従業員とパートナー" など、少し狭いターゲットユーザーを扱っている場合、リーチはそれほど問題ではありません。対象ユーザーをすべてのユーザーとすべてのユーザーよりも少し減らしたら、ターゲットプラットフォーム (.NET Frameworkをサポートできる Windows マシン) を制限し、完全なデスクトップアプリケーションを構築することでそのプラットフォームを利用できます。 ClickOnce では、アプリケーションの簡単なインストールと自動更新という数式の 2 番目の部分を指定することで、これを行うことができます。

この書籍の後半では、3 つの異なる配置モデル (Web、ClickOnce、および MSI を使用した完全なクライアントインストール) がどのように関連しているか、および特定のアプリケーションに最適な選択肢を決定する方法について説明します。ここでは、次の表に、各配置モデルの機能を示し、ClickOnce が従来の Web とクライアントの世界のギャップを埋める方法を示しています。

特徴	Web	ClickOnce	MSI/クライアント
リーチ	Y
自動デプロイ	Y	Y
システムへの影響が少ない	Y	Y
Per-Userのインストール/実行	Y	Y
豊富でインタラクティブなエクスペリエンス		Y	Y
オフライン		Y	Y
Windows シェル統合		Y	Y
無制限インストール			Y

.NET での既存の展開の機能強化

ClickOnce は、次のバージョンの CLR と.NET Frameworkの新機能ですが、マネージドコードの多くの既存の側面によって可能になります。 .NET の最初のバージョン 1.0 リリースでも、マネージドアプリケーションはアプリケーションの分離と影響ゼロのデプロイ (多くの場合、xcopy デプロイと記述) 用に設計されており、アプリケーションのインストールと更新がこれまで以上に簡単になりました。

.NET の最初のリリースでは、アプリケーションを Web サイトから直接実行することもできます (http://mysite/myapp.exe) 常に最新であることを確認します)。それでも、このアプローチの技術的な制限は大きかったです。 Href-exes (アプリケーションが HTTP アドレスから実行されることがわかっている場合) は、多くの場合、クライアントでセキュリティポリシーの変更を必要とします (つまり、アプリケーションが動作する前に.MSIを実行する必要がありました)。また、ローカルにインストールされている同じアプリケーションよりも実行速度が遅く、ユーザーエクスペリエンスが不足していました (新しいアセンブリで Web サーバーからの読み込みが必要な場合、UI がしばらくフリーズし、実際のオフラインモデルがありませんでした)。

Jamie Cool の "AppUpdater" と MSDN でリリースされた Updater アプリケーションブロックという 2 つの自動更新ソリューションの可用性により、開発者とエンドユーザーのエクスペリエンスが向上しました。どちらのソリューションでも、アプリケーションはローカルコンピューターにインストールされているため、href-exes のパフォーマンスやセキュリティの問題が発生せず、アプリケーションがオフラインでの使用をサポートする可能性がありました。

本書の付録 A では、.NET Frameworkのバージョン 1.1 を引き続き使用しながら使用できるデプロイ方法について詳しく説明します。 ClickOnce は、このサポートレイヤーを基に構築され、さらに簡単になります

ClickOnce の基本的な概念

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

配置オプション

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

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

クライアントコンピューターに影響を与えるインストール (ファイルの関連付けの作成、MSDE のインストール、またはその他の同様のアクションの実行) が必要な場合でも、.MSI ファイルを使用してインストールのその側を処理できます。もちろん、通常の ClickOnce 配置プロセスの外部で行う操作はすべて ClickOnce 機能を減らすことができますが、必要に応じて可能です。

起動済みアプリケーションまたはデプロイ済みアプリケーションを機能させるには、ターゲットコンピューターで.NET Frameworkが必要です。特定の状況に応じて、インストールの前またはインストール自体の一部として、フレームワークをコンピューターに配置するさまざまな方法があります。 .NET Frameworkの展開に関する具体的なトピックと、高度なインストールの一般的な概念の両方について、第 4 章「高度な展開の概念」で説明します。

アプリケーションの更新

更新は展開オプションと同じくらい柔軟であり、特定のタイミング (アプリケーションの開始など) またはアプリケーション開発者が適切な更新 API の呼び出しを選択するたびに更新できます。また、特定の更新プログラムが必要であることを指定して、使用可能な更新プログラムを無視するユーザーの機能を削除することもできます。この必要な更新機能は、継続的な更新プログラムを管理し、ユーザーベース全体をタイムリーに新しいバージョンに移行できるようにするために重要です。

更新プロセスのその他の主な機能には、クライアントまたはサーバーでアプリケーションリリースのロールバックを実行する機能があります。サーバーのロールバックの場合、この管理機能を使用すると、欠陥のある更新プログラムを迅速に削除し、クライアントを以前のバージョンに自動ダウングレードできます。ロールバックのクライアント側は、場合によっては接続されるクライアントにとって重要な機能です。接続、更新、切断した場合、新しいアプリケーションのバージョンがコンピューターで失敗する場合にのみ、再接続しなくても以前のバージョンにロールバックできます。使用可能なすべてのオプションを使用すると、必要な特定の更新機能を実現できますが、概念は独自の章 (第 6 章「アプリケーション更新」) に値するほど複雑です。

マニフェストファイル

配置アクティビティと更新アクティビティは、システムのコンポーネントと発生する必要がある配置アクティビティを記述する XML マニフェストファイルのペアを使用して制御できます。アプリケーションマニフェストは開発者によって作成され (Visual Studio .NET の助けを借りて)、アプリケーションのファイル、依存関係、および基本セキュリティ要件の詳細が示されます。配置マニフェストは管理者が作成することを目的としています (ただし、開発者は開発の初期段階でこのマニフェストを確実に作成します)、アプリケーションの展開と更新の方法について詳しく説明します。これら 2 つのマニフェストファイルは、すべての ClickOnce アプリケーションに含まれているため、本書全体でそれらとそのすべてのオプションが表示されますが、「マニフェストファイルの掘り下げ」の第 8 章で詳しく説明されています。

図 1. マニフェストファイルは連携して、ClickOnce アプリケーションのインストールと更新を有効にします。

この章の後半で、簡単な ClickOnce アプリケーションを構築する際に、Visual Studio .NET によって作成されたマニフェストファイルの基本的なペアの内容が表示されます。マニフェストファイルは、"Whidbey" という名前の Visual Studio .NET コードの次のバージョンの PDC リリースでは署名されませんが、その機能は将来のバージョンに存在します。

セキュリティの概念

ClickOnce より前のセキュリティは、クライアントのコンピューターで href exe を正しく実行するための最大のハードルの 1 つであり、ClickOnce アプリケーションにとって依然として重要な概念です。幸いなことに、アプリケーションの再生が許可されているセキュリティ "サンドボックス" のサイズが大きくなり、このサンドボックスの境界を理解して探索する方がはるかに簡単です。 ClickOnce アプリケーションの自動インストールと自動更新機能により、安全な配置モデルをサポートすることを目的としています。デプロイまたは自動的にダウンロードされたコードは、アクセスできる情報と実行できるアクションに制限されます。アプリケーションが URL から起動されるか、CD からデプロイされているかにかかわらず、ターゲットコンピューターで完全な信頼を持っているとは見なされません。

自動更新アプリケーションの既定のサンドボックスの制限は減りましたが、これまではセキュリティが低下している状況でのみ発生する問題のトラブルシューティングは困難でした。 Visual Studio .NET の Whidbey リリースを使用すると、IDE 内から、およびデバッグツールがアタッチされた状態で、セキュリティが低下した状況でアプリケーションを実行できます。この新機能を使用すると、アプリケーションをテストマシンにデプロイしてセキュリティの問題を表示する必要なく、アプリケーションの開発中にさまざまなセキュリティ設定と制限をシミュレートできます。

「ClickOnce アプリケーションのセキュリティ」の第 5 章では、さまざまな配置オプションの既定のセキュリティ制限について説明し、それらの制限内でプログラミングする方法に関するガイダンスを提供します。アプリケーションを既定の制限セット内で実行できない場合は、第 5 章では、管理者がセキュリティポリシーを調整してクライアントマシンに展開する方法についても説明します。セキュリティポリシーの変更の作成または展開が実用的でない場合は、第 5 章の「アクセス許可の昇格」でも説明されている新しいセキュリティ機能があります。これにより、ユーザーは特定のアプリケーションに関する信頼の決定を行うことができます。

Visual Studio との統合

ClickOnce は Whidbey の重要な機能です。つまり、文書化とサポートに加えて、Whidbey バージョンの Visual Studio .NET に緊密に統合されています。プロパティダイアログを使用すると、公開の詳細を含むさまざまな ClickOnce 情報 (前述の 2 つのマニフェストファイルの作成に使用されます) を指定できます (図 2 を参照)。

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

Visual Studio .NET 統合は、IDE 内で発行と更新の詳細を構成するだけではありません。また、IDE 内から直接アプリケーションを発行するには、[プロジェクト] メニューから [ 発行 ] をクリックし、オプションのクイックウィザードを確認します。このプロセスについては、この章で少し後ほど説明しますが、非常に簡単に使用できます。

ClickOnce ユーザーだけでなく、別の強力な Visual Studio .NET 機能を使用すると、任意のセキュリティコンテキストで (デバッガーがアタッチされた) IDE でアプリケーションを実行できます。この機能は、アプリケーションが実行されるセキュリティ制限を理解するのに役立ちます。また、Visual Studio .NET IDE の完全なツールを使用して、セキュリティ関連の問題を適切にデバッグするのにも役立ちます。

単純な ClickOnce サンプルの作成

ClickOnce の背後にある基本を確認したら、デモを行います。この本の後半にはより高度な例がありますが、今のところは、.NET Frameworkを超える実際の要件がない非常に単純なアプリケーションに焦点を当てます。

メモこれらの手順、スクリーンショット、その他の詳細は、Whidbey の PDC 2003 リリースと対応するバージョンの.NET Frameworkに基づいていることに注意してください。ユーザーインターフェイス要素と手順の正確な詳細は、時間の経過と同時に変更される可能性があります。

最初の「リリース」では、私は絶対に空のアプリケーションから始めます。 (それ以上に簡単にはできませんね?)次に、2 回目のリリースでは、自動更新機能と更新プログラムのロールアウトの基本的なプロセスを確認できるように、いくつかの簡単な機能を追加します。

必要条件

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

開発用コンピューター上の Visual Studio .NET の PDC バージョン。
ファイルを配置してディレクトリを作成できる使用可能な Web サーバー。
.NET Frameworkの PDC バージョンがインストールされているクライアントコンピューター。

すべてを 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 番目のリリースのコードを提供します。そのため、より使い慣れた言語に進んでください。

図 3: 新しい空の Windows アプリケーションプロジェクトを作成する

次に、何も追加せずに、新しいアプリケーションの展開設定の構成に移りました。

展開オプションの構成

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

メモ通常、ClickOnce の基本的な設定には、このプロパティダイアログを使用しません。代わりに、展開の場所とインストールモードのオプションを発行ウィザードの一部として設定します。このオプションは、アプリケーションの発行を選択するたびに実行されます (図 6 の少し後に示します)。ただし、この [プロジェクトのプロパティ] ダイアログを使用して高度なオプションを設定する必要があるため、一度にすべての設定をカバーできるように、このダイアログのすべてのプロパティを設定することにしました。

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

次に、[インストールモード] ラジオボタン (ネットワークの場所から起動されるアプリケーションと、ローカルにインストールされ、Web の場所から更新されるアプリケーションの選択を反映) が [アプリケーションのインストール] に設定されていることを確認します。このサンプルアプリケーションでは、通常の "Windows アプリケーション" スタイルでインストールされているシステムを表示したいと考えました。発行済みアプリケーションの Web ページを作成するオプションがオンになっていることを確認し、[Web ページ名] ボックスに適切な名前が入力されていることを確認します。 "default.htm" を自分で使うのが好きなので、文書フォルダーの既定のページになりますが、任意のファイル名を入力できます。

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

図 4: [アプリケーション更新] ダイアログでは、アプリケーションがソースの場所で新しいバージョンを確認するタイミングと頻度を指定できます。

"必須の更新" と "Update from.." の 2 つの下部の設定。は、アプリケーション更新プログラムを必須として、または以前のリリースとは異なる更新場所で構成するために使用されます。これらの値がまだ設定されていない場合は、設定を図 4 に一致させ、[アプリケーション更新] ダイアログを閉じます。

[ 前提条件 ] ボタンをクリックすると、アプリケーションの実行に必要な基本コンポーネントを指定できます (図 5 を参照)。コンポーネントを前提条件として指定すると、アプリケーションを実行する前にターゲットマシンで実行できるセットアッププログラムにコンパイルされます。このサンプルでは、.NET Frameworkを選択したまま、[前提条件] ダイアログを閉じます。

図 5: [前提条件] ダイアログで、アプリケーションの基本要件を指定します。

[アプリケーションファイル] ボタンを使用すると、アプリケーションで必要なファイルを指定できます。このサンプルでは、一覧に表示されるファイルは.exeだけなので、この時点で最も興味深いオプションではありません。

アプリケーションの発行

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

図 6: 発行ウィザードを使用すると、[プロジェクトのプロパティ] ダイアログから発行設定の一部を変更できます。

このウィザードには 3 つの手順があります。1 つは場所用、もう 1 つは展開の種類 (起動とインストール)、最後の概要手順です。 [プロジェクトのプロパティ] ダイアログで発行オプションを設定し直したので (図 2 を参照)、[ 完了 ] をクリックし、Web サーバーに接続されている Visual Studio として監視し、新しいディレクトリを作成し、一連のファイルをアップロードしました。配置マニフェストは、自動的に作成された Web ページ (publish.htm) とアプリケーションの前提条件をインストールできるSetup.msi プログラムと共に、指定されたディレクトリのルートに配置されました。最上位レベルの下に、現在のバージョンのアプリケーション (/WindowsApplication1_1.0.0.0/、.exe ファイルとアプリケーションマニフェストを含む) 用のディレクトリが作成され、前提条件のインストーラーで使用するために再頒布可能.NET Frameworkを格納する別のディレクトリが作成されました。

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

図 7: 自動生成された Web ページは、ASP.NET Web サービス用に作成されたページと似ていますが、アプリケーションの配置マニフェスト (.deploy ファイル) と、アプリケーションの前提条件のインストーラーへのリンクを提供します。

.NET Frameworkがインストールされていないコンピューターから Web ページにアクセスする場合は、実際のアプリケーションのインストールを試みる前に、[ここをクリックして前提条件をインストールする] リンクをクリックする必要があります。フレームワークがインストールされていない場合、クライアントシステムは .deploy ファイルの種類を処理する方法を知らず、マニフェストを開くか保存するかを尋ねるだけであることに注意してください。

アプリケーションの実行

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

図 8: アプリケーションがコンピューター上の何かを変更する必要がある場合は、インストールの確認を求められます。

メモこの確認ダイアログは、この場合、アプリケーションがスタートメニューに追加され、そのアクションにユーザーの同意が必要であるためにのみ必要でした。アプリケーションをスタートメニューに追加する必要がない場合は、プロンプトなしで実行するだけで済みます。

アプリケーションのインストールを確認したら、インストールプロセスを実行し、[スタート] メニューにショートカットを追加し (図 9 を参照)、アプリケーションを起動しました。スタートメニューのショートカットは Microsoft という名前の下にあります。サンプルアプリケーションのさまざまなプロパティを更新して、より適切な会社名を指定したことはありませんが、そのインストール場所に限定されることはありません。

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

アプリケーションが正常にデプロイされたので、次は変更を加え、作業中に自動更新機能をwatchします。

アプリケーション更新プログラムの発行

サンプルアプリケーションに戻ると、最初のバージョンと更新されたバージョンを明確に区別するための簡単な変更を行いました。目立つものは何でもできますが、単純なメッセージを表示するボタンを追加することにしました。このサンプルと共にフォローしている場合は、アプリケーションに同様に明確な追加を行うか、以下のコードスニペットを使用してまったく同じ追加を行います。

'Visual Basic .NET Code
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# Code
private void button1_Click( 
      object sender, 
      System.EventArgs e)
{
   MessageBox.Show("Greetings!", 
      "New Version", 
      MessageBoxButtons.OK,
      MessageBoxIcon.Information)
}

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

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

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

クライアントの更新

新しい .deploy ファイルが使用可能になったので、元のサンプルを実行すると、自動更新が行われます。更新プログラムに対して指定した設定 (アプリケーションの起動時に更新プログラムをチェックする) を使用すると、ユーザーは新しいバージョンにアップグレードすることを確認するメッセージが表示されます (図 11 を参照)。クライアント更新に関する UI は確実にアルファ状態であり、今後のビルドで置き換えられる予定です。

図 11: 更新プログラムが利用可能になると、ユーザーに通知が表示され、新しいバージョンを受け入れるか無視するか選択できます。

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

メモ ClickOnce アプリケーションの配置で問題が発生した場合は、ターゲットコンピューターに作成されたログを利用する必要があります。現在のユーザーの個人用設定フォルダー (c:\documents と settings\duncanma など) の下を見ると、\Local Settings\My Applications\ フォルダーの下にログが表示されます。

ロングホーンの ClickOnce

Windows クライアントの次のリリースでは、"Longhorn" という名前のコードで、アプリケーションの展開に対する多くの変更が含まれます。ただし、ClickOnce を使用して開発している場合は、Longhorn アプリケーションが ClickOnce アプリケーションの特性と動作の多くを共有するため、これらの変更のほとんどはよく知られています。

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

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

図 12. Longhorn の PDC リリースで実行されている単純な ClickOnce アプリケーション

サンプル ClickOnce アプリケーションを作成する手順 (図 12 に示すように) は、"Longhorn" をターゲットにする場合は変わりません。そのため、この章で前に示したのと同じプロセスに従って、Windows フォームアプリケーションを作成して展開できます (Longhorn と Whidbey の両方が使用可能であると仮定)。 Windows Server 2003 と同様に、ダウンロードが正しく機能するためには、IIS の MIME の種類のセットに .deploy ファイルの種類と .manifest ファイルの種類を追加する必要があることに注意してください。

まとめ

この書籍の残りの部分では、ClickOnce について詳しく説明します。これには、可能な更新と配置のシナリオの範囲、ClickOnce アプリケーションのセキュリティ制限内での作業、自動更新システムの開発と管理に関する高度なトピックが含まれます。うまくいけば、この入門章では、ClickOnce の基本について役立つ情報を提供し、このテクノロジが独自のアプリケーション展開の問題にどのように役立つかについていくつかのアイデアを得ることができました。

著者について

Duncan Mackenzie は、MSDN の Microsoft Visual Basic .NET および Microsoft Visual C# コンテンツストラテジストであり、夜遅くに専用のコーディング担当者です。アールグレーのお茶がないと全く仕事ができないと提案されていますが、見つけ出す必要がないことを願いましょう。Duncan の詳細については、彼のサイトを参照してください。

_________________________

詳細については、「http://www.awprofessional.com/msdotnetseries」を参照してください。

"ClickOnce" を使用したクライアントアプリケーションの配置の概要

内容