私の同僚の 1 人は、アセンブリに署名することに非常に熱心です。彼は文字通り何にでも署名しようとします。署名されていない Microsoft のアセンブリを使用する場合でも、彼はソース コードを取得して署名し、代わりに他の開発者に彼のコピーを使用するように依頼します。
アセンブリに署名することの背後にある基本的な考え方を理解できます。つまり、特定のアセンブリが危険なハッカーによって危険にさらされないようにすることです。そのため、ソフトウェア開発会社の場合、顧客に .NET ライブラリをリリースする前に、アセンブリに署名する必要があります。
ただし、ここでは主に自分で使用するための Web アプリケーションを開発しており、使用するすべてのアセンブリに署名する意味がわかりません。
ここで何か不足していますか？
私は以前に署名されていないアセンブリを利用して問題を回避し、学術的な設定でそれが重要である理由を人々に示しました。署名されていない DLL ファイル (これも学術的な設定で) を、同じ名前で同じ署名で作成したものに置き換え、.NET Reflectorを使用して元のコードをコピー アンド ペーストしましたが、私の場合はユーザー名とパスワードを電子メールで送信しました。 「実際の」コードを呼び出す前に渡されていました。
署名されている場合、署名を一致させることはできますが、置換することはできません。Zippy の言うこととは逆に、実行時にコンパイル エラーが発生します。
アセンブリに署名することは決してやり過ぎではありません。30秒かかります。田舎に住んでいるなら、ドアをロックするのはやり過ぎだと言っているようなものです。持ち物でギャンブルをしたい場合は、開いたままにしてください。解雇されるには、セキュリティ侵害が 1 回発生するだけです。アセンブリに署名するのに 30 秒しかかからず、署名しないビジネス ケースはありません。パフォーマンスへの影響は無視できます。
信頼できる環境内で使用されるアセンブリに署名することは、私にはやり過ぎのように思えます。
署名されたアセンブリの興味深い点は、暗号で検証する必要があるため、署名されていないアセンブリよりもロードがわずかに遅いことです。
アセンブリに署名するには、アセンブリが依存するアセンブリにも署名する必要があります。私の推測では、これはすべてに署名したいという同僚の願望に貢献していると思います-コンパイラはそれを要求しています。
編集この答えを書いているので、あなたは賛成派と反対派の両方がほぼ同等のサポートを持っているのを見ることができます。ここには明らかに正しい答えはありません。
ただし、この編集を余儀なくされた点は、現在、NuGetから非常に多くのオープンソースライブラリを取得しており、それらの多くはまったく署名されていないということです。アセンブリに署名する場合は、依存関係にも署名する必要があります。署名されたオープンソースライブラリの多くは、署名に使用される秘密鍵をソースリポジトリで公開しています。
すべての場合と同様に、トレードオフが必要です。プライベート環境での作業の私の経験では、政府機関がコードを変更することを懸念している場合を除いて、署名の利点はほとんど理論的（または@ user289100が言及しているように学術的）です。署名が少しの努力のように見えるインフラストラクチャ。そうでなければ、すべてに署名しなければならないことからカスケードする課題の量は、それだけの価値がないように思われます。ただし、環境によって要件が異なる場合や、マゾヒストである場合があります。
厳密な名前を使用する場合のアセンブリのバージョン管理に関連する課題については、TeunDの回答も参照してください。
追加のポイント: アセンブリに署名すると、バージョン間の下位互換性が失われます。すべての参照にバージョン番号が含まれるようになり、他のバージョン番号を持つバージョンは互換性がないと見なされます。これにより、分散アセンブリの新しいバージョンへのアップグレードが妨げられます。
私の意見では、具体的な利益が見られる場合にのみ、アセンブリにコード署名する必要があります。
あなたの同僚は、なぜ彼が議会に署名するのが好きなのかについてあなたに何か示唆を与えましたか？ここでまだ説明されていない署名の利点の1つは、署名されたアセンブリのみをGACに配置できる（つまり、管理対象プロセス間で共有できる）ことですが、私の（明らかに経験の浅い）観点からは、欠点が利点を上回っているようです。
Microsoftコードの自己署名に関するあなたの逸話は、私には特に疑わしいようです。MSがコードに署名しなかった場合、おそらく理由がありますよね？そしてそれに署名することによって、あなたはそれを書かなかったときにそれに対して責任を負っています-将来があなたを噛むもう一つの機会です。
アセンブリに署名することについてのもう一つのことは、あなたの代わりに間違ったものを注入することはできないということです（また、事故によってあなた自身）。たとえば、アセンブリFoo.dllバージョン1.0を参照するプログラムを作成する場合、誰かが同じバージョンのアセンブリを作成し、ライブラリに署名するときに自分のライブラリを置き換えることができます（で少なくとも、それは簡単には不可能だと思います）。
署名は、アセンブリがGACに配置されている場合にのみ必要であり、それ以外は必要ありません。署名されたアセンブリは、誰かがそれらを台無しにすることを妨げません。ハッカーは、署名と、署名をチェックするその他のコードを取り除くことができます。
少し無駄に思えることに同意します。ファイルがあなたが考えているものであることを確認することが本当に必要です (そして改ざんされていません)。しかし、独自のネットワーク セキュリティと Web サーバーの範囲を信頼している場合、Web アセンブリに署名することは冗長な手順のように思えます。
しかし、おそらくそれは私の中小企業の経験です。ミッション クリティカルなオンライン バンキング Web サイトについて話している場合は、サイン アウトしてください。
何かを出荷する予定がある場合、および/または実際に出荷する理由がある場合は、それを行うことを検討してください。それ以外の場合は、単に面倒です。あなたの同僚に、彼がこれを行うことで実際に何を得ているか尋ねてみたい.
私は以前に署名されたアセンブリに遭遇したことがありますが、アセンブリに署名すること、それが何のために、どのように行うかについてほとんどまたはまったく知らない人々の数を考えると、それは後々の苦痛です。絶対に必要でない限り、気にする必要のないもう 1 つのことです。
deploy-from-the-web ClickOnce XBAPでアセンブリを使用する場合は、アセンブリに署名する必要があります。
さらに、参照されているすべてのアセンブリにも署名する必要があります。
次のようなエラーが発生することがあるため、アセンブリに署名します (これはテストによるものですが、アプリケーションの実行中に発生する可能性があります)。
System.IO.FileLoadException : Could not load file or assembly 'Latitude.Platform.Core, Version=1.0.5871.22518, Culture=neutral, PublicKeyToken=7926214d13e12325' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
TearDown : System.IO.FileLoadException : Could not load file or assembly 'Latitude.Platform.Core, Version=1.0.5871.22518, Culture=neutral, PublicKeyToken=7926214d13e12325' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
私たちは、 Visual Studio が時々間違って古いコードを実行することを発見しました。
古いコードを実行している場合にエラーが必要な場合は、アセンブリに署名します。
nugetパッケージを作成している場合は、アセンブリに署名してください。署名されていないアセンブリは、最新バージョンのコードを実行していることを確認したい私たちにとって扱いにくいものです。 Visual Studio を修正できません。私にできることは、Visual Studio が間違っていることを検出することだけです。ナゲットアセンブリに署名してください。