interopアセンブリに署名する必要がありますか？

Question

VC++で開発された一連のCOMコンポーネントがあります。このようなコンポーネントへの参照が.NETプロジェクトに追加されると、Visual Studioはinteropアセンブリを生成します。このようなアセンブリが今や用意されています。

毎日のビルドを実行している間に、生成されたすべてのバイナリに電子署名で署名します。 Interopアセンブリは署名されていません。私たちが著者ではないと感じているからです。だれでもVisual Studioを使用して同じアセンブリを作成できます。

interopアセンブリにも署名する必要がありますか？また、強力な名前（sn.exeユーティリティ）で署名する必要がありますか？そうする理由は何ですか？

Answer 1

これはしばらくの間、微妙なバランスになっています。この問題は、コードとを使用してInteropアセンブリを配布する必要があり、独自のアセンブリに署名する必要があるという事実に起因します。アセンブリに署名する場合は、参照するすべてのアセンブリ（Interopアセンブリを含む）に署名する必要があります。だからあなたはそれらに署名しなければならない。

スタンドアロンアプリケーションを配布する場合、リスクはなく、簡単に作業を進めるためにアセンブリに署名してください。

コンポーネントライブラリを配布する場合、ライブラリを使用する別の開発者が独自の相互運用機能アセンブリを生成することがありますが、独自のキーで署名する可能性があるため、ややこしいことがあります。これは、あらゆる種類の命名と依存関係の問題を引き起こします。

Interopアセンブリの複雑さに応じて、プロキシコードを別の.CS/.VBファイルに生成し、アセンブリに直接コンパイルすることができます。それで、あなたは強い名前の問題について心配する必要はありません。

Answer 2

Sn.exeを使用して、COMオブジェクトのラッパーとしてツールによって生成された相互運用機能アセンブリの名前を厳密に指定します。それらをロードしているアセンブリが署名されているので、署名する必要があります。

tlbimp Some_COM.dll /delaysign /publickey:"Some_PublicKey.snk" /out:Some_COM2Lib.dll" 

あなたが完全に署名されている場合は明らかに/ delaysignを削除します。我々が使用する相互運用機能アセンブリを生成するには

。

assmebliesをオーサリングしない場合は、これが原因である可能性がありますが、その責任はユーザーにあります。他の人が（偶然にもそうでなくても）置き換えられないようにするため、おそらく、他のコードに適用するのと同じレベルの署名/厳密な名前を適用する必要があります。 「キーファイル」で「公開鍵」を交換してください

Answer 3

は：

tlbimp Some_COM.dll /delaysign /keyfile:"Some_PublicKey.snk" /out:Some_COM2Lib.dll"