17

30 人を超える開発者、20 を超えるソリューション、および 60 を超えるプロジェクトを抱える組織で、署名済みアセンブリを適用するための推奨事項とベスト プラクティスを探しています。Visual Studio Team System 2008 と TFS を使用しています。

キーの作成とアセンブリへの署名は非常に簡単で単純な手順ですが、これをどのように管理するのが最善の方法なのかが気になります。

これまでの私の考え：

  • 通常、3 ～ 20 個のプロジェクトを持つ各ソリューションには、ソリューション ルート フォルダーに配置された単一の .pfx キー ファイルがあります。
  • 各ソリューションには、キーの一意の強力なパスワードがあります。

そのアプローチで問題が発生することはありますか?

その他のアイデア:

  • ソリューション全体のすべてのプロジェクトに同じキー ファイルを使用します。これは私たちにとって物事をより簡単にしますか？それは悪い考えですか？それは可能ですか？
  • 各プロジェクトには独自の一意のキーが必要ですか? なぜ、なぜですか？

意見、良い/悪い経験、および推奨事項は大歓迎です。:)

4

3 に答える 3

13

以前は、複数のソリューションやプロジェクトに対して 1 つのキーを非常に効果的に使用してきました。秘密鍵ファイルにアクセスできる人だけが、厳密な名前のチェックに合格したビルドを公開できるようにする単純なアプローチです。

注: 単一のキー ファイルを使用するには、各プロジェクトへのリンクとしてファイルを追加するのが最も簡単であることがわかりました。

私が見た 1 つの欠点は、開発者がキー ファイルを使用できるようにすることは、本来あるべきほどプライベートではないことを意味するということです。理想的には、アクセスできる人やパスワードを知っている人はできるだけ少なくする必要があります (例: ビルド プロセスのみ)。

単一ファイルのアプローチでは、厳密な名前付けの利点を維持しながら、キーの管理をシンプルに保ちます (1 つしかありません)。

于 2009-09-10T05:16:25.977 に答える
6

現在、ソリューションのすべてのプロジェクトで同じ強力なキー (.SNK) を使用しています。プロジェクトに応じて、プロジェクトごとに異なるキーを管理する方法が異なります。

より高いセキュリティが必要な場合は、プロジェクトごとにキーを再作成できると思いますが、管理するのは悪夢になるでしょう. 結局のところ、SNK は、コードがあなたの会社からのものであることを示し、アセンブリが変更されるのを防ぐだけであり、社内の巨大なセキュリティ機能ではないことに注意してください。

そのためには、開発者がコードをビルドすることを信頼しない/望まない場合は、ソース管理を制限し、ビルド サーバーなどの使用を検討する必要があります。

于 2009-09-10T05:17:03.993 に答える
2

すべてのプロジェクト フォルダーと同じレベルにあるルート レベルのフォルダーに、厳密な名前のキーを保持することもできます。プロジェクト プロパティ -> 署名タブでこのファイルを選択すると、キー ファイルがプロジェクト フォルダにコピーされます。このファイルを削除します。メモ帳で .csproj ファイルを開きます。次のタグ mykey.snk を探します キー ファイルのパスを手動で編集します。必ずプロジェクト フォルダーからの相対パスを指定してください。ファイルを保存します。Visual Studio でプロジェクトのプロパティを開きます。正しい場所を指すように更新されたパスを確認できます。

于 2010-10-18T09:52:08.350 に答える