是否有任何理由將.snk文件與項目源一起發貨？

Question

我不時地在網絡上看到一個示例項目，其中包含一個.snk文件，用於使用強名稱對編譯結果進行簽名。

AFAIK 這是完全錯誤的 - 一旦公開.snk文件，任何人都可以生成一個程序集，可以用來替換原始代碼供應商提供的程序集，但現在包含惡意代碼。 我認為運送.snk文件的人不會認真對待這種風險而只是發送文件，因為否則該項目將無法現成的編譯。

除了“便利”之外，是否有任何理由發送.snk文件？

Answer 1

一個非常有效的問題。 我為我的 一部分不發貨的SNK文件，但提供指導如何制作一個自己和進行必要的更改（啟用InternalsVisibleTo例如）。

我認為目前的做法已經推動了我的微軟從VS2005開始的SNK處理的變化。 使用密鑰容器需要手動編輯CSPROJ文件和未記錄的MSBUILD項目KeyContainerName ... VS的默認值是將SNK復制到項目目錄中，這很方便但是錯誤的恕我直言。

Answer 2

我能想到的唯一原因是允許替換你的dll ......

當然，通常我會說“如果你想要直接替換，不要簽署你的dll。” 但如果它安裝在GAC簽名中是先決條件。 （或者，上次我知道）。

因此， 允許替換GAC中安裝的dll 。 是我能想到的唯一合理理由......

Answer 3

至少，我看不出將兩者，私人和公共密鑰對一起運送的理由。 如果您需要提供源代碼，您也可以使用.pfx，它通過您需要簽署程序集的密碼來提高安全性。

無論如何，在許多開源項目中，將.snk文件添加到源代碼控制中似乎是常見的做法（不良做法）。 這是一個非常好的問題！