Visual Basic 5.0で作成したアプリケーションを配布する
Visual Basic 5.0で作成したアプリケーションを配布する
Visual Basic 5.0では、ActiveXコントロール、ActiveXドキュメントなどを作成できるようになった。これは、インターネット/イントラネットでのWWWブラウザベースでのインストールが必要になったことを意味する。Visual Basic 5.0のセットアップウィザードでは、こうしたセットアップにも対応するようになっている。ここでは、その詳細について解説する。
酒井 法雄
DOSの時代には、アプリケーションを作成したら、ハードディスクにコピーして使えばよかった。仰々しいインストーラーが必要とされたのは、一部のコピープロテクトされたアプリケーションや、よほど大規模なものであり、それらは圧縮されたファイルを展開するというようなものだった。それとて、やっていることの基本はコピーにすぎなかった。
Windowsの時代になって、インストーラーは一般的になってきたが、やはり「コピーすること」が主たる内容であった。むしろ、インストールも専用プログラムでカッコ良くというのが主眼だったようにも思えた。
振り返ってみれば、Visual Basic 2.0のときには、セットアッププログラムはサンプルプログラムとして用意されており、それをベースにカスタマイズしなさいというものであった。しかし、その内容自体にバグが含まれており、コードは稚拙で、到底恥ずかしくてそのまま使えるようなシロモノではなかったのである。したがって、セットアッププログラムは、配布ファイルに応じてその都度コードを修正する必要があった。また、必要な配布ファイルが何であるかも細かく認識しておく必要があった。これは、とても面倒なものであった。 日本では発売されなかったVisual Basic 3.0では、この点は直されており、プロジェクトファイルを指定すると、半自動的にセットアップをしてくれるSetup Wizardが装備されていた。これは、Accessと同じデータベースエンジンを持つVisual Basic 3.0では、配布ファイルの識別を人間がやるのには無理が出てきたことを示すものであった。つまり、効率よいファイル配布のためのウィザードということである。とはいえ、基本的にはコピーすることが仕事だったことに変わりはない。
しかしここ数年、セットアッププログラムは、Windowsアプリケーションにとって必須項目となってきた。というのも、単なるファイルコピーだけでは済まなくなってしまったからである。
ところが、Visual Basic 4.0の頃から、事態は変わってきた。これは、Windows 95という32bit OSへの移行に伴った、アプリケーションインターフェイスデザインガイドの大幅な修正によるものである。ここでは、アプリケーションの配布には、セットアッププログラムを必須とし、なおかつ完全にアンインストールもできるようになっていなければならないことになっている。したがって、Visual Basic 4.0附属のセットアップウィザードも、これに準じた形で用意されていた。
このアンインストールは、単にファイルを削除するだけのことではない。レジストリの内容も書き換えるのである。 レジストリは、システム情報などをデータベースとして扱えるものである。従来のWIN.INIやSYSTEM.INIに代わるものとしてWindows 95から有名になったものであるが、実際には16bit Windowsでも用意されていた。その内容は、DDEやOLEのときに使われるものであった。たとえば、OLEのCreateObject関数では引数にActiveXサーバー(OLEサーバー)のクラス名を指定するが、この名前から実際にモノがあるパスやClass IDなどを特定するときに使われる。
Windows 95以降では、このOLEがシステムに深く関わるようになっており、Visual Basicで使われているライブラリ(DLL)も、従来は単なる関数をエクスポートした形のDLLだったのが、OLEベースのサーバー、すなわちActiveX DLLになった。VBXからOCXへ変化したのも、まったく同様にOLEベースへの移行と考えることができる。
したがって、DLLやOCXは単にコピーしただけでは動作しない。必ずレジストリへの登録が必要である。ならば、アンインストールするときにも、レジストリデータベースから削除しなくては整合性が取れなくなる。
したがって、ファイルの実体とレジストリの双方について、インストールとアンインストールが必要になるわけである。
図1のように、レジストリエディタでレジストリデータベースの内容を見ると、OLEのクラス名とその実体のあるパスなどが登録されていることがわかる
図1:レジストリデータベースの内容
ここまでは、Visual Basic 4.0でも同様の話だった。しかし、実際にはVisual Basic 4.0のセットアップウィザードの機能は十分なものではなかった。ファイルのタイムスタンプがセットアッププログラムを作った日時に変更されてしまうとか、一つのプロジェクトにしか対応しないといった問題があり、さらに進んだセットアップが必要なときには、Install Shieldなどのサードパーティ製ツールを使う必要があった。
Visual Basic 5.0になってからは、ActiveXコントロールやActiveXドキュメントが作成できるようになった。これらは、Webブラウザ内で動作するプログラムをインターネット/イントラネットで配布するというものであるから、従来のインストールプログラムとは大きく異なったインストーラーが必要になる。
また、Visual Basic 4.0 Enterprise Editionにモートオートメーションという名前で登場した分散オブジェクト環境を実現する仕組みは、Windows NT 4.0に至ってDCOMしてOSレベルに組み込まれることになった。このときには、ActiveXサーバーをどのマシンで実行するかといった指定も、インストール時にレジストリに書き込めた方がよい。
Visual Basic 5.0のセットアップウィザードは、ActiveXやDCOMといった新しい要求にも応えられるようになっている。また、ファイルのタイムスタンプ問題も解決している。
能書きはこれくらいにして、セットアッププログラムを使ってみよう。
Visual Basicフォルダー内にある「セットアップウィザード」を起動しよう。以下、画面ごとに説明をしていくことにする。ただし、ここではいろいろなプロジェクトやオプションを説明しているので、かなりの画面が出てくる。しかし、実際にはここまで多くの画面が出てくることはない。
ここでは、次の指定をする。(図2)
図2:プロジェクトとオプションの選択
このうち、オプションでは次の3つの指定がある。
もし、依存ファイルがないときには、図3のようなダイアログが出て、確認を求められることになる。
依存ファイルがないサードパーティのActiveXコントロールなどを再配布したいときには、セットアッププログラムは自動的に正確な情報を作ることはできない。手動で依存ファイルを書くか(これは正確な情報がないと難しい)、別途ActiveXコントロールの配布をしなくてはならない。
図3:不足している依存ファイル
ここでは、セットアップイメージのメディアを指定する。インターネットセットアップを選んだときには、この画面は出てこない。(図4)
これには、次の3つを選ぶことができる。
セットアッププログラムを作るディレクトリを指定する。セットアップオプションや配布方法によって画面は異なる。(図5-8)フロッピー以外のときには、デフォルトはテンポラリディレクトリ下のSWSETUPになる。この下にさらにプロジェクトの名前などをつけたディレクトリを指定するのが良いだろう。
図5:フロッピーディスク
|
図6:単一ディレクトリ
|
図7:複数ディレクトリ
|
図8:インターネットセットアップ
|
インターネットセットアップのときには、ランタイムライブラリの位置を指定する必要がある。(図9)デフォルトは、「Microsoft Webサイトからダウンロード」であり、この位置は依存ファイルなどから分かるように、「http://activex.microsoft.com/controls/vb5」の下である。 このライブラリのサイズは1Mバイト以上もあるので、イントラネットのときには、社内のWWWサーバーを指定するべきだろう。
図9 :インターネットパッケージ
また、このパッケージについての安全性の保持を指定することができる。安全性ボタンを押すと、ActiveXコンポーネントごとに、次の指定をすることができる。(図10)
図10:「安全性」を確認するダイアログ
初期化の安全性保持は、ActiveXコンポーネントがインスタンシングされたときに、 システムに悪影響を与えることはないという宣言である。
スクリプト化の安全性保持とは、ActiveXコントロールなどをスクリプトで制御したときに、 システムに悪影響を与えないという宣言である。
これらの悪影響とは、一般的には「ローカルファイルへのアクセス」、「レジストリの操作」といったことを意味するとMicrosoftは説明している。しかし、そういったことをしなければ、役に立たないActiveXコントロールもありえる。これは、悪意がないものであるというように解釈した方が分かりやすいかもしれない。
ここで注意すべきなのは、これをチェックすれば、Javaのようにサンドボックス内で安全に動作してくれるというようなものではなく、単に配布者が安全性を保証する宣言をしたに過ぎないということだ。虚偽の安全性を保証されたらどうにもならない。安全性があるとしてチェックしたにしても、受け取る側にとっては、泥棒ですと言って入ってくる泥棒などいないに決まっているわけで、安全性はないに等しいということだ。やはりインターネットでのセキュリティは保てないと考えるべきだ。
では、このチェックをしておかないとどうなるかと言えば、ActiveXコンポーネントダウンロード時に出てくる例のダイアログが一つ余計に出てきて、「初期化やスクリプト化の安全性は保証されていないけど、本当に動かすのか」といったことを聞いてくるというだけだ。これはイントラネットで使うときにはうっとうしいだけだから、気にせずチェックして使うことになるだろう。
データアクセスをするプログラムのときには、ISAMの指定やワークスペースの指定をする。図11にもあるように、ODBCのモジュールは別にセットアップディスクで配布する必要がある。この点は注意が必要だ。
図11:データアクセスの設定
セットアップウィザードは、先に依存ファイルの確認が出たように、ActiveXコンポーネントを使っているときには、自動的に検出する。しかし、CreateObjectなどを使っているときには、これが検出できないことがあるようだ。 このときには、ローカルおよびリモートごとに必要なコンポーネントを指定する。(図12)
図12:ActiveXコンポーネントの指定
DCOMやリモートオートメーションなど、リモートコンポーネントを使っているときには、「リモートコンポーネントの追加」を選び、.VBRファイルとリモートマシンの位置を指定する。
.VBRファイルを作るには、ActiveXサーバーなどを作成するときに、プロジェクトのプロパティ、「コンポーネント」タグで「リモートサーバーファイル」をチェックしておく。(図13)このファイルの中には、リモートマシンに設定すべき情報が格納されている。
図13:.VBRファイルを作るには「リモートサーバーファイル」をチェックしておく
.VBRファイルを選んだときには、図14のようなダイアログが出てきて、DCOMかリモートオートメーションかを選ぶことができる。
DCOMのときには、接続情報にネットワークアドレスを指定することができる。ここには、サーバーコンポーネントのあるマシン名あるいはIPアドレスなどを指定する。
図14:リモート接続の設定
リモートオートメーションのときには、ネットワークプロトコルや認証レベルも設定する必要がある。DCOMでは、プロトコルはDCOMのシステム内で判断されるので必要ない。認証レベルなどについては、ACLに連動したDCOMの設定ユーティリティーで設定した値が有効になる。これには、Windows NT 4.0附属のDCOMCNFG.EXE(図15)あるいはVisual Basic附属のリモート接続マネージャ(図16)がある。
実際には、このリモート接続の指定ができるコンテナは、標準EXEプロジェクトのみのようだ。ActiveXコントロールやActiveXドキュメントからリモート指定をしても、正常に動作しなかった(NT SP2時。SP3では調査していない)。
図15分散COMのプロパティ
図16:リモートオートメーション接続マネージャ
・依存情報の確認。
アプリケーションに依存するファイル一覧がリストされる。実際に必要ないものであれば、チェックを外して配布しないようにすることができる。(図17)
ファイルの詳細ボタンで、各ファイルのバージョンなどを確認することができる。(図18)
図17:依存情報の確認
図18:ファイルの詳細
以上で、セットアップに必要なファイルのリスティングは終了して、セットアップウィザードは指定されたファイルをあらためて検索して詳細を調べる。
ここでは、「プロパティページDLLを含むか?」といったメッセージボックスが出てくることがある。これは、ActiveXコントロール用のプロパティページを表示するためのDLLを同時に配布するかの確認である。インターネットセットアップのときには、どうせプロパティページなど使えないのだから、デフォルトの「いいえ」を選べばよい。ふつうのセットアップのときには、配布した方がよいだろう。
また、ライセンスキーファイル.VBLを作成してあったときには、ライセンスファイルを同時に配布するかどうかを聞いてくる。(図19)
図19:ライセンス情報登録の確認
ライセンスファイルとは、ActiveXコントロールプロジェクトのとき、そのコントロールをデザイン時に使うためのライセンスファイルのことである。
多くの人にタダで使って欲しいものならば、最初からライセンスファイルを作る必要はない。ライセンスファイルがないときには、このメッセージボックスは出てこない。
デザインはできないようにする、またはデザインには有料で配布するなどのとき、サンプルとして配布するものの中で実行時のみ使用可能にしたいなら、ライセンスファイルは提供しないようにする。
ライセンスファイルを作るには、プロジェクトのプロパティを選び、「全般」タブから「ライセンスキーを要求する」をチェックする。(図20)こうしておけば、.OCXファイル作成時に、.VBLの拡張子を持つライセンスファイルも同時に作成される。
図20:ライセンスファイルを作成する設定
ファイルサマリーが出るので、必要なファイルがあれば追加する。ActiveXコントロールやActiveXドキュメントならば、通常は必要ないだろう。そうでないセットアップのときには、ReadMe.Txtなどを追加することができる。
図21:ファイルサマリー
ファイルの詳細ボタンを押すと、図22のようなダイアログが出てくる。ファイルによっては、コピー先のディレクトリなどを変更することができる。
図22:ファイルの詳細ダイアログでは、コピー先ディレクトリ、共有ファイル、ライセンス情報などを変更できる。
サマリー詳細ボタンを押すと、配布ファイルの総数や圧縮前後の各ファイルサイズなどを知ることができる。
図23:ファイルサマリー
これで、すべての設定は終了である。(図24)
図24:完了！
「テンプレートの保存」ボタンを押せば、.SWTの拡張子を持つテンプレートファイルを作成できるので、次に同じセットアッププログラムを作るときのデフォルト値を保存しておくことができる。
完了を押せば、指定した設定を元にしたセットアッププログラムが作成される。
こうして作られたインターネットセットアップ以外のセットアップイメージのサイズは、かなり大きなものである。最小でもフロッピーディスク1枚には入りきらない。これは、セットアッププログラム自体の実行に必要になるファイルのサイズが大きいことと、実行時に必要になるDLLなどのライブラリが増えており、サイズも増加しているからである。
仮にフロッピーで配布したいときにも、一度ハードディスク上にイメージを作ってからフロッピーにコピーした方がよさそうだ。
ActiveXコントロールやActiveXドキュメントのインターネットセットアップを作ったときには、.CABの拡張子を持つキャビネットファイルがセットアップされるファイルがまとめられる。しかし、これを直接そのままダウンロードできるわけではない。HTMLファイルも同時に作られ、このファイルをIEで読み込んだときにに、セットアップも自動的に開始されることになる。
ActiveXコントロールのときには、次のようなHTMLファイルが作られる。内容としては、前半部が後述するライセンスパッケージについての指定、後半がActiveXコントロール自体の情報である。
実際にActiveXコントロールを使ったページを作るためには、このファイルを元にして、さらにHTMLを書き足したり、VBScriptを使って制御するコードを記述する必要がある。
ActiveXドキュメントのときには、拡張子が.VBDのActiveXドキュメントを読み込むためのファイルが作成され、さらに.VBDファイルを指定したHTMLファイルが作成される。内容を見ると、FRAMEを使って.VBDファイルを指定していることが分かる。
ActiveXドキュメントは、そのまま使ってもかまわないが、FRAMEをうまく活かした使い方をしたいならば、HTMLを適切に書き直す必要があるだろう。
ActiveXコントロールを含むEXEや、ActiveXコントロールを含むActiveXコントロールを作ったときには、ライセンスに注意しなくてはならない。
サードパーティのコントロールの中には、再配布する権利に制限があるものもある。また、Visual Basic附属のコントロールであっても、3D系コントロール(標準ではインストールされなくなった)などには、再配布する権利はない。ドキュメントを良く読み、再配布ができるものであるかを、あらかじめ確認しておく必要がある。
また、再配布ができるものであっても、あくまでもそのActiveXコントロールを使ったアプリケーションの配布時に、実行モジュールとして再配布が認められているだけのものが多い。つまり、デザイン時には利用できないというものだ。
しかし、こうしたActiveXコントロールを使った独自のActiveXコントロールを作ることも可能ではある。となると、たとえば市販の高機能グリッドActiveXコントロールを貼り付けて、ちょっと色を変えたActiveXコントロールを作ることもできるわけだ。もちろん、道義的に考えてこれを売り物にすることはないだろうが、やろうと思えばできないことはない。もちろん、このようなことは、最近のActiveXコントロールでは許諾条件の中で禁止されていることが多い。こういったコントロールのライセンスキーなどを配布することも通常は禁止されているから、もしデザイン時に使えるようにライセンスキーも配布したとすれば、これはマズいことになるだろう。
十分に、再配布条件などのドキュメントを読んでおいた方がよい。
しかし、ふつうに考えて、こういったActiveXコントロールの階層化はメモリや実行効率が良いとは思えない。ActiveXコントロールを作るときには、その中で既存のActiveXコントロールは使わない方がよいだろう。
先ほども見たように、セットアップファイルと同時に作られるHTMLファイルの前半部には、ライセンスパックのためのものである。 ライセンスパックとは、そのHTMLページ以外でActiveXコントロールを使えなくするための仕組みである。
これを利用するには、ActiveX SDKやVB5.0 CD-ROMに含まれているLPK_TOOL.EXEを使う(図25)。このアプリケーションを実行して、コントロールを選ぶと、.LPKという拡張子のライセンスパックファイルを作成することができる。
図25:ライセンスパック
これは、リスト4のように暗号化されたファイルである。先ほどのHTMLのVALUEの部分を、ライセンスパッケージのファイル名に書き換える。
| <PARAM NAME="LPKPath" VALUE="LPKfilename.LPK"> |
そして、ライセンスパッケージファイルをHTMLと同じパスに置いておけば、他のページで使うことはできないというわけだ。
リスト4:ライセンスパックファイルの例 LPKファイルには著作権について云々と書いてあるものの、著作権表示はない。だいたいが、ActiveXコントロールにだって著作権表示は書けるわけで、いずれにしてもコピーされてしまえば元も子もない。つまり、意味のないライセンスの仕組みである。何もしないよりはマシという程度のものだ。
しかも、実際に使ってみると、このメカニズムはどうしたことがうまく動かないことがある。よくよく調べてみると、一度レジストリに書き込まれたものは、次から無条件に実行されるパターンがあるようだ。これは、ActiveXコントロールをダウンロードするときのIEの設定でも、一度セキュリティを「高」にして実行しないと、次に「中」にしても実行されないときがあるのに似ている。どうも、IEのこのへんの仕組みはうまく動いていないようだ。
ActiveXコントロールなどには、デジタル署名をすることができる。これは、直接はセットアップウィザードには関係ないことだ。しかし、ファイルの配布には重要な問題のように思える。
デジタル署名は、CABファイルに埋め込まれたデジタル署名を元にして、インターネット上にある認証サーバーに接続して、認証を確認するというものである。確認できたときには、例の賞状みたいなダイアログが出てきて、安全性を示すということになっている。
しかし、デジタル署名は出所証明にすぎない。つまり、どこの会社が作ったものだということを証明するだけであり、故意でなくてもシステムをクラッシュさせるようなActiveXコントロールがデジタル署名されることも可能である。日本であれば、日本ベリサインに金さえ払えば、この出所証明は取得できるのである。
実際にデジタル署名をするには、 日本ベリサインからサインを購入し、ActiveX SDKなどに含まれるSIGNCODE.EXEを使って、CABファイルに埋め込むことになる。(図26)
CHKTRUST.EXEを使えば、認証がうまくいくかを確認することができる。(図27)
図26:デジタル署名の埋め込みが可能
図27:デジタル署名の確認を行うchktrust
もっとも、私はActiveXコントロールやActiveXドキュメントは、イントラネット用の技術だと思っているから、こんなことには興味がないので、デジタル署名も取得していないし、使ったこともない。
もちろん、イントラネットではこんなことをしなくても、セキュリティを「なし」にしておけばよいだけの話である。
セットアップウィザードについて、そしてインターネットセットアップやActiveXコントロールなどのコンポーネント化のセットアップについて解説してきた。
印象としては、タイムスタンプが保存されるように改善されたという点と、インターネット用(イントラネット用と言いたいが)のセットアップがカンタンにできるという点は、非常によいと感じた。
しかし、次のような問題も残っている。
ファイルをネットワークを参照するとき、「\\SERVER\VBPROJECTS」といったUNC名がサポートされていない。したがって、あらかじめドライブにマップしておく必要がある。
構造上、ActiveXコントロールプロジェクトに依存ファイルがないとき、必要なコンポーネントが配布できない。したがって、サードパーティのコントロールなどを配布するときに、前述したような問題が生じる。サードパーティが依存ファイルを提供してくれていないときには、スマートに解決することは難しいだろう。
通常のセットアッププログラムを作るときには、相変わらず一つのプロジェクトにしか対応していない。したがって、複数のEXEなどを配布しようというときには、Visual Basic 2.0の頃のように自分でカスタマイズする必要がある。
このように、セットアップウィザードは、オマケながらもまずまず実用的なものだと考えることはできるが、大規模なシステムの配布には問題が生じやすい。すでに、InstallShieldなどのサードパーティ製のインストーラー作成プログラムもあるが、こういったものは今後増えていきそうだ。用途によっては、それらの中から適切に選ぶことも必要になるだろう。
こういうコトを書くと、標準的なものだけで開発したいとおっしゃる方も多いようだ。しかし、Visual Basic附属のActiveXコントロールにしても、このセットアップウィザードにしても、しょせんはオマケであり、標準ではないのだ。バグへの対処やサポートも心もとない。たとえば、DBGridの本物は文化オリエントから売っているものであって、これが本当は標準と考えるべきである。このへんを勘違いすると、大変なことになる。気をつけていただきたい。
