Why do different versions of Silverlight assemblies have the same version number?

Question

Why do different versions of Silverlight assemblies have the same version number?

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 

While standard .net has different version numbers

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

With .NET, for a signed (.snk) assembly, the very first reason why you would not change an assembly version number is to ensure the assembly's strong name will stay the same. This way, without messing with .config files or custom policies, any client that was build with a reference to your assembly will still be able to load without complaining.

By default (without defining assemblies redirections), if you change the version, your assembly's strong name will be changed as well, and all existing assemblies build against the previous version will fail to run.

If you never change the version, of course, you'll have to make sure you don't break these same client with different classes or methods signatures.

That's the reason why most of the time, developers tend to keep the same version ... forever, when it's possible, and this is true for the CoreCLR (Silverlight's CLR) as well as the .NET CLR.

In the case of the .NET CLR though, the fact that they changed the version actually poses some problems for existing .NET apps. Sometimes, existing .NET 2 applications need to add this to the .config file in a .NET 4 context:

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

You can look at this article that explains how complex all this can be behind the scene: Version Compatibility in the .NET Framework

Answer 2

The exact same thing happened with the base class libraries (like System.dll) for the desktop versions of .NET 2.0, 2.0SP1, 2.0SP2, 3.0, 3.0SP1, 3.5 and 3.5SP1, they all have the exact same [AssemblyVersion], 2.0.0.0. Not until .NET 4.0 did this version get bumped to 4.0.0.0

The assembly version represents the public interface of an assembly. A breaking change in the types members that are accessible to other assemblies requires a new [AssemblyVersion]. Necessarily so, because that requires client code that uses these types to be recompiled. I checked for the System.Core.dll versions you mentioned. Bit of a painful slog through the Reflector export output for the assembly. Plenty of changes in the private and internal classes and methods. But not the public ones, the same types and methods.

Not entirely true, and this happened in the desktop version as well, the StrongBox class acquired a default constructor in version 4.0. Saving grace perhaps is that the constructor is documented as "This API supports the .NET Framework infrastructure and is not intended to be used directly from your code." And that specifically in Silverlight an app that targets 4.0 is never going to see the 3.0 version of that class by accident, unlike the desktop case.