アプリケーションの更新には一般に 2 つの方法があります。1 つはユーザーに通知し (電子メールの送信など)、ユーザーに指定された Web サイトのアドレスから更新プログラムをダウンロードするよう依頼する方法です。もう 1 つは、更新の責任をユーザーからユーザーに移す方法です。ユーザーがソフトウェア更新を取得してインストールするのではなく、クライアント アプリケーション自体が既知のサーバーから更新をダウンロードしてインストールする必要があります。ユーザーが行う必要がある唯一の介入は、新しい更新を今すぐインストールするかどうかを決定することです。後で。明らかに、後者の方が前者よりもフレンドリーです。 Windows XP や Microsoft Money など、後者のアプローチに似た実際の製品を確認できるようになりました。この記事で紹介した .NET アプリケーション更新コンポーネントは、同様の機能を提供できます。
1. .NET アプリケーション更新コンポーネントの概要
.NET アプリケーション更新コンポーネント AppUpdater は、.NET Framework を使用して開発されています。 AppUpdater は Microsoft 製品ではありませんが、コンポーネントを VS.NET ツールバーに追加する限り、他のコンポーネントを使用するのと同じように、いくつかのプロパティ (場所など) を設定した後、コンポーネントをツールバーからアプリケーションにドラッグ アンド ドロップできます。アップデートの取得頻度など）を考慮して、クライアントアプリケーションに自動アップデート機能を持たせることができます。
2. 動作原理
.NET クライアント アプリケーション更新コンポーネントの動作原理を深く理解するには、クライアント アプリケーション更新を実装するために何を行う必要があるかを注意深く検討する必要があります。最初のステップは、アップデートがあるかどうかを確認することです。アップデートが見つかったら、2 番目のステップを開始し、アップデートのダウンロードが完了したら、最後のステップに進み、アップデートを実装します。
(1) 更新を確認する。
開発者は、まずどこで更新を確認するかをアプリケーションに指示する必要があります。そうしないと、干し草の山から針を探すようなものではないでしょうか。次に、いつ更新をチェックするかを決定します。ユーザーが毎回クライアント プログラムを実行することは不可能であり、バックグラウンドで常に更新をチェックしているのは、なんともリソースの無駄です。最後に対処すべき重要な点は、更新を確認する方法です。 .NET Application Update コンポーネントは通信に HTTP を使用するため、クライアント アプリケーションはファイアウォールを介して更新を実行できます。そして更新チェックに必要なアドレスは既知のWebサーバーのURLアドレスとなり、第一の問題は無事解決されました。
.NET アプリケーション更新コンポーネントは、コンポーネントの生成に基づいてスレッドを生成し、更新チェックを担当します。このスレッドはほとんどの時間スリープ状態ですが、設定された間隔で起動して更新チェックを実行します。アプリケーションが新しい更新を確認する頻度は、アプリケーションによって異なります。更新チェックの間隔の一般的な値は、通常 1 時間から数日の範囲です。ポーリングに対するこの基本的なアプローチは、あらゆる状況に適しているわけではありません。たとえば、Microsoft Money は、ユーザーが要求した場合にのみ更新をチェックします。この場合、更新ポーリング スレッドを無効にすることができます。
更新チェックは、コマンドで更新コンポーネントの CheckForUpdate() メソッドを呼び出すことによって実装されます。
更新チェックを実行するにはいくつかの方法があります。
方法 1: ファイルを直接チェックする - HTTP を使用して、サーバー アプリケーションとクライアント アプリケーションの最終変更日時スタンプを比較し、それらが一致しているかどうかを確認します。サーバー上に更新されたファイルがある場合、クライアントは自身を更新できることを認識します。 Web ブラウザーにも同じことが当てはまり、HTML ページまたは画像を再ダウンロードする必要があるかどうか、または以前にダウンロードしたものを再利用できるかどうかを認識します。アプリケーションの新しいバージョンが利用可能になると、管理者はその新しいバージョンを Web サーバー上の古いバージョンにコピーするだけです。このアプローチの問題は、更新が自動ではないため、失敗する可能性があることです。たとえば、管理者が Web サーバー上のアプリケーションのバージョンを更新し、顧客が更新前のバージョンをダウンロードしている場合、顧客のコンピュータには、更新前のファイルと新しいバージョンのファイルがいくつか存在することになります。更新後のバージョン。上記の理由により、ファイルの更新を直接チェックすることは重要なアプリケーションには推奨されません。
方法 2: 明示的なチェック - サーバー上の明示的な構成ファイルを使用します。 .NET アプリケーション更新コンポーネントで使用する有効なサーバー明示的ファイルは次のようになります。 ..
<VersionConfig>
＜利用可能なバージョン＞1.0.0.0＜/利用可能なバージョン＞
＜アプリケーションURL＞ http://localhost/demos/selfupdate/V1/ ＜/
アプリケーションURL＞
</VersionConfig>
AvailableVersion は、利用可能な最新のアセンブリのバージョン番号を指定します。 ApplicationURL 属性は、このバージョンのアプリケーションが存在する URL アドレスを指定します。管理者がクライアント アプリケーションを更新する場合は、アプリケーションの新しいバージョンを Web サーバーにコピーし、サーバーの明示的ファイルを適切に変更します。クライアント自体は、サーバーの明示的ファイルが変更されたことを検出し、明示的ファイルをダウンロードします。次に、クライアントは、明示的ファイルで指定されたアセンブリのバージョン番号とアプリケーション EXE ファイルのバージョン番号を比較します。サーバーの明示的ファイルで新しいバージョン番号が利用可能な場合、アプリケーションはそれを更新する必要があることを認識します。この方法は、ほとんどのアプリケーションに推奨されます。
方法 3: XML Web サービスのチェック - XML WebServices は、より高度な更新チェック方法を提供します。たとえば、他のユーザーを更新する前に、一連の初期ユーザーを更新するとします。クライアント アプリケーションが XML Web サービスを呼び出して、更新が利用可能かどうかを確認する場合、その XML Web サービスはその更新ユーザーについてデータベースにクエリを実行することもできます。ユーザーが初期ユーザーであるかどうかを判断します。初期ユーザーの場合、XML Web サービスは更新が利用可能であることを示す値を返します。そうでない場合、Web サービスは更新が利用できないことを示す値を返します。ただし、この記事で紹介する .NET アプリケーション更新コンポーネントは、XML Web サービスの直接サポートを提供しません。
XML Web サービスを使用して更新チェックを実行するには、まず XML Web サービスを作成し、OnCheckForUpdate イベントをフックします。これにより、ポーラー スレッドの更新チェックの代わりに独自のカスタム チェックを作成できます。 OnCheckForUpdate イベントには、更新が検出されたかどうかを示す戻り値があります。
(2) 更新のダウンロード
.NET アプリケーション更新コンポーネントが新しい更新が利用可能であることを検出すると、自動的に別のスレッドを開始し、更新の非同期バックグラウンド ダウンロードを開始します。
ダウンロードはHTTP-DAVを使用して行われます。 DAV は HTTP の拡張バージョンであり、ディレクトリやファイルの列挙などの機能を提供します。完全なダウンロード プロセスは、URL を指定することで始まります。ダウンロードに使用される URL は、更新チェックを完了するために使用された方法によって異なります。たとえば、サーバー明示的ファイルを使用する場合、更新のダウンロードに使用される URL は、サーバー明示的ファイルの ApplicationURL 属性によって指定されます。
アップデートのダウンロードには明らかにある程度の堅牢性が必要です。クライアント アプリケーションをダウンロードして更新した後、不安定な状態のままにすることは容認できません。ダウンロード プロセス中には、さまざまな問題が発生する可能性があります。更新ファイルが属する Web サーバーがダウンしたり、クライアント マシンがクラッシュしたり、ユーザーが何らかの理由でアプリケーションを閉じたりする可能性があります。アプリをダウンロード中のため、アプリを閉じるとダウンロードが停止します。別の設計ソリューションは、アプリケーションのダウンロードと更新に別のシステム サービスを使用することです。システム サービスを使用すると、アプリケーション自体が実行されていない場合でも、更新プログラムのダウンロードが続行されます。実際、Windows XP には、この目的を果たす BITS と呼ばれるダウンロード サービスが組み込まれています。 BITS は、Windows XP によって Windows 自体をダウンロードして更新するために使用されます。 BITS の詳細については、 http://msdn.microsoft.com/library/en-us/dnwxp/html/WinXP_BITS.asp を参照してください。このサービスは .NET Application Update コンポーネントでは使用されないため、システム サービスをサポートしていない Windows 9x で使用できます。
(3) アップデートの実装
.NET アプリケーションのアップデート コンポーネントは、ダウンロードとアップデートのプロセスを 2 つの別々のフェーズに分割することで堅牢性を高めます。各ステージが完了すると、クライアント アプリケーション ディレクトリにある更新されたマニフェスト ファイルに記録されます。ダウンロードまたは更新のプロセスがいずれかの段階で中断された場合、次回アプリケーションが起動されたときに、最後に完了したブレークポイントから元の作業が再開されます。各ステージは再実行可能で、ステージの途中で失敗しても再実行すると成功します。ダウンロード中にサーバーへの接続が失われるなどのエラーが発生した場合、.NET 更新コンポーネントは後で再試行します。報告されるエラーが多すぎる場合 (たとえば、Web サーバーがオンラインに戻らない場合)、ダウンロードと更新は中止され、エラーが報告されます。
最初のアプローチは、単に別のプロセスを開始して更新を実装することです。この別個のプロセスは、最初にアプリケーション プロセスをシャットダウンし、更新を実装し (ロックが解除されているため)、アプリケーション プロセスを再起動し、完了するとアプリケーション プロセス自体をシャットダウンします。したがって、この設計には 3 つの基本的な問題があります。
場合によっては、機能しません。アプリケーションが更新されると、更新プロセスは元のアプリケーション プロセスを終了し、更新プロセス自体も終了するため、更新は実装されません。
更新が必要なすべてのコードを自動的に更新できるようにしたいと考えています。アプリケーションだけでなく、.NET Application Update コンポーネント自体にもパッチを自動的にインストールできる機能が必要です。このモードを使用すると、更新を実装するプロセスを更新できません。
. 使用中にユーザーにアプリケーションを閉じて待つことを強制するのは失礼です。
アプリケーションの更新を実装するために使用される最後の方法は、.NET Framework の並列アセンブリ パターンを使用することです。アプリケーション自体を更新する代わりに、現在の既存のバージョンよりも新しいバージョンのアプリケーションを生成します。
新しいバージョンは、現在存在するアプリケーション カタログとダウンロードされた更新バージョンをマージすることで生成できます。新しいバージョンが完成すると、ユーザーは次回アプリを再度開いたときに自動的に新しいバージョンを使用するようになります。元のアプリケーションのコピーは削除できます。難しいのは、特定の時点でどのバージョンをロードすべきかを判断することです。 Appstart という名前のアプリケーションを紹介します。 Appstart はアプリケーションへのエントリ ポイントです。このモードを使用すると、アプリケーション ディレクトリは次のようになります: ..
--> Program Files
--> MyApp
--> Appstart.exe
--> Appstart.config
--> V1 Folder
-- > MyApp.exe
--> V1.1 フォルダ
--> MyApp.exe
アプリケーションを実行するには、通常、Appstart.exe を起動します。デスクトップにショートカット キーを置きたい場合、そのショートカット キーはアプリケーションを直接指すのではなく、Appstart を指す必要があります (AppStart.exe の名前は、YourApp.exe など任意の名前に変更できることに注意してください)。 Appstart.config ファイルを読み取り、指定されたアプリケーションをロードする非常に単純なプログラムです。有効な Appstart.config ファイルは次のようになります:
<Config>
＜アプリフォルダ名＞V1フォルダ＜/アプリフォルダ名＞
＜AppExeName＞MyApp.exe＜/AppExeName＞
＜AppLaunchMode＞appdomain＜/AppLaunchMode＞
＜/構成＞
AppFolderName は、現在実行中のアプリケーションのバージョンを含むサブフォルダーを指定します。 AppExeName には、そのフォルダーにロードされる exe ファイルの名前が含まれます。アプリケーションの更新が完了したら、最後のステップとして、アプリケーションの新しいバージョンを指すように AppFolderName の値を変更します。こうすることで、次回ユーザーがアプリケーションを実行するときに、アプリケーションの新しい更新バージョンが実行されます。 AppLaunchMode は、アプリケーションのロード方法を指定します。アプリケーションをロードするには 2 つの方法があります。 1 つ目は、AppDomain を使用する方法です。 AppDomains は、.NET Framework 共通言語ランタイムの機能であり、独立した論理ユニットおよび管理オブジェクトでもあります。共通言語ランタイムでは、プロセスごとに複数のアプリケーション ドメインが許可されます。このようにして、Appstart.exe は、別の AppDomain にある同じ AppStart.exe プロセスにアプリケーションを読み込むことができます。 2 つの異なる exe プログラム (Appstart.exe と MyApp.exe) が実行されているにもかかわらず、使用されているプロセスは 1 つだけです。 AppDomain はほとんどのアプリケーションで問題なく動作しますが、別の AppDomain で実行する場合と別のプロセスで実行する場合には微妙な違いがいくつかあります。この場合、AppLaunchMode を「プロセス」に設定すると、アプリケーションが別のプロセスで読み込まれるようになります。
Appstart がアプリケーションを起動すると、アプリケーションが終了するのを待ってスリープ状態になります。アプリケーションが終了すると、Appstart も閉じられます。
3. サンプルウォークスルー
先ほど、.NET アプリケーションの更新がどのように機能するかを説明しました。次に、それをサンプルに適用してみましょう。
ステップ 1: 更新するアプリケーションを作成する
1. VS.NET を使用して、「SampleApp」という名前の新しい Windows アプリケーション プロジェクトを生成します。
2. フォームに好みの背景色を付けます。以降の更新バージョンと区別するために背景色を使用します。
3. 次に、このアプリケーションに微妙な機能を追加しましょう。まず、フォームにボタンを追加します。圧縮ファイルには、単純な Windows フォームのアセンブリが含まれています。圧縮ファイルに SamplesSampleAppSimpleForm アセンブリへの参照を追加します。次に、ボタン イベント ハンドラーに 2 行のコードを追加します。
..
SimpleForm.Form1 F = 新しい SimpleForm.Form1();
F.Show();
4. ビルド フラグをデバッグからリリースに変換します。これにより、後で元のコピーの実行中にアプリケーションの新しいバージョンをビルドするときに、pdb ファイルのロックの問題を回避できます。アプリケーションを構築してテストします。
ステップ 2: .NET アプリケーション更新コンポーネントを追加する
1. VS.NET ツールバーの [コンポーネント] タブで、右クリックして [ツールバーのカスタマイズ] を選択します。 「.NET Framework コンポーネント」タブを選択します。 「参照」をクリックし、圧縮ファイル内の AppUpdater プロジェクトの下にある AppUpdater.dll を選択し、「OK」をクリックします。
2. AppUpdater アイコンがツールバーのコンポーネント リストの下部に表示されます。 AppUpdater コンポーネントを SampleApp フォームにドラッグ アンド ドロップします。 appUpdater1 という名前の .NET Application Update コンポーネントのインスタンスがフォームの下部に表示されます。
ステップ 3: .NET アプリケーション更新コンポーネントをセットアップする
このステップでは、.NET アプリケーション更新コンポーネントをセットアップします。この例では、最初の 4 つのプロパティのみを変更する必要があり、残りはデフォルト値のままにすることに注意してください。
AppUpdater 属性: これは、.NET アプリケーションのアプリケーション更新の中核です。このプログラムに対して次の設定を行う必要があります。
(1) AutoFileLoad: これは、後で説明するコマンドのダウンロード特性を制御します。
(2) ChangeDetectionMode: この列挙は、更新を確認する方法を決定します。この例では、サーバーの明示的なチェックを使用するため、この値を「ServerManifestCheck」に設定します。
(3) ShowDefaultUI: .NET アプリケーション更新コンポーネントには、新しい更新が利用可能になったことや更新中に発生したエラーなど、いくつかのイベントをユーザーに通知するための一連のユーザー インターフェイスがあります。この UI は、デフォルトの UI を無効に設定し、適切なイベント (例:
OnUpdateComplete)、カスタム ユーザー インターフェイスをポップアップします。この例では、デフォルトのユーザー インターフェイスを使用するため、この値を true に設定します。
(4) UpdateUrl: UpdateUrl は、更新プログラムが更新を検索する場所を決定します。この例では、サーバー明示的ファイルを使用して更新をチェックしているため、このプロパティはサーバー明示的ファイルの URL に設定する必要があります。
この例では、 http://yourWebserver/SampleApp_ServerSetup/UpdateVersion.xmlに設定します。 「yourWebserver」を Web サーバー名に置き換えてください。
Downloader プロパティ: AppUpdater コンポーネントには 2 つのサブコンポーネントがあります。 1 つ目は Downloader と呼ばれ、コンポーネントのダウンロード プロパティと Poller プロパティを制御します。 AppUpdater の 2 番目のサブコンポーネントは Poller で、更新チェックを制御します。
(1)AutoStart: アプリケーションの起動時にポーラーがポーリングを開始するか、計画された更新クエリが開始されるまで待機するかを制御するブール値。
(2) DownloadOnDetection: ブール値。新しい更新が検出されたときにすぐに Poller が更新のダウンロードを開始するか、DownloadUdpate() メソッドを呼び出して明示的にダウンロードを開始するかを制御します。
(3)InitialPollInterval: アプリケーション起動後、最初の更新チェックを行うまでの待機秒数。
(4)PollInterval: 最初の更新チェックの後、PollInterval は後続の更新チェック間の秒数を制御します。 注: デフォルトでは 30 秒ごとにチェックが行われるため、アプリケーションの更新チェックの頻度を減らす必要があります。 。
これをすべて完了すると、プロパティ テーブルは次のようになります。
SamplesSampleAppSampleApp_Complete ディレクトリには、正しくインストールされたバージョンのアプリケーションが含まれています。
インストール:
(1)DownloadRetryAttempts: ダウンロード中にエラーが発生した場合 (Web サーバーがダウンしているなど)、ダウンローダーは後で再試行します。このプロパティは、ダウンローダーがネットワーク要求を完全なアプリケーション更新エラーと見なすまでに再試行する回数を制御します。
(2)SecondsBetweenDownloadRety: ネットワーク要求を再試行するまでに待機する秒数。
(3)UpdateRetryAttempts: アップデート中に重大なエラーが発生した場合(ダウンローダーのリトライ回数を超えた場合など)、アプリケーションアップデートエラーが発生します。デフォルトでは、更新の試行は停止されます。ただし、次回アプリケーションを起動するときに回復しようとします (たとえば、Web サーバーの更新が数日間停止する可能性があります)。このプロパティは、更新を試行する回数を制御します。この値を超えると、アップデーターは更新をキャンセルし、状態をリセットし、更新チェックに戻ります。
(4)ValidateAssemblies: この属性は、ダウンロードされたアセンブリが効果的に完了するレベルを制御します。詳細については、この記事の「セキュリティ」セクションを参照してください。
ステップ 4: アプリケーション V1 バージョンを生成してクライアントにデプロイします。
SampleApp プロジェクトで、AssemblyInfo.cs ファイルを開きます。 AssemblyVersion の値を「1.0」から「1.0.0.0」に変更します。これにより、アセンブリをビルドするときに、VS.NET が増分として通常指定する値ではなく、値 "1.0.0.0" を持つタグが取得されます。
1. アプリケーションをビルドします。
2. 圧縮ファイルから SamplesSampleAppSampleApp_ClientSetup ディレクトリをローカル マシンにコピーします。このディレクトリにはすでに AppStart.exe が含まれていることに注意してください。 AppStart.config は 1.0.0.0 ディレクトリをポイントし、SampleApp.exe を起動するように設定されています。
SampleApp (Appupdater.dll、SimpleForm.dll、および SampleApp.exe) を、SampleApp のリリース ディレクトリから
クライアントの SampleApp_ClientSetup1.0.0.0 ディレクトリにコピーします。この時点で、完全に機能するバージョンのアプリケーションがクライアントに「インストール」されており、AppStart.exe を実行することで実行できるようになります。
ステップ 5: Web サーバーをインストールする
このステップでは、更新ポーリング機能を提供するために Web サーバーをインストールします。 .NET Application Update コンポーネントは HTTP-DAV を使用してアプリケーションの更新をダウンロードするため、HTTP-DAV をサポートする Web サーバーが必要です。 Windows 2000 以降のオペレーティング システム上の IIS5.0 は HTTP-DAV をサポートします。
1. Samples/SampleApp_ServerSetup ディレクトリを Web サーバーの wwwroot ディレクトリにコピーします。
2. SampleApp の V1 バージョンを Web サーバーの 1.0.0.0 フォルダーにコピーします。
3. Web サーバー上の SampleApp_ServerSetup ディレクトリに対する IIS の「ディレクトリ参照」権限を有効にします。
ステップ 6: アプリケーションを自動的に更新する
OK、... ここで、新しいバージョンを自動的にインストールして、このすべての大変な作業の結果を確認します。
1. クライアントに展開した SampleApp のバージョンが実行されていない場合は、それをロードして、必ず AppStart.exe を使用して実行します。
2. VS.NET に戻り、SampleApp フォームにいくつかの顕著な変更を加えます (背景色の変更など)。
3. AssemblyInfo.cs のバージョン情報を 2.0.0.0 に変更します。
4. 再生します。
5. Web サーバーに戻り、ディレクトリ 1.0.0.0 と同等のディレクトリ 2.0.0.0 を生成します。アプリケーションの新しいバージョンを、リリース生成ディレクトリから Web サーバー上に新しく作成された 2.0.0.0 ディレクトリにコピーします。
6. UpdateVersion.xml を開き、AvailableVersion を 2.0.0.0 に変更します。新しい 2.0.0.0 パスを指すように ApplicationURL を変更します。
7. UpdateVersion.xml に加えた変更を保存します。
新しい UpdateVersion.xml を保存すると、30 秒以内に SampleApp のコピーを実行すると、利用可能な新しいバージョンが検出されます。
4. オンデマンド インストール、セキュリティ、スケーラビリティ、およびデバッグ
(1) オンデマンド インストール
いわゆるオンデマンド インストールとは、メインの実行可能プログラムのみがクライアント コンピュータに明示的にインストールされることを意味します。アプリケーションの残りの部分は、基本的なニーズに基づいて自動的にダウンロードしてインストールできます。
.NET アプリケーション更新コンポーネントの AutoFileLoad プロパティを通じてオンデマンド インストールを開始します。アプリケーション内のアセンブリ境界がどこにあるのか、またどのようなアクションによってアセンブリがダウンロードされるのかを慎重に検討する必要があります。アセンブリのダウンロードにはネットワークの入出力が含まれるため、ダウンロードにかかる時間は変動します。アセンブリのダウンロード中、アプリケーションはアセンブリのダウンロードが完了するまで待機してフリーズします。
(2) 導入
アプリケーションの更新を自動的に安全にインストールできる機能には多くの利点がありますが、潜在的な危険も伴います。アップデートのインストールを容易にすると、注意しないと悪意のあるコードのインストールも容易になってしまう可能性があります。 2 つの危険があります。1 つ目の危険は、誰かが独自の Web サーバーを使用して、更新の展開に使用される Web サーバーを騙すことです。彼らはその Web サーバーを使用して、アプリケーション パスにウイルスをインストールする可能性があります。ネットワーク上でのスプーフィングやその他の不適切な干渉を防ぐ最も簡単な方法は、HTTPS を使用することです。 .NET Application Update コンポーネントで HTTPS を使用するには、HTTP URL を HTTPS URL に置き換えるだけです。もちろん、HTTPS は特効薬ではありません。 HTTPS の使用には 2 つの問題があります。1 つはスケーラビリティです。 HTTPS を使用するには、サーバーが Web サーバーからダウンロードしたすべてのファイルを暗号化する必要があります。アプリケーションの更新ファイルが大きい場合、更新ファイルの暗号化コストによりサーバーに過度の負担がかかる可能性があります。 HTTPS の使用に関するもう 1 つの問題は、2 番目のセキュリティ上の危険に何の役にも立たないことです。 2 番目の危険は、ハッカーがサーバーの外部だけでなく内部からも攻撃できることです。攻撃が成功すると、数百または数千のクライアントも自動更新の影響を受ける可能性があり、壊滅的な事態になります。
この問題を解決するために、.NET Application Update コンポーネントは、.NET アセンブリの厳密な名前機能を使用して、ダウンロードされたアセンブリを検証します。ダウンロード中にアセンブリがキーで署名されていないことが .NET Application Update コンポーネントによって検出された場合、ダウンロードはキャンセルされます。これは、アプリケーションの秘密キーを持っている人だけが、自動的に展開できる更新を作成できることを意味します。
アセンブリが有効であることを確認するために、.NET Application Update コンポーネントは、現在インストールされているアプリケーション実行可能ファイルの公開キーと、ダウンロードされた更新プログラムの公開キーが一致することを確認します。 2 つのアセンブリが同じ秘密秘密キーで署名されている場合、埋め込まれた公開キーは同じになります。 CLR によって読み込まれるアセンブリは公開キーを検証するため、CLR は通常のハッシュ チェックを計算して、アセンブリが実際に本物のアセンブリであり、改ざんされたアセンブリではないことを確認します。ダウンロード時の検証を有効にするには、すべてのアプリケーション アセンブリに厳密な名前を追加し、.NET Application Update コンポーネントの ValidateAssemblies プロパティを true に設定します。
ダウンロード時のアセンブリ検証は非常に役立ちますが、実際には、アプリケーションには異なる秘密キーで署名されたコンポーネントが含まれることがよくあります。たとえば、アプリケーションに 2 つのファイルが存在する場合があります。1 つは秘密キーで署名された実行可能アセンブリ、もう 1 つはアプリケーションで購入して使用したサードパーティのグラフ コントロールを含む DLL アセンブリです。サードパーティのアセンブリは、自分の秘密キーの代わりにサードパーティの秘密キーを使用して署名される場合があります。状況をさらに複雑にするのは、アプリケーション内のアセンブリの署名に使用される有効な秘密キーの設定が、バージョン番号ごとに異なる場合があることです。これらのアプリケーションの種類を自動的に更新するにはどうすればよいですか?この問題を解決するには、有効な公開キーのリストを含むアセンブリをアプリケーションで生成します。アプリケーションのマスター秘密キー (アプリケーションの exe ファイルの署名に使用されるキー) を使用してアセンブリに署名し、アプリケーションの更新ファイルが含まれる Web サーバー上のディレクトリにアセンブリを配置します。更新プログラムのダウンロード プロセスが開始される前に、.NET アプリケーション更新コンポーネントは、Web サーバー上のアプリケーション更新ディレクトリに「AppUpdaterKeys.dll」という名前のアセンブリがあるかどうかを確認します。存在する場合、アセンブリがダウンロードされます。アセンブリは、メイン アプリケーションの公開キーと照合して検証されます。署名が有効であれば、キーリストが抽出されます。今後、このリスト内のすべてのキーは、更新されたファイルの有効な署名とみなされます。
推奨されるセキュリティ手法は、更新チェックに HTTPS URL を使用することです。これにより、第 1 レベルのスプーフィング保護が提供されます。アップデートのダウンロードでは、Web サーバーの過負荷を避けるために HTTPS RL を使用しないことをお勧めします。代わりに、アプリケーションのアセンブリに厳密な名前を追加し、アセンブリ検証機能を使用してください。
(3) スケーラビリティ
この記事で前述した例では、コンポーネントをアプリケーションにドラッグ アンド ドロップし、自動デプロイメントを実現するためにいくつかのプロパティを設定しました。
これは多くのアプリケーションでうまく機能しますが、一部のアプリケーションでは、コードを記述することによってのみ実現できる高度な制御が必要になります。オーバーライドされた CheckForUpdate() メソッドと applyUpdate() メソッドを使用して、チェックと更新の動作をカスタマイズすることで、.NET アプリケーション更新コンポーネントの標準プロセスを置き換える独自のコードを作成できます。
(4) デバッグ
このセクションでは、推奨されるデバッグ オプションをいくつか示し、このコンポーネントのユーザーが直面する最も一般的な問題について説明します。
.NET Application Updater は、AppStart.exe と同じディレクトリに AppUpdate.log という名前の隠しログ ファイルを生成します。
すべての更新の成功および失敗の情報は、このログに記録されます。ログ ファイルは、特定のクライアントが正常に更新できない場合に特に役立ちます。
ログを使用して、更新がいつどのように失敗したかを判断できます。さらに、.NET Application Update コンポーネントは、.NET Framework の Debug クラスを使用して、豊富な有用な情報を出力します。デバッガーでアプリケーションを実行すると、出力ウィンドウにこの情報が表示されます。 .NET Application Updater のログをたどって、問題のある領域を強調表示して見つけることができます。
何らかの理由で .NET Application Updater を動作させることができない場合は、デバッグを開始する前に次のことを確認してください。発生している問題は次のいずれかである可能性があります。 ..
IIS を参照しましたか。ディレクトリは開いていますか?そうでない場合、アップデーターはファイルをダウンロードしてインストールしません。
すべてを正しくデプロイし、URL を正しく設定しましたか?
アプリケーションがプログラム ファイル ディレクトリにインストールされている場合、あなたはそのマシンのスーパー管理者またはスーパー ユーザーですか?そうでない場合は、アプリケーションを更新するための書き込みアクセス権がありません。
アプリケーションのメイン UI スレッドで AppUpdater オブジェクトを生成していますか?そうでない場合、アップデーターは UI を表示できず、UI にイベントを発行するときに失敗します。
更新は成功しましたが、アプリケーションは新しい更新で自動的に再起動できませんか? .NET Application Update コンポーネントは、Application.Exit メソッドを呼び出してアプリケーションを終了しようとします。ただし、この方法ではアプリケーションを閉じることが保証されません。別のスレッドを生成して実行したままにする場合、このメソッドはプロセスをシャットダウンできません。すべてのスレッドの終了を保証する解決策は、Application.OnExit イベントを呼び出すか、.NET アプリケーション アップデーターの OnUpdateComplete イベントにフックしてシャットダウンを自分で処理することです。
5. まとめ
クライアント アプリケーションの便利な展開は、.NET Framework の最初のバージョンの重要な目標です。 .NET Framework の使用は、展開の問題を解決するクライアント アプリケーションを構築するための優れた手法です。導入の容易さは、.NET Framework の今後の新しいバージョンにとっても重要な目標であり続けます。解決策として、ここで説明する .NET アプリケーション更新コンポーネントは、.NET Framework の将来のバージョンで直接使用できるアイデアの一部を表しています。ただし、その時期が来るまでの期間では、.NET アプリケーション更新コンポーネントは、自動更新アプリケーションの構築を開始するための重要な方法と見なすことができます
。後ほど参照します。