Почему разные версии Silverlight имеют одинаковый номер версии?

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

Ответ 5

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