VC++ で開発された一連の COM コンポーネントがあります。このようなコンポーネントへの参照が .NET プロジェクトに追加されると、Visual Studio は相互運用アセンブリを生成します。現在、そのようなアセンブリのセットがあります。
毎日のビルドを実行している間、生成されたすべてのバイナリにデジタル署名を付けます。私たちは作成者であるとは考えていないため、相互運用アセンブリは署名されていません。誰でも Visual Studio を使用して同じアセンブリを作成できます。
相互運用アセンブリにも署名する必要がありますか? また、厳密な名前 (sn.exe ユーティリティ) で署名する必要がありますか? そうする理由は何ですか？
これはしばらくの間、トリッキーなバランスでした。この問題は、Interop アセンブリをコードと共に配布する必要があり、独自のアセンブリに署名している可能性があるという事実に起因しています。アセンブリに署名する場合は、アセンブリが参照するすべてのアセンブリ (Interop アセンブリを含む) も署名する必要があります。したがって、署名する必要があります。
スタンドアロン アプリケーションを配布する場合、リスクはありません。作業を楽にするために、アセンブリに署名するだけで済みます。
コンポーネント ライブラリを配布している場合、ライブラリを使用する別の開発者が独自の相互運用機能アセンブリを生成し、独自のキーで署名する可能性があるため、状況は少し複雑になる可能性があります。これにより、あらゆる種類の命名と依存関係の問題が発生します。
Interop アセンブリの複雑さに応じて、プロキシ コードを個別の .CS/.VB ファイルに生成し、アセンブリに直接コンパイルできます。そうすれば、厳密な名前の問題について心配する必要はありません。
Sn.exe を使用して、ツールによって作成された相互運用機能アセンブリに、COM オブジェクトのラッパーとして厳密な名前を付けます。それらをロードするアセンブリが署名されているため、これを行う必要があるため、署名する必要があります。
使用する相互運用アセンブリを生成するには、次のようにします。
tlbimp Some_COM.dll /delaysign /publickey:"Some_PublicKey.snk" /out:Some_COM2Lib.dll"
完全に署名している場合は、明らかに /delaysign を削除してください。
アセンブリをオーサリングしないことに関しては、これが当てはまるかもしれませんが、それらについてはあなたが責任を負います。それらが他の誰かによって (偶然であろうとなかろうと) 置き換えられないようにしたいので、おそらく、他のコードに適用するのと同じレベルの署名/厳密な名前を適用する必要があります。
「publickey」を「keyfile」に置き換えます。
tlbimp Some_COM.dll /delaysign /keyfile:"Some_PublicKey.snk" /out:Some_COM2Lib.dll"