問題タブ [tlbimp]

ユーザーが特定の専用シミュレーターの COM インターフェイスをより簡単に使用できるようにする C# プログラムとライブラリーを作成しました。

現在、サポートしたいシミュレータのバージョンごとに異なるバージョンの C# ライブラリをビルドして配布する必要があります。シミュレーターを開発する会社は定期的に新しいバージョンをリリースし、新しいバージョンごとに増分されたメジャー バージョン番号を取得します。私が知る限り、バージョン間での COM インターフェイスの変更は (まだ) ないため、呼び出しと動作は私の観点からはすべて同じです。ただし、シミュレーター バージョン 9.0 に対してライブラリとインストーラーをビルドし、ユーザーがバージョン 10.0 をインストールしている場合、私の C# プログラムはシミュレーターの COM インターフェイスを見つけることができません。(シミュレーターのマイナー アップグレードでも、COM インターフェイスのメジャー バージョン バンプが発生します。) そのため、サポートされているすべてのバージョンのシミュレーターに対してライブラリをビルドする必要があります。うざい、

これを行う方法が必要なようです。このページに方法が説明されているのではないかと思いました: How to: Wrap Multiple Versions of Type Libraries。しかし、それは私にはうまくいかなかったようです。

もちろん、私がそれを正しくしなかった可能性があります。指示に従って、COM インターフェイスの 2 つのバージョンの .il ファイルを取得しました。9.0 と 10.0。しかし、私は次のステップについて混乱していて、例を見つけることができませんでした:

テキスト エディターを使用して、Tlbimp.exe によって追加された属性の下に 2 つ目の PrimaryInteropAssemblyAttribute 属性を挿入します。タイプ ライブラリの 2 番目のバージョンを表すメジャー バージョン番号とマイナー バージョン番号を含めます。

アセンブリ ブロックを複製する必要があるのか​​、それともブロック内の行だけを複製する必要があるのか​​がわかりませんでした (これにはバージョン情報が表示されません)。そこで、次のようにアセンブリ ブロックを複製しました。

これはうまくいきませんでしたが、他の解釈がどのように可能になるかわかりません。誰かが私が間違っていることを見ることができますか? 私は完全に間違った方向に進んでいますか、それとも .il ファイルの間違った部分を結合しただけですか?

PowerShell から MSMQ トリガーとルールを使用していくつかの作業を行っていますが、問題が発生しています。

トリガー/ルールにプログラムでアクセスする唯一の方法は、mqtrig.dllアセンブリを利用することであり、調査によると、tlbimp.exeを実行して、PowerShell からロードできる .NET アセンブリを作成する必要があることがわかっています。オッケー、問題ないよ！

tlbimpを実行して生成されたアセンブリを読み込もうとすると、次のエラーが発生します。

Add-Type : ファイルまたはアセンブリ 'file:///C:\users\daniel.mann\desktop\mqtrig.dll' またはその依存関係の 1 つを読み込めませんでした。このアセンブリは、現在読み込まれているランタイムよりも新しいランタイムによってビルドされているため、読み込むことができません。

見ると、次のようになり$psversiontableます。

それで、わかりました。わかった。CLR 2.0 アセンブリを生成するバージョンのtlbimpを使用する必要があります。簡単ですよね？

たまたま、このボックスに古いバージョンの Visual Studio がいくつか入っていたので、次の 1 つを見つけました。

C:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin>tlbimp

Microsoft (R) .NET Framework Type Library to Assembly Converter 2.0.50727.42

同じエラーが発生することを除いて。

2.0、3.5 、および 4.0 のバージョンを提供するtlbimpの少なくとも 3 つの異なるバージョンを試しました。PowerShell 1.0/2.0の正しいバージョンは何ですか? また、開発マシンのどこに配置されますか?

PowerShell.exe.config ファイルを作成して新しいアセンブリを読み込めるようにすることはできますが、ここでは絶対に飛ばしません。これは自動展開シナリオの一部であり、行かなくて済むようにしたいと思います。展開前のステップとして構成ファイルをいじります。

単純なインターフェース定義を含む idl があります。

SAFEARRAY(float) を返すメソッドを追加しますが、TlbImp を実行してマネージ コードのインポート ライブラリを作成すると、次のようになります。

どこに問題があるのでしょうか?
多分私は何かを参照する必要がありますか？もしそうなら…どうすればいいですか？

よろしく。

生成された COM Interop アセンブリでget_Dataとして使用できるDataプロパティを持つMyCOMCtlクラスを持つCOM コントロールがあります。この COM コントロールに対して、次の 2 つの異なる相互運用機能アセンブリが生成されます。

1. VS2010 に COM コントロールを追加すると、相互運用機能 (および Ax...) が自動的に生成されます。
2. VS2010 コマンド プロンプトから TLBIMP v4 ツールを使用します。

問題は、相互運用アセンブリが TLBIMP を使用して生成されると、get_Data が次のようになることです。

しかし、VS2010 によって自動生成されると、次のようになります。

私のコードには、 objectを返す 2 番目のコードが必要です。VS2010 プロジェクトは.NET Framwork 4 Client Profileをターゲットにしており、TLBIMP のバージョンは 4.0.30319.1 です。

なぜこうなった？これを修正する方法はありますか？

C++ でCOM を使用するため.dllに、コンパイル時に必要な#importのは TLB (または TLB を抽出する DLL) だけで、準備は完了です。C# でコンパイルするために DLL を登録する必要があるのはなぜですか (reg-free COM は登録済みと同じです)。TLB が十分でないのはなぜですか?

.dllCOM オブジェクトを使用したコンパイルに関する私の質問に注意してください。実行時にオブジェクトを登録する必要がある理由を理解しています。

バックグラウンド

私たちのビルドは、ant とカスタム タスクを使用して、Visual Studio プロジェクト/ソリューションと一部の Java プロジェクトをビルドします。その構造は基本的に大きなツリーであり、プロジェクトからの成果物は通常、共通のビルド ディレクトリにコピーされます。

これは以前は完全に混乱していましたが、ant スクリプトを大幅に簡素化し、現在は Visual Studio プロジェクト/ソリューションのほとんどを使用しています。これらのプロジェクトは非常に古く、2013 年までのすべてのバージョンの Visual Studio でアップグレードされています。私が行った変更の一部は、既定のプロジェクト プロパティとマクロをできるだけ多く使用することでした。これらのほとんどは、以前はハードコードされていました。

$(Configuration) マクロを使用して成果物をさまざまな構成から分離するようにプロジェクトを変更しましたが、これらは他のソリューションの他の依存プロジェクトの共通の場所にコピーされます。そのため、混乱を避け、実際にデバッグ ビルドがすべてのデバッグ ライブラリにリンクしていることを確認するために (以前は発生していませんでした)、ターゲット名にサフィックスを追加しました。たとえば、デバッグ Unicode ビルドのターゲット名は $(ProjectName)DU になります。

問題

これまでのところこれは素晴らしいことですが、COM ライブラリの 1 つでこれらの変更を完了する方法がわかりません。このライブラリには IDL ファイルがあり、MIDL コンパイラは TLB ファイルを生成します。これは良い方法ではないかもしれませんが、今のところ、ビルドに応じて TLB ファイルにも異なる接尾辞を付けたいと思いました。問題は、MIDL 構成のタイプ ライブラリ プロパティを変更すると、RC ファイルのコンパイル時ディレクティブが壊れることです。_UNICODE または _DEBUG が設定されているかどうかに応じて、TEXTINCLUDE ブロックで #ifdefs を使用できる可能性があると考えました (RC ファイルを壊さないように [リソース インクルード] ダイアログを介して行う場合)。また、#ifdef チェックが必要な他の importlib 属性があることも意味します。

現時点では、TLB ファイルの名前を変更しなくても機能しますが、それは現在、このソリューション内でのみ使用されているためです。

誰かがこのようなことをしたことがありますか、またはより良い解決策を知っていますか?

アップデート

ここで本当に知っておく必要があるのは、ある COM DLL の型を別の COM DLL で使用する最良の方法は何ですか? importlib を使用する必要がありますか? MSDN のドキュメントによると、ほとんどの場合、代わりにインポートを使用する必要があります。私はこれを試しましたが、たくさんのものを壊しました。

複数のプロジェクトを含む従来の Visual Studio ソリューションがあります (Visual Studio 2013 にアップグレードされています)。これらのプロジェクトの 1 つは、COM DLL を生成します。次に、この DLL からの TLB は、importlib 属性を介して別のプロジェクトの IDL ファイルにインポートされます。MIDL コンパイラが依存プロジェクトの IDL ファイルをコンパイルしようとすると、次の警告が生成されます。

警告 MIDL2015: importlib で tlb を読み込めませんでした

TLBファイルへのフルパスを使用すると機能します。

MIDL -> 追加のインクルード ディレクトリ プロパティにパスを追加しようとしましたが、これは IDL、ヘッダー、および ACF ファイル ( /I switch ) のみに対応していると思います。

Linker -> Additional Library Directories プロパティも試しましたが、これもうまくいきませんでした。

importlib 属性を解決するときに MIDL が使用する検索パスは何ですか?

ベンダーから提供された 4.0 フレームワークの dll があり、3.5 を使用しています。ベンダーから、dll は com インターフェイスを公開しているので、まだ使用できるはずだと言われました。.dll ファイルと .tlb ファイルの両方があります。いくつかの調査を行った後、TlbImp を使用してみましたが、エラーが発生します。

コマンド TlbImp.exe myDll.dll は、それが有効なタイプ ライブラリではないことを示しています。
コマンド TlbImp.exe myDll.tlb は、ライブラリが CLR アセンブリからアセンブルされ、CLR アセンブリとして再インポートできないことを示しています。

問題が何であるか、または C# 08 のコマンドにアクセスするために使用できる別のアプローチに関するアイデアはありますか? ありがとう！