.NET Core Подробности — достаточно ли?


Microsoft только что предоставила некоторые дополнительные сведения о .NET Core — недавно созданном ею проекте с открытым исходным кодом. Есть хорошие и плохие новости, но в краткосрочной перспективе, возможно, еще больше плохих.

В длинном и подробном сообщении в блоге раскрывается природа .NET Core. Однако, хотя Immo Landwerth предоставляет много деталей, разобраться в них непросто.
Прежде всего объясняется древняя история разветвления .NET. Если вы не пережили этот опыт, .NET в настоящее время поставляется в нескольких вариантах, которые имеют ряд несовместимостей. Возможно, больше всего раздражало разделение рабочего стола / Silverlight, но поскольку Silverlight больше нет, это просто память.
Сохраняющиеся важные расщепления показаны на диаграмме:

Не все на этой диаграмме имеет смысл. Например, приложения Магазина Windows не являются приложениями .NET, поскольку они работают под WinRT. Но давайте возьмем эту диаграмму больше как изложение проблемы, которую пытается решить Microsoft.
Первой попыткой решения проблемы было введение переносимых библиотек классов. По сути, это были оболочки для различных версий кода — идея не лучшая, но она позволила Microsoft изобрести универсальные приложения.
Отойдя на мгновение от ситуации, вы не можете не спросить, как все попало в эту ситуацию. Когда был представлен .NET, он был связан с ОС и мог считаться частью ОС. Приложения использовали базовый фреймворк, не принося его с собой. Были и есть проблемы с версией, но в основном это было улучшение по сравнению с адом DLL.
Похоже, что момент прорыва для Microsoft наступил, когда стало известно, что NuGet используется для распространения обновлений фреймворка как части вашего приложения. Идея центральной системы .NET стала выглядеть менее привлекательной, чем локальное объединение того, что было необходимо для каждого приложения.
Теперь введите .NET Core:
«.NET Core — это модульная реализация, которая может использоваться в самых разных вертикалях, масштабируясь от центра обработки данных до сенсорных устройств, доступна как открытый исходный код и поддерживается Microsoft в Windows, Linux и Mac OSX».
Это желаемое за действительное, поскольку .NET Core на самом деле не существует. Все, что Microsoft сделала, — это запустила проект с открытым исходным кодом с целью создания чего-то, что отвечает всем требованиям.
Ключом к созданию этого нового мира является .NET Native. Это возвращает нас к технологии, напоминающей редактор ссылок. Он объединяет фреймворк с приложением, а затем удаляет неиспользуемые модули, а затем генерирует собственный код.
«.NET Core — это, по сути, ответвление NET Framework, реализация которого также оптимизирована с учетом соображений факторинга. Несмотря на то, что сценарии .NET Native (сенсорные устройства) и ASP.NET 5 (веб-разработка на стороне сервера) сильно отличаются, мы смогли предоставить единую библиотеку базовых классов (BCL) «.
Это не так удивительно, как кажется, поскольку BCL на самом деле не состоит из классов, которые в первую очередь должны зависеть от платформы.
На следующей диаграмме показана структура .NET Core:

Эта диаграмма также вызывает много вопросов. Что CoreCLR делает рядом с Native Runtime? Предположительно, это представляет собой выбор среды выполнения, которая преобразуется для взаимодействия с Unified BCL с помощью уровня адаптации среды выполнения — что делает что? Почему показаны только приложения Магазина Windows, то есть приложения WinRT и приложения ASP.NET 5? Что происходит с настольными компьютерами и ASP.NET 4? Где Windows Phone?
Кажется, это обычная проблема со схемами, относящимися к .NET Core — пропадают технологии!
Намного позже приложения Windows Store и Windows Phone упоминаются как подмножества .NET Core, и, следовательно, новые классы BCL будут работать для них обоих.
Помимо того факта, что BCL будет одним набором классов для разных сред, что, вероятно, должно было быть с самого начала, все это кажется расплывчатым.
Одна вещь, которая кажется очевидной, — это переход от централизованного предоставления инфраструктуры к использованию NuGet для доставки пользовательских пакетов. Ключевой частью информации, по-видимому, является
«Для уровня BCL мы будем иметь отношение 1 к 1 между сборками и пакетами NuGet».
Это говорит о том, что для других уровней отношения будут отличаться от 1 к 1. Итак, в этом случае NuGet должен будет предоставить правильный пакет в зависимости от развертывания?
Будет использоваться семантическое управление версиями — что снова поднимает вопрос, почему оно еще не использовалось?
Ключевая идея:
«Конечно, некоторые компоненты, такие как файловая система, требуют разных реализаций. Модель развертывания NuGet позволяет нам абстрагироваться от этих различий. У нас может быть один пакет NuGet, который предоставляет несколько реализаций, по одной для каждой среды. Однако важная частично в том, что это деталь реализации этого компонента. Все потребители видят унифицированный API, который работает на всех платформах ».
Что ж, это хорошо, но это не ракетостроение. Когда впервые появился .NET, идея заключалась в том, что он предоставит независимый от ОС API, в который вы можете писать. Тот факт, что он распался на несовместимые API, полностью виноват Microsoft и в основном был вызван внутренней политикой. Технической необходимости во фрагментировании API никогда не было, хотя могли быть причины для фрагментации реализаций.
Сообщение в блоге заканчивается новостью о том, что работа над старомодной .NET будет продолжена, и мы можем рассчитывать на Framework 4.6, но не как на открытый исходный код.
Что касается моно:
«Mono жив и здоров с большой экосистемой на вершине. Вот почему, независимо от .NET Core, мы также выпустили части эталонного исходного кода .NET Framework на GitHub под лицензией с открытым исходным кодом. Это было сделано для того, чтобы позволить сообществу Mono чтобы закрыть пробелы между .NET Framework и Mono, используя один и тот же код. Однако из-за сложности .NET Framework мы не настроены для запуска его как проекта с открытым исходным кодом на GitHub. В частности, мы не может принимать запросы на вытягивание для него «.
Итак, теперь есть три форка .NET — .NET Framework, Mono и .NET Core. Было бы гораздо более впечатляюще, если бы Microsoft имела открытый исходный код .NET в качестве текущего проекта — не говоря уже о Silverlight, Windows Forms, WPF и так далее …
Сообщение в блоге содержит пародию на одну из самых известных работ xkcd, но я думаю, что это может просто вернуться, чтобы преследовать .NET Core:

Трудно сказать, сколько времени нам придется ждать появления .NET Core и какое влияние это окажет. Этот проект, по-видимому, необходим в основном для того, чтобы прояснить беспорядок, который Microsoft сделала с .NET Framework. Единственной действительно новой идеей, похоже, является развертывание «локально для приложения», что означает переход от общих библиотек к коду, который привязан к каждому приложению. Что ж, в большинстве случаев память и память больше не проблема, не так ли?
Оглядываясь назад на историю, вы не можете не думать, что если мы хотим, чтобы это был унифицированный API для кодирования, то, возможно, унифицированная Windows могла бы быть хорошей идеей — это то, что у нас было с Silverlight на рабочем столе, в браузере и Windows Phone. .NET Framework начиналась как унифицированный API. Для тех, кто помнит, для чего .NET должен был быть решением, очень грустно, что мы снова обойдем этот цикл.
Нам нужна унифицированная Windows на всех устройствах, тогда фреймворки будут унифицированы, по крайней мере, в Windows по умолчанию.
Хорошо, что Microsoft пытается что-то сделать с прошлыми ошибками и возрождает .NET в достаточной степени, чтобы те, кто цепляется за эту технологию, проявили энтузиазм. Достаточно ли этого видения, чтобы вернуть к нему любого, кто покинул загон?
Я серьезно в этом сомневаюсь на данный момент.

Больше информации
Представляем .NET Core
Статьи по Теме
Не выгружать .NET — метод Microsoft
Сброс .NET — безумие Microsoft
Microsoft Open Sources .NET?
.NET становится открытым исходным кодом
Полная версия Visual Studio теперь бесплатна
WPF жив!
Microsoft и Xamarin совместно работают над внедрением встроенных iOS и Android в Visual Studio
Microsoft против разработчиков
Windows 8 — разрушитель рабочего стола
Событие вымирания Microsoft
Война с Microsoft — управляемое против неуправляемого
Был ли .NET ошибкой?
Silverlight мертв, да здравствует Silverlight?

Чтобы получать информацию о новых статьях на I Programmer, установите панель инструментов I Programmer, подпишитесь на RSS-канал, подпишитесь на нас в Twitter, Facebook, Google+ или Linkedin или подпишитесь на нашу еженедельную новостную рассылку.

Комментарии
Оставьте комментарий или просмотрите существующие комментарии с помощью Disqus
или отправьте свой комментарий по адресу: comments@i-programmer.info


Добавить комментарий