また、日常業務でアプリケーションを利用していると、操作ミスも含めてさまざまな要因でファイルが壊れてしまったり、いわゆる書き変わりが起こってしまう。これはWindows 2000の環境では考えにくいのですが、こうしたことが原因となって、アプリケーションがうまく動かなくなってしまったといった時に、「自己修復機能」が働くようなアプリケーションを書くことができます。ただしこの機能を利用するためには、アプリケーション側にも「Windows Installer」のAPIまたは、COMのインターフェイスを使って、ある種の処理を記述しておかなければなりません。
「Windows Installer」は、「安定性」「保守性」、そして、大きく捉えれば「TCOの削減」をもたらすためのテクノロジーであり、とても重要なものと考えています。
Office 2000にはこの機能を実装していますが、「Windows Installer」自体は、OS側のモジュールの1つなのです。UIと「Windows Installer」とは、2段階に分かれているといえます。「Windows Installer」は、言ってみればエンジンだけです。そして、その上で動かすインストールパッケージを、今回の「Visual Studio Installer」や、サードパーティ製のインストーラプログラムを使って作るわけです。そのためUIは、そのインストールパッケージの内容に依存します。つまり、エンジンの部分だけを「Windows Installer」と呼んでいて、その上に載るインストールパッケージを作るのが「Visual Studio Installer」などのインストーラ作成プログラムというわけです。そしてセットアップオーサリングツールは、インストールパッケージとなる「MSIデータベース」を作成し、その中にはリレーション構造を持った複数のテーブルが組み込まれます。そのテーブルの内容によって、データドリブンでセットアップが進んでいくという仕組みです(Figure 1)。
「Windows Installer」の優れた点をいくつか説明しましょう。たとえば、「Advertised」という状態でセットアップすることが可能です。セットアップといったら、通常は「インストール＝ローカルのハードディスクに入れる」ことですし、アンインストールは、取り除くことを示します。または、CD_ROMやネットワーク上から使うといった選択肢もあるかもしれません。そして、もう1つ第4の状態として、「Advertised」状態というものが用意されています。これは「使えるけども、実体はまだ存在しない」という状態です。たとえば、ショートカットなど、ありはするけれど、使おうとするとそのリクエストはMSI Serverへ渡され、必要なコンポーネントを自動的にインストールし、スタートするといったことができるわけです。
Office 2000は、厳密にいうとこの「Advertised」機能を使っています。これが非常に効果的なシチュエーションがあります。たとえば大量のCOMコンポーネントとそれに関連するデータを作ったとしましょう。実際にこれらの大量のCOMコンポーネントとデータのすべてを使うかどうか分からないけれども、とりあえず「Advertised」で入れておけば、ユーザーが使う時にのみ、初めてインストールされる。こうして、ディスクスペースを無駄にすることもなく、インストールの時間も手順も短くなるといった意味で、かなり有効な手段の1つです。
Office 2000の時にアピールしていた「TCO削減」ということのいくつかは「Windows Installer」の機能です。たとえば「自動修復」メニューがOffice 2000の中にありますが、あれも「Windows Installer」の機能の1つです。ですから、アプリケーションの方にそのメニューを組み込んでおいてパッケージングすることによって、Office 2000のようなことを、自分のアプリケーションでもできるようになるわけです。
でも「Advertised」の状態で、たとえばノートパソコンを持って出張に出掛けてしまうようなケースでは、困ったことになる。実際に使おうとしたときに出先ではインストールしたい実体がないからです。そういう場合には、コンポーネントのインストールされている状況を問い合わせて、必要に応じて、必要なインストールして出掛ける。そして出張から戻って来たら、元の状態に戻してしまうといったこともできる。
そのときにユーザーが、どういうインストール状態であるのか、たとえばExcelは入れてあるけれども、Wordは入れていない、AccessはAdvertisedしてるけども、ほかのものはどうか、というような状態があると思います。その状態を保存しておいて、出かける前に全部インストールしておいて、戻って来たら元の状態のとおりに、またアプリケーションを設定し直すということができる。必要なときに必要なもののみを、インストールしたり、アンインストールできます。
また、たとえば使用頻度が少ないものを入れておいても仕方がない場合も考えられる。日常的に利用していれば、使われるアプリケーションや機能は、だんだん固まってくる。使わないアプリケーションや機能は、定期的に「Advertised」化しておけば、ディスクから自動的に不要な領域を取り除いて、データ領域を解放しておくことができるというわけです。
いずれもこれらは、ソリューションの1つであって、「コードを書けば」ということが前提になりますが、書くコードのボリュームというのは、APIを2～3つ、またはCOMのメソッドやプロパティも2～3つ呼び出すことで可能です。たとえば「自動修復」のケースでいえば、「MSIInstallProducts」というAPIを1つ呼び出すだけで大丈夫です。MSIで始まるAPIが、全部MSIに関連したものになりますから、開発者の方にはとりあえずザックリと眺めていただいて、何ができるのだろうかということを把握していただけると嬉しいです。
使うユーザー側は、トラブルが起こっても自己回復できますし、管理者側はそれにかかるTCOを削減できます。さらにアプリケーションのライフサイクル、配布、管理、補修、最後に削除というような、一連の流れの中のどこでも「Windows Installer」を使うことで対応できると思います。
