.snkファイルの場所とその管理

Question

現在、厳密に型指定されたキーで署名された.netライブラリをセットアップしています。 .snkファイルを使用して、ソリューションごとに自分のdllに署名しています。したがって、各ソリューションには独自の.snkファイルがあります。これは正しい練習ですか？たとえば、ソリューション内の各プロジェクトからいくつかの異なるdllを出力するクラスライブラリがあり、それぞれが.snkキーで署名されています。

私の質問は、ソース管理のキーの格納を囲んでいます。私は各リリースのために自分のコードを分岐します。キー必要があります。

A.枝の外に存在し、分岐していない - 各ブランチ B.ためにその同じキーを確保し、ブランチ内に存在するが、各ブランチ C.についても同じことが支店や変更内に存在します各支店について D.その他（具体的にご記入ください）

ご提案ください。

また、SolutionInfoファイルに以下を挿入してdllに署名するのがベストプラクティスですか、それとも何か別の方法がありますか？

[assembly: AssemblyKeyFile("<<absolute path>>\\MyKey.snk")] 

Answer 1

あなたの特定の実装に応じて、それは通常、あなたが取り組んでいる枝でた.snkキーファイルを維持するためのベストプラクティスです。

使用例：v1.0とv2.0の間でアセンブリ署名鍵を変更しています。ブランチ内の正しいキーに対して開発しながら、トランク内の現在のコードを維持できるようにする必要があります。

第2に、（状況に応じて、これはベストプラクティスである必要はありません。たとえば、他の開発者をどれくらい信頼しているかなど）、ソース管理で保持する.snkファイルには公開鍵ソリューションは、サインのみを遅延させるように構成する必要があります。

これは、ビルドサーバー（Windowsキーマネージャ）に保護された状態で保存され、アセンブリを完全に署名するために "リリース"ビルド中に使用されるプライベートキーの配布を防ぎます。ビルドサーバーがない場合は、ビルド後に1〜2人が秘密鍵を委託してsn.exeでアセンブリに署名できるようにすることをお勧めします。シンプルなシェルスクリプトやバッチファイルは、このプロセスを自動化できます。

最後に、遅延を選択する場合に限り、遅延署名付きアセンブリを実行/デバッグするすべての開発者ワークステーションの.NETアセンブリ検証リスト（sn.exe -Vr *,<publicKeyToken>）にエントリを追加する必要があります。プラットフォームのターゲットに応じて、VSコマンドプロンプトの32ビット版と64ビット版の両方で実行する必要があります。

希望に役立ちます。

Answer 2

基本的な戦略は2つあります。最初のものは、他の誰かが悪意のある目的のためにアセンブリを置き換えるのを恐れなければならない非常に大規模な企業に適しています。マイクロソフト、アドビ、オラクルのようなもの。信頼できるビルド・エンジニアの少数であるが、キーへのアクセス権を持っている人はいません。コードは遅延署名によって開発され、テストされます。

もう1つは他の人のためのものです。アセンブリに署名してGACに入れるか、 GACに入れたい第2者に出荷するだけです。あなたが使用する実際のキーは重要ではないし、大きな金庫に置く必要もありません。プロジェクト+プロパティ、[署名]タブを使用します。キーを生成し、プロジェクトとともにチェックインします。