Michael Sanford
Xambi Solutions, Inc.

January 2005
日本語版最終更新日 2005 年 3 月 15 日

概要: Michael Sanford 氏 が .NET Framework 2.0 の ClickOnce テクノロジを深く掘り下げ、既存の Windows インストーラ テクノロジと比較します。結びとして、それぞれのテクノロジの適用範囲について何点か提案します。

目次

はじめに
Windows インストーラの概要
製品、機能、およびコンポーネント
Windows インストーラの機能
ClickOnce の概要
主な相違点
使い分けの基準
Windows インストーラと ClickOnce の併用
まとめ

はじめに

新しい配置テクノロジである ClickOnce は、PDC 2004 で公開された最も画期的な機能の 1 つです。 強力な機能セットを備えた ClickOnce がアプリケーションの配置方式として普及するのは間違いありませんが、Windows インストーラはどうなるのでしょうか。 この記事では、ClickOnce の機能について詳しく説明し、その中で 2 つのテクノロジの主な違いを明らかにしていきます。 最後に、それぞれの配置テクノロジの適用範囲について何点か指針を示します。

Windows インストーラの概要

マイクロソフトが最初に Windows インストーラを導入したのは 1999 年のことです。きっかけとなったのは、アプリケーションの配置に伴う問題点についてユーザーから寄せられたフィードバックでした。 具体的には、既存のインストール テクノロジが抱えていた以下のような弱点について指摘がありました。

• COM コンポーネント、ActiveX コントロールなどの共有リソースを一貫して確実に管理する機能に欠けている (いわゆる "DLL Hell" の問題)。
• 標準のカスタマイズ機能を備えていない。
• インストールしたアプリケーションの修復やメンテナンスの手段が用意されていない。
• 必要に応じてアプリケーションを部分的にインストールするためのメカニズムを備えていない。
• インストール プログラムがオペレーティング システムと対話するための一貫したメカニズムを備えていない。

Windows インストーラは、Windows 2000 を始めとするすべてのオペレーティング システムに組み込まれているシステムレベルのコンポーネントです。従来のインストール テクノロジでは独自のスクリプトやファイル形式が使用されていたのに対し、Windows インストーラでは、アプリケーション、そのリソース、およびアプリケーションを正常にインストールするための処理が、データベースに似たオープンなファイル形式で記述されています。 テーブルと列の標準定義など、データベース形式の内部構造については、Platform SDK の「Windows Installer」セクションを参照してください。 最新バージョンの SDK は、http://www.microsoft.com/downloads/details.aspx?FamilyId=A55B6B43-E24F-4EA3-A93E-40C0EC4F68E5&displaylang;=en (英語) にあります。

Windows インストーラのパッケージは、"msi" という拡張子の付いたファイルに格納されています。 このファイル形式は OLE 構造化ストレージに基づく独自の実装ですが、msi ファイルの内容には Platform SDK 付属のツールで簡単にアクセスできます。 Platform SDK に用意されている主な msi 編集ツールは、"Orca" というコードネームで呼ばれています。 以下の図 1 に示すとおり、msi ファイルの論理構造はリレーショナル データベースの論理構造とよく似ています。

図 1. msi ファイルの内容を Orca で表示した状態

Platform SDK に用意されているツールのほかに、msi ファイルの作成や管理の負担を大幅に軽減するサードパーティ ツールもいくつかあります。 主なベンダーの一部を以下に示します。

• InstallShield (http://www.installshield.com )
• Wise (http://www.wise.com )
• Zero G (http://www.zerog.com )

製品、機能、およびコンポーネント

Windows インストーラのパッケージでは、製品、機能、およびコンポーネントの論理構造に基づいて、アプリケーションを複数の機能単位の集合体として扱います。 機能は、ユーザーがインストール プログラムと対話する際に使用する最下位のエンティティで、コンポーネントはインストール プログラムの開発者が扱う最下位のエンティティです。 たとえば、あるグラフィック アプリケーションが 2 つの機能で構成されているとします。1 つはアプリケーションの実行ファイル (.exe) をインストールする中核的なアプリケーション機能、もう 1 つはオプションのクリップアート集をインストールするクリップアート機能です。 この架空のアプリケーションをインストールするプログラムの中核機能は、2 つのコンポーネントから成ります。 1 つ目のコンポーネントは、アプリケーションの主な実行ファイルおよび正常起動に必要なレジストリ エントリのコンテナとして機能します。 中核機能の 2 つ目のコンポーネントには、共有 .dll と COM 登録情報 (COM サブシステムに認識させるためレジストリに記録する必要のある情報) が入ります。

Windows インストーラの機能

Windows インストーラは、カスタマイズと構成の機能を多数備えた複合的なテクノロジです。 この記事で Windows インストーラの機能を網羅することはできないため、ここでは重要度の高い機能の一部を簡単に紹介します。

• プログラマビリティ
  Windows インストーラには堅牢な API セットと完全なオートメーション インターフェイスが用意されており、オーサリング プロセスおよびインストールとメンテナンスのプロセスの両方で、アプリケーションと Windows インストーラの対話が可能になっています。
• カスタマイズ
  インストール パッケージの実行時の動作は、複数の異なる方法でカスタマイズできます。 たとえば、コマンド ラインで特定のオプションを設定できるようなインストール プログラムを開発したり、msi ファイルの内容をインストール時に実際に書き換えてインストール動作を変更する特殊な変換ファイルを作成したりすることができます。 Platform SDK と大多数のサードパーティ ツールのベンダーは、変換ファイルの作成をサポートしています。
• オンデマンド インストール
  Windows インストーラは、アドバタイズと呼ばれる概念をサポートしています。アドバタイズは、アプリケーションの個別部分 (またはアプリケーション全体) を、ユーザーが必要とする場合にのみインストールする機能です。 オペレーティング システムとの緊密な統合により、特定のアプリケーション (またはアプリケーションの特定機能) が必要になった場合に、その状況を検出できるようになっています。 たとえば、.foo ファイルの編集機能を備えたアプリケーションがインストールされた場合、Windows インストーラは該当するアプリケーションが確実にインストールされるようチェックし、ユーザーが Windows エクスプローラで .foo ファイルをダブルクリックしたときに、必要に応じてそのアプリケーションをインストールします。
• 回復機能
  Windows インストーラではアプリケーションや機能をオンデマンドでインストールできますが、それと同様に、ユーザーと対話しながらアプリケーションを修復することもできます。 たとえば、ユーザーがアプリケーションの実行を意図して [スタート] メニューのショートカットをクリックするか、関連付けられているファイルをダブルクリックした場合、Windows インストーラはその要求をインターセプトし、該当するアプリケーション要素が適切にインストールされているかどうかを確認することができます。 問題が検出された場合は、アプリケーションの実行前に修復が行われます。
• トランザクション インストール
  Windows インストーラの内部処理の多くは、インストール中に重大なエラーが発生してもシステムに悪影響が及ばないようにするためのものです。 Windows インストーラは、アプリケーションを適切にインストールするために必要な処理を正確に記述した内部的な "スクリプト" を作成することによって、これを実現しています。 インストール中に何か問題が発生した場合は、それまでに実行された処理をスクリプトによって実質的に取り消し、システムを元の状態に戻すことができます。
• ソース回復機能
  インストール済みのアプリケーションを修復する Windows インストーラの機能には、時として元のインストール ソースへのアクセスが必要になるという重要な側面があります。 たとえば、Windows インストーラで重要なファイルの欠落または破損が検出された場合は、そのファイルの正常なコピーを取得する必要があります。 ソース回復機能は、Windows インストーラで複数の場所を検索して元のインストール ソースを探し、どこにも見つからなければユーザーに対してメディアを要求するメッセージを表示するメカニズムです。 ソースの場所は、ローカル ファイル システムの場合もあれば、ネットワーク共有やインターネット URL の場合もあります。 Windows インストーラ 3.0 ではこれらの機能が強化され、管理者がソースの場所を楽に管理できるようになっています。
• アップグレードとパッチ
  通常、製品のライフサイクルは、アプリケーションが正常にインストールされた時点で終わりになるわけではありません。 それが理想ではありますが、現実には、修正や新機能を導入するために更新やパッチが必要になるアプリケーションが大多数を占めます。 Windows インストーラではバイト単位のパッチの作成と配布がサポートされ、より包括的な形でアプリケーションの更新プログラムを配布できるようになっています。 Windows インストーラ 3.0 では、パッチのシーケンス機能とアンインストール機能のサポートにより、パッチ機能の大幅な強化を実現しています。
• 管理環境のサポート
  大規模な企業環境では、ユーザーが不正なアプリケーションをインストールしてシステムの保全性を危険にさらすことのないよう、システムがロックダウンされているケースが少なくありません。 Windows インストーラのいくつかの機能を使用すると、この種のロックダウン環境でも、システム管理者の認可により特定の msi ベースのインストールを実行することができます。

ClickOnce の概要

ClickOnce は .NET Framework バージョン 2.0 に搭載されている最新の配置テクノロジであり、ロサンゼルスで開催された PDC 2004 にて初公開されました。 ClickOnce は、実行環境のセキュリティを確保しつつ、スマート クライアント アプリケーションの配置を Web アプリケーション並みに単純化することを主眼としています。 ClickOnce を使用すると、アプリケーション ファイルを Web サーバー、ファイル共有、またはローカル ファイル システムに置き、そのアプリケーション マニフェストへのリンクをユーザーに知らせるだけでアプリケーションを配置することができます。

Visual Studio 2005 で開発している場合は、発行ウィザードを利用することにより、ClickOnce 機能を備えたアプリケーションを難なく発行できます。 発行ウィザードには、ソリューション エクスプローラでプロジェクト名を右クリックし、コンテキスト メニューから [発行] を選択するだけでアクセスできます。 あるいは、[プロジェクトのプロパティ] ダイアログ ボックスの [発行] タブからアクセスすることもできます。

図 2. Visual Studio 2005 の発行ウィザード

ClickOnce による配置は、配置マニフェストとアプリケーション マニフェストという 2 種類の XML マニフェスト ファイルで制御されます。

配置マニフェスト

配置マニフェストは、アプリケーションの配置に関する記述に使用します。 アプリケーション マニフェストの場所、アプリケーション マニフェストに記述されているファイルの場所、およびクライアントで実行する必要のある最新リリースのバージョンを規定します。

<?xml version="1.0" encoding="utf-8" ?>
<asmv1:assembly xsi:schemaLocation="urn:schemas-microsoft-com:asm.v1
    assembly.adaptive.xsd" manifestVersion="1.0"
    xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns="urn:schemas-
    microsoft-com:asm.v2" xmlns:asmv1="urn:schemas-microsoft-
    com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"
    xmlns:xrml="urn:mpeg:mpeg21:2003:01-REL-R-NS"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<assemblyIdentity name="My Test App.application" version="1.0.0.20"
    publicKeyToken="7726c4d654f5bf83" language="neutral"
    processorArchitecture="msil" xmlns="urn:schemas-microsoft
    -com:asm.v1" />
<description asmv2:publisher="Xambi Solutions" asmv2:product="My Test
    App" asmv2:supportUrl="http://michael
    -dev2/WindowsApplication1/Support.htm" xmlns="urn:schemas
    -microsoft-com:asm.v1" />
<deployment install="true">
<subscription>
<update>
<expiration maximumAge="3" unit="days" />
</update>
</subscription>
<deploymentProvider
    codebase="http://michael_dev2/WindowsApplication1/My%20Test%20App
    .application" />
</deployment>
<dependency>
<dependentAssembly codebase="My Test App_1.0.0.20\My Test 
    App.exe.manifest" size="4908">
<assemblyIdentity name="My Test App.exe" version="1.0.0.20"
    publicKeyToken="7726c4d654f5bf83" language="neutral" 
    processorArchitecture="msil" />
<hash>
<dsig:Transforms>
<dsig:Transform Algorithm="urn:schemas-microsoft
    -com:HashTransforms.Identity" />
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>GANTD3FaR5KJiqnEluecM05wtss=</dsig:DigestValue>
</hash>
</dependentAssembly>
</dependency> 
<Signature Id="StrongNameSignature" 
    xmlns="http://www.w3.org/2000/09/xmldsig#" />
<!-- 簡潔にするため細部は省略しています -->
</asmv1:assembly>

アプリケーション マニフェスト

アプリケーション マニフェストは、アプリケーション、アセンブリ、ファイル、リソース、およびアプリケーションを正常に機能させるために必要な権限の記述に使用します。 また、更新プログラムの場所もアプリケーション マニフェストによって規定されます。

<?xml version="1.0" encoding="utf-8"?> <asmv1:assembly 
    manifestVersion="1.0" xsi:schemaLocation="urn:schemas-microsoft
    -com:asm.v1 assembly.adaptive.xsd"
    xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" xmlns="urn:schemas
    -microsoft-com:asm.v2" xmlns:asmv1="urn:schemas-microsoft
    -com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <asmv1:assemblyIdentity name="My Test App.exe" version="1.0.0.20"
    publicKeyToken="7726c4d654f5bf83" language="neutral"
    processorArchitecture="msil" type="win32" />
<asmv2:configuration configFile="My Test App.exe.config"
    xmlns="urn:schemas-microsoft-com:asm.v1" />
<entryPoint>
<assemblyIdentity name="My Test App" version="1.0.0.0"
    publicKeyToken="7726C4D654F5BF83" language="neutral"
    processorArchitecture="msil" />
<commandLine file="My Test App.exe" parameters="" />
</entryPoint>
<trustInfo>
<security>
<applicationRequestMinimum>
<PermissionSet class="System.Security.PermissionSet" version="1"
    ID="Custom">
<IPermission class="System.Security.Permissions.EnvironmentPermission,
    mscorlib, Version=2.0.3600.0, Culture=neutral,
    PublicKeyToken=b77a5c561934e089" version="1" Unrestricted="true" /> <IPermission class="System.Security.Permissions.FileDialogPermission,
    mscorlib, Version=2.0.3600.0, Culture=neutral,
    PublicKeyToken=b77a5c561934e089" version="1" Access="Open" /> <IPermission
    class="System.Security.Permissions.IsolatedStorageFilePermission,
    mscorlib, Version=2.0.3600.0, Culture=neutral,
    PublicKeyToken=b77a5c561934e089" version="1"
    Allowed="DomainIsolationByUser" UserQuota="10240" />
<IPermission class="System.Security.Permissions.SecurityPermission,
    mscorlib, Version=2.0.3600.0, Culture=neutral,
    PublicKeyToken=b77a5c561934e089" version="1" Flags="Execution" /> <IPermission class="System.Security.Permissions.UIPermission, mscorlib,
    Version=2.0.3600.0, Culture=neutral,
    PublicKeyToken=b77a5c561934e089" version="1"
    Window="SafeTopLevelWindows" Clipboard="OwnClipboard" /> <IPermission class="System.Windows.Forms.WebBrowserPermission, System,
    Version=2.0.3600.0, Culture=neutral,
    PublicKeyToken=b77a5c561934e089" version="1" Level="Restricted" /> <IPermission class="System.Drawing.Printing.PrintingPermission,
    System.Drawing, Version=2.0.3600.0, Culture=neutral,
    PublicKeyToken=b03f5f7f11d50a3a" version="1" Level="SafePrinting"/> </PermissionSet>
<defaultAssemblyRequest permissionSetReference="Custom" /> </applicationRequestMinimum>
</security>
</trustInfo>
<dependency>
<dependentAssembly codebase="My Test App.exe" size="12288"> <assemblyIdentity name="My Test App" version="1.0.0.0"
    publicKeyToken="7726C4D654F5BF83" language="neutral"
    processorArchitecture="msil" />
<hash>
<dsig:Transforms>
<dsig:Transform Algorithm="urn:schemas-microsoft
    -com:HashTransforms.Identity" />
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <dsig:DigestValue>xx4Nai4Nr7Bp5R7xtyqO8gAVsSk=</dsig:DigestValue> </hash>
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly preRequisite="true">
<assemblyIdentity name="Microsoft-Windows-CLRCoreComp"
    version="2.0.3600.0" />
</dependentAssembly>
</dependency>
<file name="My Test App.exe.config" size="1222">
<hash>
<dsig:Transforms>
<dsig:Transform Algorithm="urn:schemas-microsoft
    -com:HashTransforms.Identity" />
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<dsig:DigestValue>BdHEVcmEBWqRZGitWdDZ/vAGGmQ=</dsig:DigestValue> </hash>
</file>
<Signature Id="StrongNameSignature"
    xmlns="http://www.w3.org/2000/09/xmldsig#">
<!-- 簡潔にするため細部は省略しています -->
</Signature>
</asmv1:assembly> 

アプリケーション マニフェストと配置マニフェストの作成を終えたら、後は必要なアプリケーション ファイルと共に配置場所にコピーするだけです。 配置マニフェストは、必ずしもアプリケーション マニフェストと同じ場所に格納する必要はない点に注意してください。 たとえば、配置マニフェストは物理ディスクで提供される場合があります。配置マニフェストがアクティブになると、その配置マニフェストから ClickOnce エンジンにアプリケーション マニフェストの場所が伝達されます。 これは ClickOnce の重要な機能です。ユーザーが最初から最新バージョンのアプリケーションをインストールできるようになり、特定のバージョンをディスクからインストールした直後に更新が必要になるような事態を避けることができます。

ユーザーがアプリケーションを起動した時点で、ClickOnce により、配置マニフェストに記述されている設定に基づいてアプリケーションがインストールまたは更新されます。 権限の昇格が必要なアプリケーションの場合は、必要な権限を付与するよう求めるメッセージがユーザーに対して表示されます。

図 3. 必要な権限についてユーザーに問い合わせるメッセージ

このダイアログ ボックスの右下隅にある [詳細] リンクをクリックすると、次のような情報を示すダイアログ ボックスが表示されます。

図 4. セキュリティ警告に関する詳細情報

最終的にアプリケーションが稼動を開始すると、アプリケーションの配置元と、アプリケーション アイコンの上に重なる特殊なアイコンがタイトル バーに表示されます。 このアイコンにマウス ポインタを合わせると、アプリケーションがどのセキュリティ コンテキストで実行されているかを示す特殊なメッセージが表示されます。

図 5. セキュリティ環境に関する情報メッセージ

メモ   作成中の .NET アプリケーションがセキュリティ保護された環境で実行される可能性がある場合は、アプリケーションの安定性を保つため、そしてセキュリティ例外の発生時にユーザーが状況を把握できるようにするために、セキュリティ例外を明示的に処理することが非常に重要になります。

主な相違点

Windows インストーラと ClickOnce の両方の機能を簡単に紹介してきましたが、ここまでの説明で、それぞれのテクノロジの目指すところが大きく異なっていることがわかると思います。 この点をさらに明らかにするために、以下の表を用意しました。

前述したとおり、各テクノロジの設計と開発にあたって設定されていた一連の目標は、それぞれまったく異なるものでした。 どちらのテクノロジも、他方のテクノロジに取って代わるべきものではありません。 ClickOnce には非常に魅力的な機能が揃っており、その多くは Windows インストーラのテクノロジには見られないものです。 これらの機能は、複雑な構成要件のない .NET Framework ベースのスマート クライアント アプリケーションを作成する開発者にターゲットを絞っています。 Windows インストーラは、これよりはるかに幅広い配置テクノロジで、本質的に拡張性に優れ、.NET アプリケーションを含む各種アプリケーションの配置に関するどのような問題でも処理できる設計になっています。

使い分けの基準

配置テクノロジの選択にあたっては、1 つの選択肢のみにとらわれる必要はありません。 重要なのは、適切なツールを適切な場面で使用することです。 ルールは 1 つではなく、単純な答えもありません。ニーズに最適なツールを選択するための判断材料として、一般的なガイドラインをいくつか挙げておきます。

• COM コンポーネントをインストールするアプリケーションですか?
• COM 相互運用機能のコンポーネントの登録を必要とするアプリケーションですか?
• サービスをインストールするアプリケーションですか?
• 特定の場所またはグローバル アプリケーション キャッシュ (GAC) にインストールする必要のあるアプリケーションですか?
• オペレーティング システムや実行環境に基づいて条件付きでインストールされるアプリケーション コンポーネントがありますか?
• インストール時にユーザー入力が必要なアプリケーションですか?
• Active Directory や COM+ のようなシステムレベルのサービスの構成を必要とするアプリケーションですか?
• アプリケーションのインストール後に、ファイルの作成やレジストリへの書き込みなど、アプリケーションを削除してもシステムにリソースが残るような何らかの処理が実行されますか?

いずれかの質問の答えが Yes であれば、最新の Windows インストーラがニーズに最も適しています。 一方、上記のシナリオが当てはまらない場合は、ClickOnce が配置ソリューションの有力候補になります。 ClickOnce の際立った利点を活かすには、アプリケーション設計プロセスの早い段階で ClickOnce の機能を理解しておくことが非常に重要です。 アプリケーションの初期のバージョンを ClickOnce で配置した場合、後になって Windows インストーラへの移行の必要性に気付いても、アップグレードは容易ではありません。このような事態は、事前に綿密な計画を立てていれば避けられます。

Windows インストーラと ClickOnce の併用

そうです。 目を疑った方も多いと思いますが、書き間違いではありません。 ここまでは 2 つのテクノロジの実装がいかに異なるかを述べてきましたが、ここからは発想を転換して両テクノロジの併用のしかたを説明していきます。

Windows インストーラは、インストール中にユーザーと対話するための高度な機能を備えています。 多くの場合、ユーザーとの対話は配置プロセスの重要な手順と位置付けられます。 インストール プログラムには、ターゲット システムを調べてアプリケーションの最小要件を満たしているかどうかを確認する機能が不可欠です。 さらに、一般的なアプリケーションは動作環境となんらかの対話をするのが普通です。 この対話には、ログ ファイルをディスクに書き込む処理や、データをレジストリに保存する処理などが含まれます。行儀のよい (well-behaved) アプリケーションと呼ばれるためには、アプリケーションをシステムから削除する際に、このようなアプリケーション固有のデータを取り除く機会が必要になります。 これらはすべて、ClickOnce のパラダイムには見られない、配置の主要概念です。

その一方で、Windows インストーラには更新とパッチにまつわる話があり、スマートさと扱いやすさの点では ClickOnce に遠く及びません。

ほんの少しの思考、計画、創意工夫により、両方のテクノロジの利点を最大限に活かして配置モデルを作成することができます。

Windows インストーラ セットアップの設計

ここでの基本概念は、Windows インストーラ テクノロジに基づいて外部インストール プログラムを作成することです。 この外部インストール プログラムは、アプリケーションのインストール前にシステムの点検と調査をする役割を担います。 ユーザーと対話し、構成情報を収集して保存したり、共有アセンブリを GAC にインストールしたりする機能を持ちます。 アンインストール時には、通常はシステムに残りがちなアプリケーション リソースをクリーンアップする役割を担います。 たとえば、ファイルのアンインストール、実行時に作成されたログファイルの削除、サービスのアンインストール、GAC にインストールされたアセンブリの削除などを実行できます。

前述のとおり、ClickOnce アプリケーションは容易にインストール プログラムに取り込むことができます。 ClickOnce アプリケーションはインターネットやイントラネットの URL 経由で起動できるため、ターゲット システムにアプリケーション マニフェストへのショートカットを作成するだけで済みます。 ショートカットを作成するには、Windows インストーラを使用して、インストール時にその場で .url ファイルを作成します。 .url ファイルは特殊なタイプのショートカットで、標準の .ini ファイル形式に準拠しています。

[InternetShortcut]

URL=http://www.myserver.com/myapp/v1_0/myapp.application

Windows インストーラでこの INI ファイルを作成した場合は、IniFile テーブルに 1 行追加するだけで済みます。

この手法を綿密な設計に基づいて実装しようとすれば、アプリケーションに必要なタスクがインストール時に確実に実行されるよう、msi ファイルにさらに変更を加える必要があります。この記事で扱えるのはここまでですが、それぞれの配置テクノロジの利点を最大限に活かすことで得られる効果を、多少なりともつかんでいただけたのではないかと思います。

まとめ

機能上の制約のないアプリケーションにとって ClickOnce は非常に優れた配置テクノロジであり、ClickOnce を採用することによって価値ある利点が生まれ、かつては Web ベースのアプリケーション以外では実現できなかった更新モデルを使用できるようになります。 より複雑な要件が課せられているアプリケーションの場合は、Windows インストーラも依然として配置テクノロジの有力候補となります。 アプリケーションを確実にインストールするという目標はどちらの配置テクノロジも同じですが、似ているのはこの点だけです。 ClickOnce の機能が今後伸びていくのは間違いありませんが、同じくらいの確率で Windows インストーラも定着します。 当面は、創造力を働かせて両方のテクノロジを愛用するようにしてください。

Michael Sanford 氏は、Xambi Solutions (http://www.xambi.com ) の社長兼チーフ ソフトウェア アーキテクトです。 Xambi 創設以前は、ActiveInstall Corporation の社長兼 CEO を務めていました。ActiveInstall Corporation は後に Zero G Software に買収されましたが、同社が当時発表した Windows インストーラのオーサリング ソリューションは評判を呼びました。 Sanford 氏は、マイクロソフト公認ソリューション開発者 (MCSD)、マイクロソフト公認システム エンジニア (MCSE)、および Windows インストーラの MVP に認定されています。 氏のブログは http://msmvps.com/michael で公開されています。