自動生成された COM Interop アセンブリのもっと便利な使い方

.NET

IDL とコード自動生成の罠

なんで自動生成したタイプライブラリの内容が間違ってるんだろう。char *pStr を ref short pStr に直すなよ……

実は IDL から TLB に変換したところでその辺の判断に必要な情報が落ちちゃうんですよねぇ．困った話です．私もむかし困りました．Text Services Framework も TLB が提供されてなかったので．

自動生成した Interop アセンブリより使い慣れた言語のソースコード

結論から言えば，TLB を経由して生成された Interop アセンブリに，最適なマーシャリング設定は期待できません．
私がよく使う手は，.NET Reflector で Interop アセンブリを C# のソースコードに再変換してしまうというものです．得られたソースコードをプロジェクトに追加し，IDL とドキュメントを眺めながらマーシャリング設定を手で調整します．この作業が不毛と感じだしたら，あとはもう IDL のパーサを作るところまで行くしかないでしょう．
このテクニックは「COM 参照の追加」で追加される Interop アセンブリ一般に使用できます．「COM 参照の追加」は内部的には tlbimp や TypeLibConverter.ConvertTypeLibToAssembly と等価です．
基本的に，生成された Interop アセンブリには単なる型定義しか入っていません．要するに，構造体の定義と P/Invoke のメソッド宣言だけが書かれたアセンブリのようなものです．実際にマーシャリングをどう行うかの実装は，CLR 自体が最初から「型を横断する形」で持っていますから，Interop アセンブリに実装は不要というわけです．
だったら使い慣れた言語で書かれた同等物をプロジェクトに取り込んでも同じ話でしょう．自動生成された Interop アセンブリは，再配布時にも手間になることが多いですしね．自動生成された P/Invoke のメソッド宣言だけが延々書かれているようなアセンブリを，ありがたがってそのまま使う必要はないのです．

過去の関連記事