Почему разные версии 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
5 ответов

С .NET для подписанной сборки (.snk) самая первая причина, по которой вы не измените номер версии сборки, - обеспечить, чтобы сильное имя сборки оставалось прежним. Таким образом, без использования файлов .config или настраиваемых политик любой клиент, который был создан со ссылкой на вашу сборку, по-прежнему сможет загружать без жалоб.

По умолчанию (без определения перенаправления сборок), если вы измените версию, ваше сильное имя сборки также будет изменено, а все существующие сборки, созданные против предыдущей версии, не будут выполняться.

Если вы никогда не меняете версию, конечно, вам нужно будет убедиться, что вы не нарушаете этот же клиент с помощью разных классов или методов подписи.

Вот почему большую часть времени разработчики, как правило, придерживаются той же версии... навсегда, когда это возможно, и это верно для CoreCLR (Silverlight CLR), а также .NET CLR.

Однако в случае .NET CLR факт, что они изменили версию, фактически создает некоторые проблемы для существующих приложений .NET. Иногда существующие приложения .NET 2 необходимо добавить в файл .config в контексте .NET 4:

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

Вы можете посмотреть на эту статью, которая объясняет, насколько сложным все это может быть за сценой: Совместимость версий в .NET Framework


Ничего не мешает платформе Silverlight 4 использовать версию System.Core 2.0.5.0. Структура .NET 3.5 поставляется с версией 2.0 System.Web. Однако платформа .NET 4 поставляется с более новой версией System.Core.


То же самое произошло с библиотеками базового класса (например, 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

Версия сборки представляет собой открытый интерфейс сборки. Разрывное изменение членов типов, доступных для других сборок, требует новой [AssemblyVersion]. Обязательно, потому что для этого требуется, чтобы клиентский код, который использует эти типы, перекомпилировался. Я проверил версии, описанные в System.Core.dll. Немного болезненного пробоя через выходной поток Reflector для сборки. Множество изменений в частных и внутренних классах и методах. Но не публичные, те же типы и методы.

Не совсем верно, и это произошло и в настольной версии, класс StrongBox приобрел конструктор по умолчанию в версии 4.0. Сохранение благодати, возможно, состоит в том, что конструктор документируется как "Этот API поддерживает инфраструктуру .NET Framework и не предназначен для непосредственного использования из вашего кода". И именно в Silverlight приложение, которое нацелено на 4.0, никогда не увидит версию 3.0 этого класса случайно, в отличие от настольного случая.


Возможно, они не хотят, чтобы разработчик перекомпилировал приложение Silverlight для целевой версии Sliverlight Framework...


Я думаю, что команда разработчиков забыла изменить номера версий и не иметь контрольный список, но я не уверен на 100%. Нет механизма, который автоматизирует эту задачу b/c, нет центрального компилятора. Каждый пользователь этой группы разработчиков может скомпилировать эту сборку кода, если у них есть сильное имя с токеном открытого ключа. Меня интересует полный ответ эксперта по этому вопросу.

licensed under cc by-sa 3.0 with attribution.