1

私はtlbimp/noclassmembersで遊んでいて、オプションを見つけました。

ああ！私はそれが早期の拘束力を壊すに違いない！

しかし、残念なことに、このオプションで生成された相互運用機能アセンブリを使用した場合でも、すべてが正常に機能しているように見えました。つまり、この新しい相互運用機能アセンブリに置き換えるときに、コンパイルの問題（またはテストマシンでの明らかな実行時の問題）はありませんでした。

では、正確には何をするのでしょうか。また、このオプションを常に使用することが望ましくないのはなぜですか。/noclassmembers

次のことを考慮してください。

  1. どうやら、「TypeLoadError例外を回避する」必要がある場合があります。
  2. 結果として得られる相互運用機能アセンブリは小さくなります（私の場合はサイズの3/4にすぎません）

（ファイルサイズから判断すると、Visual Studioの自動生成された相互運用機能アセンブリはこのオプションを使用しません。）

ありがとう。

4

1 に答える 1

2

COMは、インターフェイスベースのプログラミングモデルを使用します。コクラス自体はメンバーを公開しないでください。インターフェイスを実装し、IUnknown :: QueryInterface（）を使用して公開します。ただし、タイプライブラリは、コクラスがそれ自体のメンバーを公開することを妨げません。[ComVisible]であり、[ClassInterface（ClassInterfaceType.None）]属性を適用しないマネージクラスで発生することは注目に値します。これらの目に見える実装の詳細は、TypeLoadExceptionの原因となる可能性があります。

したがって、このオプションを使用しても問題が発生しないのは当然のことです。正常に動作するクライアントコードは、公開されたインターフェイスのみを使用します。oleview.exe SDKツールを使用して、タイプライブラリを調べ、何が公開されているかを確認できます。File + View Typelibを使用して、.tlbまたは.dllを選択します

于 2012-01-24T19:00:05.240 に答える