为什么不同版本的Silverlight程序集具有相同的版本号？

Question

为什么不同版本的Silverlight程序集具有相同的版本号？

13

为什么不同版本的 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

- Simon

1

我一直想知道那个。我觉得肯定是我漏掉了什么。 - Ken Smith

5个回答

3

桌面版本的.NET 2.0、2.0SP1、2.0SP2、3.0、3.0SP1、3.5和3.5SP1的基类库（如System.dll）也发生了完全相同的事情，它们都有完全相同的[AssemblyVersion]，即2.0.0.0。直到.NET 4.0才将此版本提升为4.0.0.0。

程序集版本表示程序集的公共接口。对其他程序集可访问的类型成员进行重大更改需要一个新的[AssemblyVersion]。这是必要的，因为这需要使用这些类型的客户端代码重新编译。我检查了你提到的System.Core.dll版本。通过反射器导出输出来看，私有和内部类和方法发生了许多变化。但是公共的类型和方法没有变化。

不完全正确，桌面版也发生了这种情况，StrongBox类在4.0版本中获得了默认构造函数。可能的救赎是构造函数被记录为“此API支持.NET Framework基础结构，不应直接从您的代码中使用。”特别是在Silverlight中，针对4.0的应用程序永远不会意外地看到该类的3.0版本，与桌面情况不同。

- Hans Passant

这可能对Silverlight 3和Silverlight 4有意义，因为你可以认为它们是相同的运行时。但对于Windows Phone程序集来说却不是这样，因为它们显然是不同的公共API。 - Simon

我没有它来检查，但我不认为会有什么不同。只是Silverlight。 - Hans Passant

2

Silverlight 4框架没有限制使用2.0.5.0版本的System.Core。.NET 3.5框架使用了System.Web的2.0版本。然而，.NET 4框架则使用了更新的版本的System.Core。

- Rex M

我认为你没有理解重点。所有版本的Silverlight文件都是相同的，即使它们显然是不同的文件。 - Simon

0

也许他们不希望开发人员重新编译Silverlight应用程序以针对不同版本的Silverlight Framework...

- Kii

这对于Windows Phone程序集不起作用，因为如果您重新编译它们，它们将无法运行。 - Simon

-1

我认为这是开发团队忘记更改版本号并没有检查清单，但我不确定百分之百。因为没有中央编译器，所以没有自动化此任务的机制。在这个开发组中，只要用户拥有带有公钥令牌的强名称，就可以编译此代码汇编。我对这个主题的专家的完整答案很感兴趣。

- Cyber Slueth Omega

1

这些是微软发布的程序集。你肯定不认为微软的开发团队会忘记更改版本号，对吧？ - Gabe

1

在任何成熟的开发过程中，都有一个构建系统来自动化编译整个团队更改的程序集，因此在概念上有一个集中式编译器。个人开发人员不需要负责创建实际发布的程序集，这是由构建系统生成的。 - Tim Lloyd

真的吗？我以为他们使用强密钥创建了一个程序集，将强密钥添加到程序集中，并在唯一的ID下存储该强密钥。该唯一ID是公钥令牌。版本由最后编译该项目的人设置。由于您可以在单个解决方案中拥有多个项目，因此每个项目根据项目类型可能都有自己的已签名程序集。构建系统听起来很酷，我需要调查一下。感谢您提供的信息。 - Cyber Slueth Omega

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Simon Mourier · Accepted Answer

使用.NET时，对于已签名（.snk）的程序集，不更改程序集版本号的第一个原因是确保程序集的强名称保持不变。这样，不需要修改.config文件或自定义策略，任何使用对您的程序集的引用构建的客户端都能够在不抱怨的情况下加载。

默认情况下（未定义程序集重定向），如果更改版本，则程序集的强名称也将被更改，并且所有针对先前版本构建的现有程序集将无法运行。

如果从不更改版本，当然，您必须确保使用不同的类或方法签名时不会破坏这些相同的客户端。

这就是为什么大多数开发人员大部分时间 tend to keep the same version...forever（尽可能长期保持同一版本），CoreCLR（Silverlight的CLR）以及.NET CLR都适用。

在.NET CLR的情况下，他们更改版本实际上会对现有的.NET应用程序造成一些问题。有时，在.NET 4的上下文中，现有的.NET 2应用程序需要将此内容添加到.config文件中：

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

你可以查看这篇文章，它解释了.NET Framework背后的所有复杂性: .NET Framework中的版本兼容性