現在、強い型のキーで署名されるように.netライブラリを設定しています。ソリューションごとにdllに署名するために.snkファイルを使用しています。したがって、ソリューションごとに、独自の.snkファイルがあります。これは正しい習慣ですか？たとえば、ソリューション内の各プロジェクトからいくつかの異なるdllを出力するクラスライブラリがあり、それぞれが.snkキーで署名されています。
私の質問は、ソース管理でのキーの保存に関するものです。リリースごとにコードを分岐します。キーが必要です：
A.ブランチの外側に存在し、ブランチされていない-ブランチごとに同じキーを確保するB.ブランチ内に存在するが、ブランチごとに同じであるC.ブランチ内に存在し、ブランチごとに変更するD.その他（指定してください）
提案をお願いします？
また、SolutionInfoファイルに以下を配置してdllに署名することをお勧めしますか、それとも別の方法がありますか？
[assembly: AssemblyKeyFile("<<absolute path>>\\MyKey.snk")]
基本的な戦略は 2 つあります。1 つ目は、悪意のある目的でアセンブリが置き換えられることを恐れる必要がある非常に大規模な企業に適しています。マイクロソフト、アドビ、オラクルなど。少数の信頼できるビルド エンジニアだけがキーにアクセスでき、コードは遅延署名によって開発およびテストされます。
もう 1 つは他のすべての人のためのものです。アセンブリに署名して GACに入れるか、GAC に入れたいと考えている第 2 のパーティにアセンブリを出荷するためです。使用する実際のキーは問題ではなく、大きなボールトに入れる必要もありません。プロジェクト+プロパティ、署名タブを使用するだけです。キーを生成し、プロジェクトと共にチェックインします。
特定の実装にもよりますが、通常は、作業中のブランチに .snk キー ファイルを保持することをお勧めします。
使用例: v1.0 と v2.0 の間でアセンブリ署名キーを変更しています。ブランチで正しいキーに対して開発を行いながら、トランクで現在のコードを維持できるようにする必要があります。
次に、(これはベスト プラクティスにすぎず、状況によっては必要ではありません。たとえば、他の開発者をどれだけ信頼しているかなど)、ソース管理に保持する .snk ファイルには公開鍵のみを含める必要があり、ソリューションを構成する必要があります。サインのみを遅らせる。
これにより、ビルド サーバー (ほとんどの場合、Windows キー マネージャー) に保護された状態で格納され、アセンブリに完全に署名するために "リリース" ビルド中に使用される秘密キーの配布が防止されます。ビルド サーバーがない場合は、ビルド後に sn.exe を使用してアセンブリに署名できる秘密キーを 1 人または 2 人に預けることをお勧めします。シンプルなシェル スクリプトまたはバッチ ファイルで、このプロセスを自動化できます。
最後に、遅延署名を選択した場合にのみsn.exe -Vr *,<publicKeyToken>、遅延署名アセンブリを実行/デバッグするすべての開発者ワークステーションで、.NET アセンブリ検証リスト ( ) にエントリを追加する必要があります。プラットフォーム ターゲットによっては、VS コマンド プロンプトの 32 ビット バージョンと 64 ビット バージョンの両方で実行する必要があります。
それが役立つことを願っています。