Почему на машине с установленным.NET 4 не может быть запущена исполняемая программа, нацеленная на.NET 4.5, если они используют одну и ту же версию CLR?

Question

На странице Microsoft Common Language Runtime (CLR) говорится, что как.Net Framework 4, так и 4.5 используют версию CLR 4.

Однако на этой странице ( версии и зависимости.NET Framework) написано: ".Net Framework версии 4.5 Включена обновленная версия CLR 4".

Также пишет:

" Исполняемый файл, нацеленный на.NET Framework 4.5.1, будет заблокирован для запуска на компьютере, на котором установлен только.NET Framework 4.5, и пользователю будет предложено установить.NET Framework 4.5.1. Кроме того, сборки.NET Framework 4.5.1 не следует вызывать из приложения.NET Framework 4.5. '

ВОПРОС: Если во всех версиях Net Framework 4, 4.5 и 4.5.1 управляемый код выполняется на одной и той же версии CLR, то есть 4, почему я не могу запустить исполняемый файл, предназначенный для.Net Framework 4.5, на компьютере, на котором установлена ​​только.Net 4.0?

(Разве компиляторы не создают IL, предназначенный для CLR версии 4, в конце концов, независимо от того, нацелен ли вы на.NET framework 4, 4.5 или 4.5.1?)

Answer 1

Да, версия CLR такая же, все еще v4.0.30319. Сильно отсталым отрывом стали библиотеки классов.NET Framework. Изменения, вызванные интеграцией поддержки WinRT (Store store) в среду. Несколько типов были перемещены из одной сборки в другую, наиболее заметными являются ExtensionAttribute и ICommand. Необходимость небольших реализаций.NET на мобильных устройствах сыграла важную роль. System.Core и PresentationFramework не маленькие.

Это довольно большое дело, сборка, в которой объявлен тип, является частью идентификатора типа.NET. Или, другими словами, тип.NET, имеющий одно и то же имя пространства имен и имя типа, никогда не совместим с типом с таким же полным именем, который был получен из другой сборки.

Это вообще было возможно благодаря нововведениям, появившимся в.NET 4.0. Начиная с атрибута [TypeForwardedTo], который используется для перемещения типа. И специально созданные эталонные сборки в c:\program files\ эталонные сборки. Особенность в том, что они содержат только метаданные и не соответствуют напрямую фактическим сборкам, установленным в GAC, которые ваша программа будет использовать во время выполнения.

Это иногда идет не так, как надо, в очень трудных для диагностики способах, вызванных использованием неправильных эталонных сборок. К сожалению, Microsoft сохранила традиционные эталонные сборки в c:\windows\microsoft.net\framework. Проекты, которые используют их, терпят неудачу довольно жалким способом.

Так что это просто не может работать, программа, нацеленная на.NET 4.5, будет искать неправильные сборки 4.0 GAC для таких типов, как ExtensionAttribute и ICommand. И потерпеть неудачу с совершенно не поддающимся диагностике исключением TypeLoadException. Соответственно, атрибут [TargetFramework] проверяется первым, чтобы потерпеть неудачу при попытке запустить программу как можно раньше.

Answer 2

Microsoft,

Каждая сборка, статическая или динамическая, содержит набор данных, который описывает, как элементы в сборке связаны друг с другом. Манифест сборки содержит эти метаданные сборки. Сборочный манифест. Этот манифест содержит информацию о CLR сборки этого исполняемого файла, и во время выполнения exe/dll .net CLR пытается найти ту же версию CLR. Увидеть изображение, Сборка по версии 3.5 и Сборка на 4.0.