Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

.NET 4.5 — обновление на месте .NET 4.0

Anna | 17.06.2014 | нет комментариев
Совместно с бета версиями VS 2011 и Windows 8 многие люди будут устанавливать, и разбираться с .NET 4.5. В .NET 4.5 добавлено много новых усовершенствований, которые являются довольно прозрачными, но значимо осознать, как с точки зрения CLR она работает на вашей машине.

Когда .NET 4.5 устанавливается она, реально, заменяет .NET 4.0 на вашей машине. .NET 4.0 перезаписывается новой версией .NET 4.5, что в соответствии со словами Microsoft гарантирует 100%-ую совместимость. 100% совместимость звучит симпатично, но все мы знаем, что добиться такого итога довольно трудно. Но есть вещь значительно больше увлекательная, чем обратная совместимость, которая делает обстановку с разворачиванием .NET 4.5 неудобной в лучшем и запутанной в худшем случае.

Что значит обновление на месте?

Когда Вы устанавливаете .NET 4.5 ваши сборки из .NET 4.0 в папке Windows.NET FrameworkV4.0.30319 перезаписываются новым комплектом. В выводе Вы остаетесь с перезаписанными сборками, а так же с кучей новых (скажем, сборка System.Net.Http). Следующее изображение показывает сборку System.dll для .NET 4.5 (слева) и для .NET 4.0 (справа):

Видимо, что это различные файлы с различными размерами (увлекательно, что версия .NET 4.5 поменьше размером).

Это еще не все. Если во время выполнения приложения, с установленной .NET 4.5, Вы обратитесь к свойству Environment.Version, то все еще получите 4.0.30319.

Если вы откроете окно свойств сборки System.dll в .NET 4.5 Вы так же увидите

Обратите внимание, что версия файла по-бывшему 4.0.xxx.

Разница в номере компоновки: в .NET 4.0 он равен 261, в то время как в нынешней бета версии .NET 4.5 он равен 17379. Я думаю, Вы можете применять номер компоновки, Дабы определить версию .NET: если он огромнее чем 17000, то это .NET 4.5, впрочем, это не дюже прекрасное решение согласитесь.

Не существует простого либо явственного метода, Дабы определить какая из версий .NET 4.5 либо .NET 4.0 применяется, так как для приложения они являются идентичными.

Компилировать для .NET 4.5, а запускать на .NET 4.0 мысль не из отличных

Вы можете компилировать приложение под .NET 4.5 и запускать его под .NET 4.0 до тех пор, пока вы не выходите за рамки функционала доступного только в .NET 4.0. В данный момент приложение легко упадет с оплошностью. Скажем, ваш код в основном использует вероятности .NET 4.0, но есть несколько мест, велико спрятанных в приложении, в которых применяются новые вероятности .NET 4.5, скажем, async/await. .NET с радостью запустит ваше приложение и исполнит удачно каждый код, до тех пор, пока не встретит код использующий вероятности .NET 4.5, а после этого удачно упадет. Какая веселье!

Вы безусловно можете запускать приложения, написанные для .NET 4.0 на .NET 4.5 и это должно трудиться без специальных причуд.

Определение версий

Если вы пишете приложение для .NET 4.5, у Вас есть определенный контроль, над его выполнением, применяя конфигурационный файл. Вы можете указать, что приложению нужна .NET 4.5, скажем, так:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework, Version=v4.5" />
  </startup>
</configuration>

Это делается для того, Дабы приложение при запуске не на .NET 4.5 известило об ошибке, взамен падения во время выполнения.

Также веб-приложения на .NET 4.5 могут применять качество targetFramework для достижения схожих итогов.

<configuration>
  <system.web>
    <compilation debug="true"
                 strict="false"
                 explicit="true"
                 targetFramework="4.5" />
  </system.web>
</configuration>

Это отлично работает для отдельных настольных и веб приложений, но нет никакого метода для сборок, добавляемых в план. Для плана на .NET 4.0 сборка .NET 4.5 выглядит, как и любая иная .NET 4.0 сборка.

Для разработчиков, исключительно разработчиков компонентов это исключительно проблематично, от того что нет метода разрешающего определить версию .NET, так как качество Environment.Version возвращает 4.

Дальнейший код выводит

void  Main()
{
    Environment.Version.ToString().Dump();
    Environment.Version.Build.Dump();
    Environment.Version.Revision.Dump();
    Environment.Version.Major.Dump();    
}

на .NET 4.0
4.0.30319.269
30319
269
4

на .NET 4.5
4.0.30319.17379
30319
17379
4

Достаточно, схоже, нет? Подметим, впрочем, что номер ревизии огромнее в .NET 4.5 — 17379, в то время как в .NET 4.0 — 261. Если вы подлинно хотите знать, что вы используете .NET 4.5 либо .NET 4.0 вы можете применять дальнейший код:

public static bool IsDotNet45()
{
    return Environment.Version.Major == 4 && Environment.Version.Revision > 17000;
}

2-й метод заключается в попытке выявления некоторого типа добавленного в .NET 4.5 с поддержкой рефлексии.

public static bool IsNet45OrNewer()
{
    // Класс "ReflectionContext" доступен начиная с .NET 4.5.
    return Type.GetType("System.Reflection.ReflectionContext", false) != null;
}

Одним из превосходств данного подхода является вероятность применения в больше поздних версиях .NET.

Тем не менее, довольно показательно, что нам доводится прибегать к такого рода уловкам, Дабы легко узнать совместимость версий.

Отличие с .NET 3.0 / 3.5

Учтите, что это обновление на месте крепко отличается от обновления .NET 2.0 до .NET 3.0 / 3.5 (так же было на месте), которые трудились на CLR 2-й версии. Обе 3.x версии были легко библиотечными усовершенствованиями поверх ядра .NET 2.0. Обе версии трудились под управлением .NET 2.0, тот, что не был изменен на протяжении каждого цикла 3.x. В свою очередь, обновление под номером 4.5 всецело заменяет .NET 4.0 оставляя фактический номер версии v4.0.30319.

Когда вы создаете новейший план в VS 2011, вы все еще можете предпочесть версию платформы .NET 4.0 либо .NET 4.5. Но реально вы ссылаетесь на один и тот же комплект сборок самостоятельно от выбранной вами версии. Разница заключается в том, что при компилировании под .NET 4.0 компилятор дает лишь подмножество вероятностей доступных в NET 4.0, но при компилировании под .NET 4.5 вы можете применять всю функциональность. Это совсем не обозначает, что вы можете применять VS 2010 для разработки приложений под .NET 4.5.

Отличные новости — дрянные новости

Microsoft усердствует экспериментировать всеми допустимыми методами разворачивания новых версий .NET. Не существует 2-х обновлений, которые были бы идентичными. Безусловно полное обновление (такое как .NET 2.0, 4.0) имеет свои недочеты, но делать обновление на месте и при этом не обеспечивать даже метода определения нынешней версии .NET не вовсе верно, даже по эталонам Microsoft. Исключительно рассматривая, что .NET 4.5 является довольно огромным обновлением со всеми async-ами. Множество API использующее IO было обновлено для поддержки async-ов, что значительно повлияло на существующее API. Что еще дрянней .NET 4.5 будет поставляться совместно с Windows 8, так что будет с нами в течение еще долгого времени, если безусловно Microsoft не примет, наконец, решение об обновлении версии .NET в рамках обновления системы. Верно так же было с Vista, которая поставлялась с промежуточной версией .NET 3.0, которая была стремительно заменена на больше практичную и долгоживущую .NET 3.5. Людям хватило задач с запутанной обстановкой с 3.x версиями, которые трудились реально на .NET 2.0. Я даже не могу сосчитать число заданных вопросов о том, что люди не могут обнаружить .NET 3.5 в диалоговом окне IIS. Тоже самое может случиться с .NET 4.5. Отлично когда мы знаем метод обновления до версии 4.5, но менеджеры не до конца знакомые с .NET вряд ли осознают эти нюансы, и в финальном результате будут путаться какая версия .NET установлена.

Мне сложно увидеть преобладание в таком методе обновления, я даже не видел ясного объяснения, отчего был выбран именно такой подход. Безусловно, при таком подходе существующие привязки к сборкам не ломаются, так что приложение может оставаться работающим позже обновления. Я думаю, это может оказаться пригодным для некоторых подрядчиков компонентов. А если серьезно, вы подлинно собираетесь смешивать .NET 4.0 и .NET 4.5 (не перекомпилировав приложение), а после этого всё скрупулезно протестировать, Дабы удостовериться что все работает? Перекомпиляция не кажется чем-то серьезным в свете прозрачного обновления версии.

Знали ли вы о таком разворачивании .NET 4.5?

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Проголосовало 23 человека. Воздержалось 13 человек.

 

 Источник: programmingmaster.ru
Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB