.NETコンポーネントをVB6から使用するための方法
著者: 株式会社アイジュピタ  新出 純壱( shinde@sev.or.jp )
日時: 2003年6月27日  (2003年10月6日 更新)


0. このドキュメントについて

 この資料では、Visual Basic 6.0から.NETで作成したクラスをCOMとして利用する為の方法について説明する。.NET側の言語はC#を用いるが、他の言語にも応用可能である。
 同様の情報が「.NET COM 相互運用」のようなキーワードでネットやヘルプ等の様々な場所に点在しているが、VBから.NETを利用するという観点で通して説明した資料が見つからなかった為、自分なりの解釈でそれらをまとめたものである。

 解釈が間違えている箇所もあると思われるので、お気づきの点は shinde@sev.or.jp までご連絡頂ければ幸いである。内容については各自の責任で利用されたい。

目次
1. 最も簡単にVB6から.NETコンポーネントを利用する方法
2. VB6上で実行できるようにする
3. DLLの共有方法
 3.1 会社固有のキー・ペアを作成する
 3.2 DLLに遅延署名する
 3.3 グローバルアセンブリキャッシュ(GAC)に登録する
 3.4 VB6から利用できるようにする
 3.5 署名を行う
4. その他の問題を解決する
 4.1 最新のタイプライブラリを使ってコンパイルすると、実行時エラー429が発生する
 4.2 VB6のコード補完が使えない
 4.3 イベントをVB6から利用できない
5. 参考文献



1. 最も簡単にVB6から.NETコンポーネントを利用する方法

(1) .NETのDLLを作成する。

 まず、VB6から利用したい.NETのクラスをコンパイルし、DLLにする。
 DLLにするにはプロジェクトの新規作成時に「クラス ライブラリ」を選択すれば良い。

例) DotNetCOMTest.dll
DotNetCOMTestClass
 void TestA() - メッセージボックスを表示する。

 このDLLはVB6.exeと同じディレクトリに置いておく。

(2) COMとして利用できるように、レジストリに登録する。

 VB6から利用する為に、.NETのDLLをCOMとして利用できるようにレジストリに登録する。
 これをやってくれるのがregasmコマンドである。

% regasm DotNetCOMTest.dll
※regasm.exeは、.NET Framework ランタイムに含まれる("WINNT\Microsoft.NET\Framework"以下の各バージョンのフォルダに存在する)。

(3) tlbexp コマンドで、タイプライブラリ(*.tlb)を作成する。

 VB6の統合開発環境から利用する為にはタイプライブラリというクラスの型情報を持つファイルが必要である。
 これを生成するのがtlbexpコマンドである。

% tlbexp DotNetCOMTest.dll /out:DotNetCOMTest.tlb
※tlbexp.exeは、.NET Framework SDKに含まれる(\Program Files\Microsoft.Net\ FrameworkSDK\Bin か、VS.NETインストールフォルダ内の同場所に含まれる)。

 この結果、同じディレクトリにDotNetCOMTest.tlb が作成される。  

(4) VB6のプロジェクトから参照設定する。

 VB6の「参照設定」からDotNetCOMTest.tlb を読み込む。
 これでVBの統合開発環境上で各クラスを呼び出す準備が整った事になる。

(5) VB6から.Netクラスを生成し、呼び出す。

 VB6のフォームにボタンを貼り付け、ボタンのClickイベントに次のようなコード を書く。
 尚、クラス名以外のコード補完機能は働かない為注意が必要だ(コード補完機能を使えるようにするには4.を参照)。

VBソースコード(Form1)

Private Sub Command1_Click()
    On Error GoTo Err_Proc
    Dim obj As DotNetCOMTest.DotNetCOMTestClass ' (a)
    Set obj = New DotNetCOMTest.DotNetCOMTestClass ' (b)
    Call obj.TestA ' (c)
    Exit Sub

Err_Proc:
    MsgBox Err.Description
End Sub

(a) DotNetCOMTestパッケージの、DotNetCOMTestClassの変数objを宣言する。
(b) DotNetCOMTestClassを生成し、objに代入する。
(c) objのTestAメソッドを呼び出す。


(6) プロジェクトをコンパイルし、exeを作成する。

 exeを実行してボタンをクリックするとTestAが呼び出される事を確認する。
 尚、VB6上から直接実行すると、クラスが見つからない旨のエラーになる。
 VB6上から実行できるようにするには2.または3.を行う必要がある。

 


2. VB6上で実行できるようにする

 VB6上から直接実行するとエラーになるのは、VB6から実行する際にはカレントフォルダがVB6.exeのフォルダになっており、DLLをVB6が見つけられない為である。

 対策は、DLL(ここではDotNetCOMTest.dll)をvb6.exeと同じフォルダにコピーするだけでよい。
 ※DotNetCOMTest.dllが参照している他のDLLがあればそれもコピーする。

 このやり方でも特に問題はないが、このDLLが他のアプリケーションからも使われる「共有DLL」である場合は3.の対処を行う必要がある。3.の対処を行う場合は2.の対処は不要である。

コラム:共有DLLは必要か?

 「3.DLLの共有方法」で説明しているDLLの共有方法は、昔ながらのCOMの共有方法に近い。

 しかし、本来.NETの思想ではDLLはそれぞれのアプリケーションにローカルにすべきであり、共有を避けることによって「DLL地獄」に陥らないようにしたり、「XCOPYインストール」を実現したりするのが本筋であろう。

 「3.DLLの共有方法」で確かに共有は実現されるが、代償としてそのアプリケーションのインストール時にGACにアクセスしなければならなくなる。GACにアクセスするためのツールであるgacutil.exeは.NET SDKをインストールしなければ存在しない為、VBアプリケーションの配布が非常に面倒になる。

 では一般に.NET DLLを利用するVBアプリケーションを配布するにはどうすればいいのかというと、このドキュメントの1.と2.で説明した通り、配布したいVB用アプリケーションのexeと同じフォルダに.NET DLLを配置してregasm.exeを実行すればいいだけである。regasm.exeは.NETランタイムをインストールすれば一緒にインストールされる。

 複数のアプリケーションから共有したい場合は、それぞれのアプリケーションフォルダにDLLをコピーすれば良い。一箇所にDLLをまとめたいのであれば、そのVBアプリケーション用の「アプリケーション構成ファイル」を作成してcodebase属性でDLLの位置を指定すれば良い。

 「3.DLLの共有方法」は、最後の手段と考えておくべきである。

※参考:<codebase>属性
http://www.microsoft.com/japan/msdn/library/default.asp?
url=/japan/msdn/library/ja/cpgenref/html/gngrfcodebase.asp


※アプリケーション構成ファイルについて
 ちなみに、アプリケーション構成ファイルは「exe名.config」という名前で作成すればOKだが、これは.NETアセンブリを利用するVBアプリケーションにもそのまま当てはまる。
 つまり、「MyVBApp.exe」というVBアプリなら、「MyVBApp.exe.config」という名前で作成すれば良い。codebase属性などについては上記URLを参照のこと。

※DLLの配布の際は、4.1の問題点についても対処しておくこと。



3. DLLの共有方法

 COMの場合、system32フォルダに置いてregsvr32を実行することでDLLを共有できた。
 .NETにも共有の仕組みが用意されている。
 DLLを共有化すると、どのアプリケーションからでもそのDLLを利用することができる。但し、どうしても共有しなければならない理由がない限り、DLLは各アプリケーションにローカルにしておいた方が良い。

 共有化するためにはグローバルアセンブリキャッシュ(GAC)にDLLを登録すれば良い。
 しかし、GACに登録する為にはDLLに対して先に「署名」を行うことにより厳密名をつける必要がある。
 署名を行う為には「キー・ペア」と呼ばれるものが必要になる。

 ここでは開発時のキー・ペアの運用を考慮して、遅延署名と呼ばれるテクニックを用いた手順を詳しく解説する。
 この方法はDLLに対して厳密名を付ける方法としても参考にして良い。

 尚、既にDLLが完成していて後は共有するだけ、という場合は以下の項目だけを実行すれば良い。
 3.1(1) キー・ペアを作成する。
 3.2(2) 公開キーを使って遅延署名する。
   (※3.1(1)のキー・ペアを使って正式署名をすれば良い)
 3.3(2) GACに登録する。
 3.4(1) system32フォルダにDLLをコピーする。

3.1 会社固有のキー・ペアを作成する。

(1) キー・ペアを作成する。

% sn.exe -k companyname.snk
※sn.exeは、.NET Framework SDKに含まれる(\Program Files\Microsoft.Net\ FrameworkSDK\Bin に含まれる)。

 この結果、カレントフォルダにcompanyname.snkが作成される。
 このキー・ペアは他に漏れないよう厳重に保管する必要がある。
 また、このキー・ペアは会社固有のキー・ペアとして全てのDLLに対しての署名用に用いる。

3.2 DLLに遅延署名する。

 キー・ペアは非常に機密性の高いファイルである為、DLLをコンパイルする度にこのファイルを持ち出していたのでは機密性を保持するのは大変である。
 これを回避する為に「遅延署名」というテクニックが用意されている。これはキー・ペアから「公開キー」のみを取り出し、これを使って擬似的に署名を行うものである。
  ちゃんとした署名は開発の終了時に行う。

(1) キー・ペアから公開キーを取り出す。

% sn.exe -p companyname.snk companyname_public.snk

 この結果、companyname_public.snkが作成される。このキーは公開用のキーなので誰に配っても良い。
 この後、この公開キーを使ってDLLに「遅延署名」を行う。

コラム: 「キー・ペア」とは何か?

 「キー・ペア」とは暗号化方式の一つである「公開鍵暗号化方式」の用語である。
 よく知られる「秘密鍵暗号化方式」では一つの暗号化キーを使って暗号化と復号を行うが、公開鍵暗号化方式では「個人鍵」と「公開鍵」という二つの暗号化キーのペアを用いる。
 これがキー・ペアと呼ばれる由縁である。

 個人鍵を使って暗号化された文書は、対となる公開鍵でしか復号できない。また、公開鍵を使って暗号化された文書は対となる個人鍵でなければ復号できない。

 例えばA氏が自分の個人鍵を使って暗号化した文書は、A氏が公開している公開鍵を使ってしか復号できない為、その文書がA氏のものだという証拠となる(もちろん個人鍵は厳重に管理されているという前提がある)。
 逆にA氏に秘密の文書を送りたい場合は、送信者がA氏の公開鍵を使って暗号化し、A氏に送れば良い。A氏は自分の個人鍵を使って復号することができるが、他の人がもしこの文書を入手しても復号することはできないのである。

 これを署名検証に応用する場合、目的は「対象のアセンブリが正式に署名されたものかを確認する」ことである。その為には、アセンブリ自身に、アセンブリのハッシュをアセンブリの個人鍵で暗号化したものと公開鍵を持たせておけば良い。検証する側は、自分が持っている公開鍵を使ってその暗号文を復号し、それがアセンブリのハッシュと一致すれば、身元が正しい事を証明できる。もちろんこれは、検証する側がそのアセンブリの正しい公開鍵を事前に知っている場合に限られる。(実際にはもっと複雑な手順を踏んでいると思われる)。

(2) 公開キーを使って遅延署名を行う。

 公開キー(companyname_public.snk)をプロジェクト(又はソリューション)フォルダに配置する。
 VS.NETのプロジェクト(又はソリューション)を開き、AsemblyInfo.cs に以下の記述を追加する。

AssembyInfo.cs(一部)

[assembly: AssemblyDelaySign(true)] // falseにすると正式に署名される。
[assembly: AssemblyKeyFile(@"..\..\..\companyname_public.snk")]

 これでコンパイルすれば、DLLに遅延署名がされる。
 尚、AssemblyKeyFile属性はDLLの出力先からの相対パスとなるので、各環境に合わせて変更しなければならない。
  また、署名された(厳密名を持った)DLLは厳密名を持ったDLLしか参照できない為、必要ならばそれらも署名する必要がある。

3.3 グローバルアセンブリキャッシュ(GAC)に登録する。

(1) 署名検証機能をオフにする。

 遅延署名されたDLLは公開キーを持っているだけで、実際には有効な署名がされているわけではない。よって、DLLのロード時の署名検証時にエラーとなって しまう。
 以下の方法で.NET Frameworkの署名検証機能をオフにする必要がある。この処理は.NET Frameworkに対して行われるものであり、DLLそのものに何らかの変更がされる訳ではない。よって、オフにしたい全ての環境でこれを実行しなければならない。

% sn.exe -Vr DotNetCOMTest.dll

 ところで、「こんなことができるのなら、遅延署名など使わず最初から署名検証機能をオフにすればよかったのに」と思う人がいるかもしれないが、なんらかの形で署名されていないとGACへの登録そのものができない為、面倒だがしょうがない。

(2) グローバルアセンブリキャッシュ(GAC)に登録する。

% gacutil -i DotNetCOMTest.dll
※gacutil.exeは、.NET Framework SDKに含まれる(\Program Files\Microsoft.Net\ FrameworkSDK\Bin に含まれる)。

尚、登録解除は以下の通り。
% gacutil -u DotNetCOMTest

 DLLから参照している他のDLLがあるならば、全てGACに登録しなければならない。

3.4 VB6から使用できるようにする。

(1) system32フォルダにDLLをコピーする。

 DLLを、system32フォルダ(又はパスが通っているフォルダ)にコピーする。
 その後、1.と同様の処理を行えばよい。


3.5 署名を行う。

 遅延署名されたDLLは出荷前にちゃんとしたキー・ペアを使って署名しなければならない。

(1) 遅延署名DLLへ署名する。

% sn.exe -Rc DotNetCOMTest.dll companyname.snk

(2) 署名検証機能をオンにする。

 開発環境においては必ずしも行う必要はないが、正式に署名されたDLLの署名検証
機能をオンに戻すのは以下の方法で行う。

% sn.exe -Vu DotNetCOMTest.dll


4. その他の問題を解決する

4.1 最新のタイプライブラリを使って再コンパイルすると、実行時エラー429が発生する。

 DLL側の開発中は、頻繁にDLLそのものやタイプライブラリが更新されることになる。
 ところが更新されたタイプライブラリをVBに読み込んで再コンパイルしたexeを実行すると、実行時エラー429が発生する場合がある。
  regasmを使ってDLLを再登録するとこのエラーは起こらなくなる。しかし、DLLが更新されるたびにregasmを行っていたのでは非常に面倒であるし、配布もしづらい。

 これは以下のような理由から起こる。
 タイプライブラリを生成すると、クラスの固有キーがCLSIDとして生成され、タイプライブラリに埋め込まれる。既定ではこのCLSIDは毎回違うものになる為、タイプライブラリに埋め込まれるCLSIDも毎回異なることになる。
 regasmによってレジストリに登録される.NETクラスのキーはこのCLSIDであり、exeはこのCLSIDを用いて.NETクラスを探しに行く。最新のタイプライブラリ(つまり新しいCLSID)を使ってコンパイルされたexeがいくらレジストリを探しても、まだregasmされていない.NETクラスは見つけられないのである。

 これを回避する為にはクラスやインターフェイスに対してGUID属性を指定すれば良い。

[GuidAttribute("25731EF3-88ED-4322-9A90-E665598A4889") ]
public class Person : IPerson {
※GUIDは、[ツール]メニューから「GUIDの生成」を使って生成できる。

 これによりCLSIDは固定となり、いちいちregasmを行う必要はなくなる。

4.2 VB6のコード補完が使えない。

 そのままの設定だと.NETのクラスに対してはVB6のコード補完が働かない。これについては以下のように対処可能であるが、いくつか問題もある。

(1) ClassInterface属性にClassInterfaceType.AudoDualを設定する。

[ClassInterfaceAttribute(ClassInterfaceType.AutoDual)]
public class Person

 この属性値を指定すると、そのクラスのメンバが全てVB6のコード補完から使えるようになる。
 具体的にはAutoDualは全てのメンバのインターフェイスをタイプライブラリに記述する、つまり事前バインディングを可能にする指定である。

  しかしこれには重大な欠点がある。そのクラスのメンバのレイアウト(メンバの順番など)を変更すると、事前バインディングのインターフェイスも変わってしまうのだ。例えばクラスのメンバAとBの間にメンバXを加えたら、それまで動いていたアプリケーションが全て動かなくなってしまう。メンバAとBの順番を変えただけでも同様の結果になる。毎回全てのアプリケーションを再コンパイルするのは、開発時は問題ないとしても、一旦リリースしてしまった場合などは困難である。

 開発時のみの属性値だと思った方が良さそうである。(MSも、この属性値は「推奨しない」と言っている)

(2) ClassInterface属性にClassInterfaceType.AutoDispachを設定する。

[ClassInterfaceAttribute(ClassInterfaceType.AutoDispatch)]
public class Person

 この属性値を指定してもコード補完は働かない。それもそのはず、この属性値は既定値だからである。何も指定しなければ自動的にAutoDispatchとなる。
 具体的にはAutoDispatchは全てのメンバのインターフェイスをタイプライブラリに「記述しない」、つまり事前バインディングをできないようにする指定である。逆に言えば、遅延バインディング(実行時バインディング)に限定することになる。

  こうする事には理由がある。(1)の説明を読めばお分かりと思うが、事前バインディングを用いるとクラスのレイアウト変更に非常に弱くなってしまうからである。事前バインディングでなく遅延バインディングを用いることで、クラスのレイアウト変更とは完全に切り離すことができる。

(3) ClassInterface属性にClassInterfaceType.Noneを設定する。

[ClassInterfaceAttribute(ClassInterfaceType.None)]
public class Person : IPerson

 コード補完は使いたい、でもAutoDualは問題がある・・・このちょうど中間がNoneである。
 Noneは、そのクラスが実装しているインターフェイス(ここではIPerson)のみを事前バインディング可能にする指定である。これだけならAutoDualと同じ問題が起きそうだが、Noneの良いところはクラス側のレイアウト変更が外部に影響を及ぼさない点である。IPersonのレイアウトのみが外部に影響する。

 よって、Noneを用いるのは「COM公開用のインターフェイスが決まっており、今後も変更しない事が決まっている場合」 に限られる。これはCOMの思想と合致しており、あくまでもCOMとして利用するためのDLLであればこれで問題ないと思われる。

4.3 イベントをVB6から利用できない。

 .NETのクラスでイベントを発生させ、VBのクライアントからそれを受け取る・・・いかにも楽しそうなこのテクニックが、単に.NETのクラスにeventを定義しただけでは行えない。
 VB側でWithEventsステートメントを使っても、そもそもコード補完のリストに該当のクラスが現れないのである。

 イベントの利用はなぜか面倒な手続きが必要となっている。

 まず、そのイベントと同じ引数と名前のメソッドを持つインターフェイス(ここではPersonEvents)を定義し、以下のような属性を指定する。

public delegate void PersonEventHandler( string name );

[InterfaceTypeAttribute(ComInterfaceType.InterfaceIsIDispatch)]
public interface PersonEvents
{
  void NameChanged( string name );
}


public class Person
{
  public event PersonEventHandler NameChanged;

 次に、ComSourceInterfaces属性を使ってクラス側にそのインターフェイス名を指定する。

public delegate void PersonEventHandler( string name );

[InterfaceTypeAttribute(ComInterfaceType.InterfaceIsIDispatch)]
public interface PersonEvents
{
  void NameChanged( string name );
}

[ComSourceInterfaces("DotNetCOMTest.PersonEvents, DotNetCOMTest")]
public class Person
{
  public event PersonEventHandler NameChanged;

 ComSourceIntarfaces属性値の引数は、最初がイベント用に定義したインターフェイス名、二番目がそのインターフェイスが存在するアセンブリ名である。

 これでVB6からイベントを利用できるようになる。


5. 参考文献

Microsoft .NET Framework SDK クイックスタートチュートリアル
http://ja.gotdotnet.com/quickstart/default.aspx

解説 インサイド .NET Framework (@IT記事)
http://www.atmarkit.co.jp/fdotnet/technology/index/index.html

高度なCOM相互運用機能 - クラス インターフェイスの概要
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/
cpguide/html/cpconintroducingclassinterface.asp


高度なCOM相互運用機能 - COMシンクによって処理されるイベントの発生
http://www.microsoft.com/japan/msdn/library/default.asp?url=/japan/msdn/library/ja/
cpguide/html/cpconraisingeventshandledbycomsink.asp