爲什麼不同版本的Silverlight程序集具有相同的版本號？

爲什麼不同版本的Silverlight程序集具有相同的版本號？爲什麼不同版本的Silverlight程序集具有相同的版本號？

Location: ...\Silverlight\v3.0\System.Core.dll 
Name: System.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e 

Location: ...\Silverlight\v4.0\System.Core.dll 
Name: System.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e 

Location: ...\Silverlight\v4.0\Profile\WindowsPhone\System.Core.dll 
Name: System.Core, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e

雖然標準的.NET有不同的版本號

Location: ...\Framework\v4.0.30319\System.dll 
Name: System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 

Location: ...\Framework\v2.0.50727\System.dll 
Name: System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

來源

2010-12-14 Simon

我一直想知道這一點。我想我只是想錯過一些東西。 – 2010-12-14 00:57:22

這是一個很好的問題。 – 2010-12-14 01:08:29

沒有什麼利用的2.0.5.0版本System.Core程序的停止Silverlight 4的框架。 System.Web版本2.0附帶的.NET 3.5框架。但是，.NET 4框架附帶更新版本的System.Core。

來源

2010-12-14 03:01:02

我認爲你錯過了這一點。所有Silverlight文件的所有版本都是相同的。儘管它們是明顯不同的文件。 – Simon 2010-12-14 07:02:58

我認爲這是開發團隊忘記更改版本號和沒有檢查清單，但我不是100％確定。沒有任何機制可以自動完成這個任務，沒有中央編譯器。只要開發組中的每個用戶具有帶公鑰標記的強名稱，就可以編譯此代碼組合件。我對這個問題的專家的完整答案感興趣。

來源

2010-12-14 03:35:51

這些是MS出貨的組件。當然，你不認爲MS開發團隊忘記更改版本號，是嗎？ – Gabe 2010-12-14 07:22:38

在任何成熟的開發過程中，都有一個[構建系統]（http://en.wikipedia.org/wiki/Build_automation），可以爲整個團隊的變更自動編譯程序集，因此概念上是集中式編譯器。單個開發人員不負責創建實際發佈的程序集。構建系統產生這些。 – 2010-12-18 16:14:22

真的嗎？我認爲他們使用強大的鑰匙創建了一個組件，將強大的鑰匙添加到組件中，並將該強大的鑰匙存儲在唯一的ID下。該唯一ID是公鑰標記。該版本由編譯該項目程序集的最後一個人員設置。由於您可以在標牌解決方案中包含多個項目，因此每個項目可能都有自己的簽名程序集，具體取決於項目類型。構建系統聽起來很酷，我不得不調查它。謝謝（你的）信息。 – 2010-12-19 12:45:16

也許他們不想讓開發人員重新編譯Silverlight應用程序針對不同版本的Sliverlight框架...

來源

2010-12-18 14:55:30 Kii

這不適用於Windows Phone程序集，因爲如果你重新編譯它們，它們將不會運行。 – Simon 2010-12-19 01:50:18

確切的同樣的事情發生與基類庫（如System.dll中）爲桌面.NET 2.0,2.0SP1,2.0SP2,3.0,3.0SP1,3.5和3.5SP1的版本，它們都具有完全相同的[AssemblyVersion]，2.0.0.0。直到.NET 4.0的版本碰到4.0.0.0

程序集版本代表程序集的接口public。其他程序集可訪問的類型成員中的重大更改需要新的[AssemblyVersion]。必然如此，因爲這需要使用這些類型的客戶端代碼進行重新編譯。我檢查了你提到的System.Core.dll版本。通過裝配體的反射器輸出輸出的一陣痛楚。私人和內部班級和方法發生了很多變化。但不是公衆的，相同的類型和方法。

並非完全如此，並且這也發生在桌面版本中，StrongBox類在4.0版本中獲得了默認構造函數。保存寬限可能是構造函數被記錄爲「此API支持.NET Framework基礎結構，並且不打算直接從您的代碼中使用」。特別是在Silverlight中，針對4.0的應用程序絕不會偶然看到該類的3.0版本，這與桌面案例不同。

來源

2010-12-18 20:31:51

漢斯。這可能對Silverlight 3和Silverlight 4有意義，因爲您可能會認爲它們是相同的運行時。但不適用於顯然是不同的公共API的Windows Phone Assemblies。 – Simon 2010-12-19 01:49:20

我沒有檢查，但我不明白爲什麼它會有所不同。只是Silverlight。 – 2010-12-19 07:50:46

對於.NET，對於簽名（.snk）程序集，不改變程序集版本號的第一個原因是爲了確保程序集的強名稱保持不變。通過這種方式，不用搞亂.config文件或自定義策略，任何通過對程序集的引用構建的客戶端仍然可以加載而不會抱怨。

默認情況下（沒有定義assemblies redirections），如果更改版本，程序集的強名稱也會更改，並且所有現有程序集都將無法運行。

如果你永遠不會改變版本，當然，你必須確保你不用不同的類或方法簽名來破壞這些相同的客戶端。

這就是爲什麼大多數時候，開發人員傾向於保持相同的版本...永遠，當可能的時候，對於CoreCLR（Silverlight的CLR）以及.NET CLR也是如此。

儘管在.NET CLR的情況下，他們改變版本的事實實際上給現有的.NET應用程序帶來了一些問題。有時，現有的.NET 2個應用程序需要這在.NET 4的上下文添加到config文件：

<configuration> 
    <startup> 
    <supportedRuntime version="v4.0.30319" /> 
    </startup> 
</configuration>

你可以看一下這篇文章，解釋瞭如何複雜這一切都可以在幕後：Version Compatibility in the .NET Framework

來源

2010-12-21 16:51:53

這或許可以解釋銀光組件是相同的，但並不能解釋爲什麼silverlight和WP7組件具有相同的版本號。 – Simon 2010-12-21 23:40:15

如果爲SL構建的程序集在不重寫的情況下對WP7有些兼容，那可以解釋它。 – 2010-12-22 08:04:11

爲什麼不同版本的Silverlight程序集具有相同的版本號？

回答

相關問題