每隔一段時間我都會在網絡上看到一個示例項目，其中包含一個用於用強名稱簽名編譯結果的.snk文件。是否有任何理由將.snk文件與項目源一起發佈？
AFAIK this is plain wrong - 一旦.snk文件被披露，任何人都可以生產一個組件，可以用來替換原始代碼供應商提供的組件，但現在包含惡意代碼。我想運輸.snk文件的人不會認真對待這種風險，只是運送文件，因爲否則該項目將無法現成編譯。
運送.snk文件除了「方便」之外是否有任何理由？
一個非常有效的問題。我爲mypart不要運送SNK文件，但要做provide instructions如何自己生成一個並進行必要的更改（例如啓用InternalsVisibleTo）。
我認爲，目前的做法已經推動我的微軟與VS2005開始SNK處理的變化。使用密鑰容器需要使用無證MSBUILD項目KeyContainerName手動編輯CSPROJ文件... VS的默認值是將SNK複製到項目目錄中，這很方便，但卻是錯誤的。
至少，我看不出有理由將兩者，私人和公共密鑰對一起運送。如果您需要發佈源代碼，您可以使用通過密碼提高安全性的.pfx，以便籤署程序集。
無論如何，在很多開源項目中，將.snk文件添加到源代碼管理中似乎是很常見的做法（不好的做法）。所以一個非常好的問題！
我能想到的唯一理由，就是讓一個下拉更換爲DLL ...
當然，通常我會說：「如果你要滴不籤你的DLL替代品「。但如果它安裝在GAC簽名中是一個先決條件。 （或者，上次我知道）。
因此允許替換您的dll安裝在GAC。是我能想到的唯一理性原因...
強名稱是必須的恕我直言：你不能簽署一個引用未簽名程序集的程序集，因此這會創建一個未簽名程序集鏈。在未簽名的程序集上，版本未被檢查AFAIK，這使得它們非常不安全，因爲你再次打開DLL地獄的大門。 – Lucero 2011-01-31 12:17:51