Question

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

Answer 1

对于.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

Answer 2

没有什么能阻止Silverlight 4框架使用2.0.5.0版本的System.Core。 .NET 3.5框架随System.Web 2.0版一起提供。但是，.NET 4框架附带了较新版本的System.Core。

Answer 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

程序集版本代表程序集的 public 接口。其他程序集可访问的类型成员的重大更改需要新的[AssemblyVersion]。必然如此，因为这需要重新编译使用这些类型的客户端代码。我检查了你提到的System.Core.dll版本。通过程序集的Reflector导出输出有点痛苦。私人和内部类和方法的大量变化。但是不是公共的，相同的类型和方法。

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

Answer 4

我认为开发团队忘记更改版本号而没有核对清单，但我不是百分百肯定。没有自动执行此任务的机制b / c没有中央编译器。只要具有公钥标记的强名称，此开发组中的每个用户都可以编译此代码程序集。我对这个主题专家的完整答案感兴趣。

Answer 5

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

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

5 个答案: