次の方法で共有


開発者以外が配置する ClickOnce アプリケーションの作成

ClickOnce 配置を作成するすべての開発者がアプリケーションの配置を自ら計画するわけではありません。 多くは ClickOnce を使用してアプリケーションをパッケージ化し、ファイルを大企業のような顧客に渡すだけです。 アプリケーションをネットワーク上でホストするのは、顧客の責任です。 このトピックでは、Version 3.5 より前のバージョンの .NET Framework でのそうした配置でよく発生する問題のいくつかを検討します。 次に、.NET Framework 3.5 の新機能である "マニフェストの信頼用の使用" を使うことによる新しい解決方法について説明します。 最後に、以前のバージョンの .NET Framework を現在も使用している顧客向けに ClickOnce 配置を作成する場合の推奨される方法について説明します。

顧客向け配置の作成に伴う問題

顧客に配置を提供する計画を立てる際に、いくつかのことが問題になります。 最初の問題は、コード署名に関係する問題です。 ネットワーク全体に配置するためには、ClickOnce 配置の配置マニフェストとアプリケーション マニフェストの両方がデジタル証明書を使用して署名されている必要があります。 ここで、マニフェストの署名に使用するのは、開発者の証明書と顧客の証明書のどちらかという疑問が出てきます。

ClickOnce アプリケーションの ID は配置マニフェストのデジタル署名に基づくので、どの証明書を使用するかという問題は重要です。 配置マニフェストに開発者が署名すると、顧客が大企業であり、複数の部門がアプリケーションのカスタマイズ バージョンを配置する場合に、競合を引き起こす可能性があります。

たとえば、Adventure Works 社に財務部と人事部があるとします。 この 2 部門は両方とも、SQL データベースに格納されたデータからレポートを生成する ClickOnce アプリケーションのライセンスを Microsoft Corporation から供与されています。 Microsoft は各部門に、それぞれのデータに合わせたアプリケーションのカスタマイズ バージョンを提供します。 各アプリケーションが同じ Authenticode 証明書を使用して署名された場合は、ユーザーが両方のアプリケーションを使用しようとすると、エラーになります。ClickOnce は、2 番目のアプリケーションを最初のアプリケーションと同一であると見なすからです。 この場合、予測不能な望ましくない副作用が起こる可能性があります。これには、アプリケーションがローカルに格納したデータの消失が含まれます。

コード署名に関連する別の問題は、配置マニフェスト内の deploymentProvider 要素です。ClickOnce は、アプリケーションの更新の場所を、この要素から知ります。 この要素は、署名する前に配置マニフェストに追加しておく必要があります。 この要素を後で追加すると、配置マニフェストの再署名が必要です。

顧客への配置マニフェスト署名の要求

こうした一意でない配置の問題の 1 つの解決方法は、アプリケーション マニフェストには開発者が署名し、配置マニフェストには顧客が署名することです。 この方法はうまくいきますが、他の問題をもたらします。 Authenticode 証明書という資産は保護されていなければならないので、顧客は配置への署名のために証明書を開発者に提供するわけにはいきません。 顧客は、.NET Framework SDK の自由に利用できるツールを使用することにより、自ら配置マニフェストに署名することができます。しかし、顧客の意欲や能力を超えた技術知識が求められることがあります。 このような場合は通常、開発者がアプリケーションや Web サイトなどの手段を構築し、顧客はそれを通じてアプリケーションの顧客のバージョンへの署名を求めて送信できるようにします。

ClickOnce アプリケーションのセキュリティへの顧客署名の影響

顧客がアプリケーション マニフェストに署名することに開発者と顧客が合意したとしても、特に信頼されたアプリケーションの配置に適用する場合に、アプリケーションの ID に関連する他の問題が出てきます。 この機能の詳細については、「信頼されたアプリケーションの配置の概要」を参照してください。 Adventure Works 社が、Microsoft Corporation から提供されたアプリケーションはどれも完全信頼で実行できるようにクライアント コンピューターを構成することを考えているとします。 Adventure Works が配置マニフェストに署名すると、ClickOnce は Adventure Works のセキュリティ署名を使用して、アプリケーションの信頼レベルを判断します。

アプリケーション マニフェストを信頼用に使用することによる顧客配置の作成

.NET Framework 3.5 の ClickOnce には、開発者と顧客にとってマニフェストへの署名方法のシナリオの新しい解決方法となる新機能が含まれています。 ClickOnce アプリケーション マニフェストは、<useManifestForTrust> という新しい要素をサポートします。開発者はこの要素を使用することにより、アプリケーション マニフェストのデジタル署名が、信頼の決定を行うために使用されるものであることを示すことができます。 開発者は、ClickOnce パッケージ化ツール (Mage.exe、MageUI.exe、Visual Studio) を使用して、発行者名とアプリケーション名の両方をアプリケーション マニフェストに組み込むだけでなく、この要素もアプリケーション マニフェストに含めます。

<useManifestForTrust> を使用する場合、配置マニフェストは、証明機関が発行した Authenticode 証明書を使用して署名している必要はありません。 代わりに、いわゆる自己署名証明書を使用して署名できます。 自己署名証明書は、顧客または開発者のどちらかが .NET Framework SDK の標準ツールを使用して生成した後、ClickOnce 配置の標準ツールを使用して配置マニフェストに適用されます。 詳細については、「Makecert.exe (証明書作成ツール)」を参照してください。

配置マニフェストに自己署名証明書を使用すると、いくつかの利点があります。 <useManifestForTrust> を使用すると、顧客が Authenticode 証明書を取得または作成する必要がなくなるので、顧客にとって配置が簡単になります。一方開発者も、自社の商標 ID をアプリケーションで維持できるようになります。 結果として、より安全で、一意のアプリケーション ID を持つ署名された配置のセットになります。 これにより、複数の顧客に同じアプリケーションを配置するときに起こる場合がある競合の可能性がなくなります。

<useManifestForTrust> を有効にして ClickOnce 配置を作成する方法の手順については、「チュートリアル : 再署名が不要で商標を保持する ClickOnce アプリケーションの手動配置」を参照してください。

実行時の信頼用のアプリケーション マニフェストの作用

アプリケーション マニフェストを信頼用に使用すると実行時にどのように作用するかをよく理解するために、次の例を考えてみます。 .NET Framework 3.5 をターゲットとする ClickOnce アプリケーションを Microsoft が作成するとします。 アプリケーション マニフェストは <useManifestForTrust> 要素を使用し、Microsoft によって署名されています。 Adventure Works は自己署名証明書を使用して配置マニフェストに署名します。 Adventure Works のクライアントは、Microsoft が署名したアプリケーションはどれも信頼するように構成されています。

ユーザーが配置マニフェストへのリンクをクリックすると、ClickOnce はユーザーのコンピューターにアプリケーションをインストールします。 クライアント コンピューター上の ClickOnce は、証明書と配置の情報からそのアプリケーションを一意に識別できます。 ユーザーが別の場所から同じアプリケーションを再びインストールしようとすると、ClickOnce は、この ID を使用することにより、そのアプリケーションが既にクライアント上に存在するかどうかを判断できます。

次に ClickOnce は、アプリケーション マニフェストの署名に使用された Authenticode 証明書を調べ、付与する信頼レベルを判断します。 Adventure Works のクライアントは Microsoft が署名したアプリケーションはどれも信頼するように構成されているので、この ClickOnce アプリケーションには完全信頼が付与されます。 詳細については、「信頼されたアプリケーションの配置の概要」を参照してください。

以前のバージョン向けの顧客配置の作成

以前のバージョンの .NET Framework を使用している顧客に開発者が ClickOnce アプリケーションを配置する場合はどうなるのでしょうか。 以下のセクションでは、推奨するいくつかの解決方法を、それぞれの利点と欠点を含めて要約します。

顧客に代わって配置に署名する

可能な配置方法の 1 つは、顧客に代わって開発者が顧客自身の秘密キーを使用して配置に署名する手段を構築することです。 この方法を使えば、開発者が秘密キーや複数の配置パッケージを管理する必要がなくなります。 開発者は、各顧客に同じ配置を提供するだけです。 顧客の環境に合うように署名サービスを使用してカスタマイズするかどうかは、顧客しだいです。

この方法の 1 つの欠点は、実装に要する時間と費用です。 こうしたサービスは .NET Framework SDK に用意されているツールを使用して構築できますが、製品ライフサイクルに占める開発時間が増加します。

このトピックで既に取り上げたように、アプリケーションの各顧客のバージョンが同じアプリケーション ID を持つので、競合を引き起こす可能性があるという別の欠点もあります。 これが心配であれば、開発者は配置マニフェストの生成時に使用する名前フィールドを変更して、アプリケーションごとに固有の名前を指定できます。 これによってアプリケーションのバージョンごとに別々の ID が作成されるので、ID が競合する可能性がなくなります。 このフィールドは、Mage.exe の場合は引数 -Name、MageUI.exe では [Name] タブの [Name] フィールドに相当します。

たとえば、開発者が Application1 という名前のアプリケーションを作成したとします。 名前フィールドを Application1 に設定して単一の配置を作成する代わりに、開発者はこの名前に Application1-CustomerA や Application1-CustomerB のように顧客固有のバリエーションを持たせて、複数の配置を作成できます。

セットアップ パッケージを使用して配置する

2 番目の可能な配置方法は、Microsoft セットアップ プロジェクトを生成して、ClickOnce アプリケーションの初期配置を実行することです。 これは、MSI 配置、セットアップ実行可能ファイル (.EXE)、キャビネット (.cab) ファイルとバッチ スクリプトの併用のいずれかの形式で実現できます。

この手法を使用する場合、開発者は、アプリケーション ファイル、アプリケーション マニフェスト、テンプレートの役割をする配置マニフェストを含む配置を顧客に提供することになります。 顧客がセットアップ プログラムを実行する場合、デジタル証明書だけでなく配置 URL (ユーザーがインストールする ClickOnce アプリケーションがあるサーバーまたはファイル共有の場所) についてもプロンプトが表示されます。 セットアップ アプリケーションでは、更新チェック間隔など追加の ClickOnce 構成オプションのためのプロンプトを表示するようにすることもできます。 セットアップ プログラムはこうした情報を収集すると、実際の配置マニフェストを生成し、それに署名し、指定されたサーバーの場所に ClickOnce アプリケーションを発行します。

この場合、顧客が配置マニフェストに署名するには、次の 3 つの方法があります。

  1. 顧客は、証明機関 (CA) が発行した有効な証明書を使用できます。

  2. 上記の方法のバリエーションとして、顧客は自己署名証明書を使用して配置マニフェストに署名することもできます。 この場合の欠点は、アプリケーションをインストールするかどうかをユーザーに確認するときに、"不明な発行元です" という言葉が表示されることです。 しかし小規模の顧客にとっては、証明機関が発行する証明書を入手するために必要な時間と費用をかけずに済むという利点があります。

  3. 最後に、開発者がセットアップ パッケージに自分の自己署名証明書を含めることができます。 この場合は、このトピックで既に述べたアプリケーション ID の問題が起こる可能性があります。

セットアップ配置プロジェクトの方法の欠点は、カスタム配置アプリケーションを構築するために要する時間と費用です。

顧客に配置マニフェストを生成してもらう

3 番目の可能な配置方法は、アプリケーション ファイルとアプリケーション マニフェストだけを顧客に渡すことです。 このシナリオでは、.NET Framework SDK を使用して配置マニフェストを生成して署名する作業は、顧客が担当することになります。

この方法の欠点は、顧客が .NET Framework SDK ツールをインストールする必要があること、およびそうしたツールを使用できるスキルを持った開発者またはシステム管理者を顧客が用意する必要があることです。 顧客によっては、顧客側の技術的労力をほとんどまたはまったく必要としない解決方法が求められる場合があります。

参照

処理手順

チュートリアル : ClickOnce アプリケーションを手動で配置する

チュートリアル : 再署名が不要で商標を保持する ClickOnce アプリケーションの手動配置

概念

再署名を行わない ClickOnce アプリケーションの配置 (テスト サーバーおよび運用サーバー)