UWP & .net core
От: okon  
Дата: 23.08.16 06:44
Оценка:
Написано в книженции что UWP are using .net core, but also require Windows Runtime.
Не совсем я понял это, т.е. часть UWP использует .net core, но есть часть UWP которая не на .net core и использует Windows Runtime.
Или же имеется ввиду что на .net core можно написать код который зависим от Windows Runtime и UWP написан таким образом ?
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re: UWP & .net core
От: Sinix  
Дата: 23.08.16 08:24
Оценка: 45 (11) :))) :)
Здравствуйте, okon, Вы писали:

O>Написано в книженции что UWP are using .net core, but also require Windows Runtime.

O>Не совсем я понял это, т.е. часть UWP использует .net core, но есть часть UWP которая не на .net core и использует Windows Runtime.

Там связь фреймворков как в индийских сериалах.

Грубо говоря:

* WinRT .net API — смесь тяжёлого наследия SL, WP7 и полноценного .net. Сам рантайм (JIT/GC и частично BCL) — всё тот же "взрослый" .net, только собранный с другими conditional symbols, системное API — творческое переосмысление WP7. Нативную часть WinRT можно описать... не нужно описать. COM жив, просто он так пахнет, да.

* WinRT .net native preview — тулчайн для перевода managed winrt в нативный бинарник. У него тож длиннющая и весьма своеобразная родословная, не будем

Поверх всего этого были привёрнуты кросплатформенные библиотеки PCL (которые были скорее тонким троллингом, чем реально кросплатформенным кодом, ну да фиг с ним), сбоку прикостылены shared projects, а где-то в сторонке тусовались xamarin / unity и всё это дело кое-как работало с нюгетом.



Вот до этого момента всё было более-менее ок. А дальше пошла натуральная санта-барбара. Всё что ниже выпущено всего-то за два года.

* .Net Core — рефорк. Рантайм — снова взрослый .net с некоторыми нюансами, BCL — форк WinRT BCL, всё остальное изобреталось заново и наполовину не готово, на вторую половину — будет переделываться. Оставшаяся часть очень даже ничего.

* UWP .net API. Форк .net core годовалой давности с дополнительным набором библиотек, форк периодически синхронизируют с .Net Core, в ближайшем будущем форк будет заменён на сам .net core. По планам ближайшее будущее наступило этим летом, но с тулингом по-прежнему беда.

* UWP .net native — тулчайн для перевода UWP .net API app в нативный бинарник. Чтоб было бодрее, для отладочных сборок используется .net core.

Поскольку движухи всё-таки не хватало, этой весной PCL и ко были заменены на .net standard, который по сути есть творческое переосмысление Android API Levels и у которого всего-то 6 версий плюс планы на "наконец-то мы сделаем правильно aka netstandard2.0". По сравнению с 46 способами неправильно приготовить PCL — ниочём.

Всё отлично, кроме одной мелочи: сам .net core по-прежнему находится в полуразобранном виде, что тянет за собой кучу приключений как при попытке использовать сам .net core, так и в смежных проектах.
В основном мелочи типа "после обновления пакетов пустой проект перестаёт собираться", но их количество и отсутствие решений не то что в гугле, но и в issues собственно .net core раздражает неимоверно



Если теперь стало понятнее — я вам очень завидую
Re[2]: UWP & .net core
От: okon  
Дата: 23.08.16 11:11
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, okon, Вы писали:


O>>Написано в книженции что UWP are using .net core, but also require Windows Runtime.

O>>Не совсем я понял это, т.е. часть UWP использует .net core, но есть часть UWP которая не на .net core и использует Windows Runtime.

S>Там связь фреймворков как в индийских сериалах.


S>Грубо говоря:


S>* WinRT .net API — смесь тяжёлого наследия SL, WP7 и полноценного .net. Сам рантайм (JIT/GC и частично BCL) — всё тот же "взрослый" .net, только собранный с другими conditional symbols, системное API — творческое переосмысление WP7. Нативную часть WinRT можно описать... не нужно описать. COM жив, просто он так пахнет, да.


S>* WinRT .net native preview — тулчайн для перевода managed winrt в нативный бинарник. У него тож длиннющая и весьма своеобразная родословная, не будем


S>Поверх всего этого были привёрнуты кросплатформенные библиотеки PCL (которые были скорее тонким троллингом, чем реально кросплатформенным кодом, ну да фиг с ним), сбоку прикостылены shared projects, а где-то в сторонке тусовались xamarin / unity и всё это дело кое-как работало с нюгетом.




Буду задавать вопросы, а то понятно но не совсем

S>Вот до этого момента всё было более-менее ок. А дальше пошла натуральная санта-барбара. Всё что ниже выпущено всего-то за два года.


S>* .Net Core — рефорк. Рантайм — снова взрослый .net с некоторыми нюансами, BCL — форк WinRT BCL, всё остальное изобреталось заново и наполовину не готово, на вторую половину — будет переделываться. Оставшаяся часть очень даже ничего.


Т.е. .net core — форк взрослого .netа и использует рантайм взрослого дотнета ( c ньюансами ) ? А BCL у .NET Core на WinRt ? Не совсем понятно тогда как у .net core достигается кросплатформенность, ведь WinRt я так понимаю это COM в фантике .net ? И не совсем понятно зачем для базовых типов использовать COM

S>* UWP .net API. Форк .net core годовалой давности с дополнительным набором библиотек, форк периодически синхронизируют с .Net Core, в ближайшем будущем форк будет заменён на сам .net core. По планам ближайшее будущее наступило этим летом, но с тулингом по-прежнему беда.


Т.е. сначала родили .net core , потом решили добавить в него UWP, и пока пилят, в ближайшем будущем допилят, но не понятно в этом случае будет ли полноценная кросплатформенность ? будет ли отвязка от WInRT , хотя как оно отвяжется если BCL на WinRT ( возможно я не правильно понял ответ в первой части )

S>* UWP .net native — тулчайн для перевода UWP .net API app в нативный бинарник. Чтоб было бодрее, для отладочных сборок используется .net core.


Т.е. это тулза для того чтобы собрать под конкретную платформу ? Или имеется ввиду чисто под винду ( аналог ngen )


S>Поскольку движухи всё-таки не хватало, этой весной PCL и ко были заменены на .net standard, который по сути есть творческое переосмысление Android API Levels и у которого всего-то 6 версий плюс планы на "наконец-то мы сделаем правильно aka netstandard2.0". По сравнению с 46 способами неправильно приготовить PCL — ниочём.


S>Всё отлично, кроме одной мелочи: сам .net core по-прежнему находится в полуразобранном виде, что тянет за собой кучу приключений как при попытке использовать сам .net core, так и в смежных проектах.

S>В основном мелочи типа "после обновления пакетов пустой проект перестаёт собираться", но их количество и отсутствие решений не то что в гугле, но и в issues собственно .net core раздражает неимоверно


S>Если теперь стало понятнее — я вам очень завидую
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re[3]: UWP & .net core
От: Sinix  
Дата: 23.08.16 13:34
Оценка: 60 (8) :)
Здравствуйте, okon, Вы писали:

O>Т.е. .net core — форк взрослого .netа и использует рантайм взрослого дотнета ( c ньюансами ) ? А BCL у .NET Core на WinRt ? Не совсем понятно тогда как у .net core достигается кросплатформенность, ведь WinRt я так понимаю это COM в фантике .net ? И не совсем понятно зачем для базовых типов использовать COM


Не совсем так. Если совсем-совсем грубо, то исторически есть всего два рантайма дотнета от MS — .net compact (ныне всё, заменён .NET Micro Framework, вживую шансов встретить 0) и собственно взрослый дотнет. Грубо — т.к. есть непубличные форки, есть mono и тыды.

Т.е. (с некоторой натяжкой) базовые вещи практически не менялись начиная с CLR 2.0, и один и тот же код запускался на разных платформах ещё тогда. Другой вопрос — кому оно тогда надо было
Другими словами: разница между разными форками .net только в наборах доступного API и в специфичных для платформы библиотеках.


O>И не совсем понятно зачем для базовых типов использовать COM

Дальше идёт сложный момент: WinRT не имеет никакого отношения к дотнету, это отдельный набор системного API. По сути, это единственное API, которое планировалось оставить для массовых потребительских устройств. Каждый язык мог предлагать свои плюшки, но только поверх того, что уже предоставлено системой. Ближайшая аналогия — WinAPI и обычные десктопные приложения на дотнете.

Особенность WinRT в том, что он не заточен на максимум экономии любыми средствами (напомню, корни WinAPI из тех времён, когда 64 кб — это не просто много, а всё, на что можно рассчитывать). Вместо этого в приоритетах — энергоэффективность, хорошая _воспринимаемая_ производительность (perceived performance) и интеграция с языками для массового рынка (читай, js + .net + натив для игрушек и медиа).

На практике люди работают не с WinRT напрямую, а с её подмножеством для конкретного языка / фреймворка (win rt projections). На настоящий момент эти подмножества практически совпадают за исключением отдельных нюансов (к примеру, компоненты WinRT нельзя реализовать на JS, только использовать готовые на c#/c++). Из готовых тулчайнов имеем C++/CX, Managed WinRT api и WinJS для плюсов / шарпа / js соответственно. В разнообразной степени готовности есть адаптеры, позволяющие использовать WinRT API из iOS/Android/Win32 apps.

Сами внутренности WinRT документированы не больше, чем нюансы WinAPI, зато по продуманности и удобству использования публичного API WinRT всё-таки на голову поудобней. Вот сам способ реализации — забавно, да.
Понятно, что такие масштабные вещи за такой короткий срок без использования задела сделать нереально (кто сомневается — смотрим на куда менее амбициозный .Net Core. "Взять и переписать" работает, ага).

Получилось "слепила из того что было", 1.0.
* Хороший нативный API — только COM (хороший — в смысле "остальное ещё хуже"). Ок, берём, переименовываем в WinRT API.
* Приседаний с регистрацией компонентов и бедной системой типов никому не хотелось, поэтому для описания метаданных был взят формат метаданных дотнета. Берём, переименовываем в WinMD.
* То же самое — распространением. Ок, берём маркет и формат пакетов от WP7 (который в свою очередь позаимствовал формат пакетов от SL). Переименовываем .XAP в .Appx
* UI? Опять-таки, только брать из WP7, т.е. заимствуем xaml и основные идеи от WPF, но при этом выкидываем кучу вещей, ибо время не позволяет качественно реализовать всё. Одновременно и ок, и не очень, ибо шаг в сторону == или нельзя, или никто ещё не пробовал. Занимательное занятие, короч. А, да, с идеями было уже плохо, поэтому назвали просто — Windows XAML.

Напоминаю, что отношения между developer division, desktop и mobile div
  сложились как-то так

так что побочным эффектом заимствования был небольшой пипец для исходной команды (RIP SL, WPF на искусственном дыхании, MS Exspression закрыт, версия XAML 2009 так и не выпущена, CLR team начали снова шевелиться после использования дотнета в сервисах самого MS...). Погуляли на все деньги, ага.

Ну и чтоб не обидно было, противоположный лагерь тоже немножко прибило политическими решениями (там и нелюбовь времён Синофски к managed, и отношения между командами, и своеобразное отношение к разработчикам, и фейл на десктопе и последовавший мегаэпический фейл на мобильном рынке)... Где-то вот к текущему моменту winRT наконец стала тем, что задумывалось изначально — полноценной заменой WinAPI для современных консумерских операционок, от телефонов и xbox до ноутбуков. Вот только из этих устройств только приставки с ноутбуками по факту и остались.


Доп. инфа:
http://www.johndcook.com/blog/2012/04/07/winrt-projections-com/
Вступление в WinRT Revealed book (точно не вспомню, но по-моему она)
Неплохой исторический обзор.

Это если говорить про нативную часть WinRT. Ну а про managed... то же самое в принципе. Что было, то и использовали.


S>>* UWP .net API. Форк .net core годовалой давности с дополнительным набором библиотек, форк периодически синхронизируют с .Net Core, в ближайшем будущем форк будет заменён на сам .net core. По планам ближайшее будущее наступило этим летом, но с тулингом по-прежнему беда.

O>Т.е. сначала родили .net core , потом решили добавить в него UWP, и пока пилят, в ближайшем будущем допилят, но не понятно в этом случае будет ли полноценная кросплатформенность ? будет ли отвязка от WInRT , хотя как оно отвяжется если BCL на WinRT ( возможно я не правильно понял ответ в первой части )

Не так.
0. WinRT managed — вариант WinRT для дотнета. Managed-часть — отдельный форк, перетаскивает к себе свежий код из других форков. Нативная — собственно WinRT API, в Win10 переименовано в UWP API.

По кросплатформенному коду:
1. Сам рантайм на сегодня кросплатформенный и используется с некоторыми оговорками везде.
2. Базовые библиотеки — почти ок, но набор API на разных платформах не то чтобы совпадает.
3. Полноценная спецификация базовых библиотек (.net standard) появляется только сейчас.
4. Куча вещей (ресурсы, конфиги, логирование, сериализация) в кросплатформенном варианте или отсутствуют, или проще заменить сторонними библиотеками.
5. Общий тулинг, включая интеграцию со студией по факту нерабочий. Для всего, кроме собственно .net core это некритично, т.к. используются свои версии.


S>>* UWP .net native — тулчайн для перевода UWP .net API app в нативный бинарник. Чтоб было бодрее, для отладочных сборок используется .net core.

O>Т.е. это тулза для того чтобы собрать под конкретную платформу ? Или имеется ввиду чисто под винду ( аналог ngen )
Упрощая: аналог ngen, только сборка происходит не на конечной машине, а у разработчика. Доступно пока только для UWP apps.
Re[2]: UWP & .net core
От: DreamMaker  
Дата: 23.08.16 17:01
Оценка:
Здравствуйте, Sinix, Вы писали:


S>Если теперь стало понятнее — я вам очень завидую



я правильно понял мысль, что пришло время учить этот чертов юникс?
In P=NP we trust.
Re[3]: UWP & .net core
От: Sinix  
Дата: 23.08.16 17:42
Оценка:
Здравствуйте, DreamMaker, Вы писали:

S>>Если теперь стало понятнее — я вам очень завидую

DM>я правильно понял мысль, что пришло время учить этот чертов юникс?
Если жизнь кажется слишком скучной — однозначно да.

На самом деле всё не так страшно, всего-то комбинация из избытка оптимизма и попытки выпустить новую платформу (.net core, как ни крути — это оно) в продакшн до релиза. А если вспомнить Silverlight 1.0, где шарпа вообще не было, а создание кнопок выглядело вот так (оччень рекомендую, они это серьёзно, да), то текущая ситуация даже на мелкий насморк не тянет.
Re[4]: UWP & .net core
От: push  
Дата: 23.08.16 22:17
Оценка:
Я так и не понял — стоит смотреть UPW и .NET core? Или это всё еще технологии с очень сомнительным будущем?
Re[5]: UWP & .net core
От: okon  
Дата: 23.08.16 23:11
Оценка:
Здравствуйте, push, Вы писали:


P>Я так и не понял — стоит смотреть UPW и .NET core? Или это всё еще технологии с очень сомнительным будущем?

Я так понимаю сейчас высокая "волатильность" и сложно сказать куда это все выйдет, так же как что будет с курсом рубля через год.
Пациента я так понимаю сейчас стараются вытащить, было бы хорошо если получится. Но есть у меня ощущение
Автор: okon
Дата: 23.08.16
что скоро все это станет совсем не нужно.
”Жить стало лучше... но противнее. Люди которые ставят точку после слова лучше становятся сторонниками Путина, наши же сторонники делают акцент на слове противнее ( ложь, воровство, лицемерие, вражда )." (с) Борис Немцов
Re[5]: UWP & .net core
От: Sinix  
Дата: 24.08.16 06:51
Оценка:
Здравствуйте, push, Вы писали:

P>Я так и не понял — стоит смотреть UPW и .NET core? Или это всё еще технологии с очень сомнительным будущем?


C UWP с технической стороны всё ок. Есть проблемы с рынком (а где их нет?) и с рекомендациями по дизайну приложений — в win8 было дофигищща красивых идей именно для планшетов, от которых в десятке не осталось практически ничего, официальные приложения даже не стараются изобразить общий стиль.

С .Net core всё в принципе тоже ок. Рантайм — нормально, базовые библиотеки — почти нормально, с инструментальной обвязкой и с совместимостью... для релиза это фейл. Но тут надо учитывать, что при старом добром подходе к разработке текущее состояние называлось бы CTP, даже не бетой, и вопросов никаких не было бы.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.