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


VD>Они обещают стандартизовать и тэги XAML-а. Но все равно они будут компилироваться под разные платформы, по этому ты не сможешь получить общего бинарника под них.

Ак как же Xamarin.Forms?
S>>и писать сразу один код для UWP и WPF по аналогии с Ксамарин, где в одном проекте ты делаешь приложение для IOS,Android,Tizen и UWP

VD>Кзамарин тебе предоставляет общий тулинг для этого. UWP и WPF — это разные платформы. Общие теги — это еще не все. Там море нюансов, которые тебе придется учитывать.

В чем проблема сделать общий тулингтдля WPF и UWP?
VD>Вот всем было бы лучше, если МС тупо выбросил все свои Кзамарины с UWP и тупо реализовал дотнет вместе с библиотеками на всех девайсах. Тогда бы не было чихарды с проектными файлами, всеми этими нюансами и т.п. И можно было бы действительно писать единый код.
Для этого и сжелан Net Standard 2, но все равно нужно использовать нативные контролы

VD>Хотя единый код для десктопа и телефона — это скорее красивая сказка. Бизнес логику и сейчас не трудно обобщить. А гуй у ни будет разный. Причем концептуально разный.

S>>То есть у тебя будет возможность сразу делать код для UWP и WPF, но ты его не будешь использовать?

VD>Да не будет этого. Плюс, конечно не буду. Я выберу WPF для десктопа. И Кзамарин для девайсов. А UWP пошлю на фиг. Ну, разве что кто-то потребует (и оплатит) разработку под виндофоны.
То есть бесплатная возможность создать приложение для UWP тебя не интересует?
Я как владелец десятки выберу UWP приложения, чем ресурсоемкий и небезопасный WPF.

VD>МС это уже понял. От того и приоритеты у него поменялись.

VD>Посмотри тренды по запросам:
VD>https://trends.google.ru/trends/explore?cat=5&q=xamarin,UWP,WPF,ASP.NET,%2Fm%2F0j45p7w

Нще раз это все до выхода NS2 и XS2. К новому году все изменится.
S>>А потом меня обвиняешь в бреде.

VD>Я не обвиняю, я констатирую факт.
Ну конечно, один ты у нас умный с с MS стою в сторонке.
VD>>>Тебе говорят, что NetStandard — это всего лишь стандарт. Он не позволит заработать UWP-приложениям под Core. Это всего лишь подмножество АПИ которое хотят сделать доступным в назных реализациях.

S>> Это не просто АПИ это еще и реализация

VD>Хрен там! NetStandard — это именно подмножество АПИ. Понятно, что дотнетные сборки можно использовать где угодно. Вопрос только в том, что за либы ты сможешь зедайствовать. Вот в Моно, например, не было полноценого МСБилда. И хоть ты обосрись, но проект в Моно должен быть другим. И XAML-а там тоже не было. UWP — это АПИ разработки для 10-й винды. Там куча нюансов связанных с их магазином и всякими политиками безопасности. Всего этого никогда не будет в NetStandard.

NetStandard это не монолит, там кстати есть пакеты только для Windows

Существуют и «серые области», наподобие System.Drawing, которые с одной стороны могут иметь смысл на всех платформах, с другой слишком завязаны на Windows с его GDI+. Подробности: github.com/dotnet/corefx/issues/20325.

Так, что от условной компиляции не исбавиться.
VD>То же XAML не будет одинаковым просто потому, что в UWP не реализовали всех наворотов из WPF. Набор базовых тегов они возможно и устаканят. Но не более того.
Их реализуют. Во всяком случае надеюсь. В этом то и смысл.
VD>Ну, и надо понимать, что WPF и UWP тупо дублируют друг друга. Все разница в UWP в том, что UWP-приложение можно тупо запихнуть в их магазин и продать.
Ну вот и я говорю, я возьму приложение UWP вместо WPF

S>>Вот только несколько диффов

S>>https://github.com/dotnet/standard/blob/master/docs/versions/netstandard2.0.md

VD>Ну, и где ты в списке пространств имен Window узрел?

VD>Ой, все! (ц) Тебе хоть кол на голове теши, ты будешь продолжать нести бред.

S>> А UWP и так работает под .Net Core в Debug режиме. Библиотеки у них одни.

VD>Что ты несешь?! А...

Влад ты, что мои ссыки не читаешь?
Еще раз специально для тебя

Читаем
В чем разница между NetFramework и NetCore

https://msdn.microsoft.com/ru-ru/magazine/mt590967.aspx

Наконец, .NET Core — это нижележащая инфраструктура, от которой зависит .NET Native. Когда проектировали .NET Native, стало понятно, что .NET Framework не подойдет в качестве фундамента для библиотек классов этой инфраструктуры. Дело в том, что .NET Native статически связывает инфраструктуру с приложением, а затем удаляет все лишнее, что не нужно приложению. (Здесь я сильно упрощаю общую картину, но идею вы уловили. Подробнее на эту тему см. «Inside .NET Native» по ссылке bit.ly/1UR7ChW.)
Традиционная реализация .NET Framework не предусматривает разбиения на модули, поэтому компоновщик (linker) не может включить в приложение лишь ту часть инфраструктуры, которая нужна приложению. Но .NET Core, по сути, является ответвлением .NET Framework, реализация которой оптимизирована с учетом модульности. Другое преимущество этой реализации — возможность поставлять .NET Core Framework как набор NuGet-пакетов, что позволяет вам обновлять индивидуальные классы вне самой .NET Framework. Однако, прежде чем двигаться дальше, давайте обсудим изменения в NuGet.

Скомпилировав и запустив программу в конфигурации Debug, вы выполняете код Intermediate Language (IL) в CoreCLR, упакованной вместе с приложением. Системные сборки .NET упаковываются наряду с кодом вашего приложения, и это приложение получает зависимость от пакета Microsoft.NET.CoreRuntime (CoreCLR). Если инфраструктура CoreCLR отсутствует на устройстве, где вы тестируете, Visual Studio автоматически обнаружит это и установит ее до развертывания вашего приложения.
Это означает, что получаете максимум удобств при разработке: быструю компиляцию и установку, богатые средства отладки и диагностики и весь инструментарий, к которому вы привыкли при .NET-разработке.
Когда вы переключаетесь в режим Release, ваше приложение по умолчанию использует цепочку инструментария .NET Native. Поскольку пакет компилируется в неуправляемый двоичный код, в этом пакете не нужны библиотеки .NET Framework. Более того, пакет зависим от новейшей установленной версии исполняющей среды .NET Native в противоположность пакету CoreCLR. Исполняющая среда .NET Native на устройстве будет всегда совместима с пакетом вашего приложения.

Читай выделенное. И разберись с предметной областью.
VD>Люди же будут вообще все больше и больше уходить в веб. Трах со всеми этими платформами никому не нужен. Десктопные приложения, конечно, останутся. Но их количество будет сокращаться. UWP станет нужным только после победы виндофонов. Кзамарин будет востребован просто потому, что многие хотя иметь клинтов для мобил.

VD>МС же делает очередные поступательные шаги вместо то того, чтобы еще 15 лет назад не делать глупостей и не превращать дотнет в виндовую яву.

VD>Правильным подходом было бы реализовать в Core все интерфейсы нужные для создания программ включая WPF. Выкинуть к чертям UWP и Кзамарин, а для Андроида и айОС реализовать полноценный фреймворк с поддержкой AOT-компиляции.

VD>Тогда все эти NetStandard-ы были бы не нужны, а поддержка всяких UWP и Виндовс сводилась бы к паре небольших библиотечек. Собственно именно это и называется Явой. Именно в Яве МС нашел фатальный недостаток на рубеже веков. И именно желание сделать привязанную к винде яву и породила всю эту котовасию.
ни как раз к этому и идут, только постепенно. А тебе нужно сразу и сейчас
Есть Net Natie для UWP и IOS, есть NetStandа насчет пару библитечек посмотри на свою нитру и оцени сколько в ней кода

Ну и на посдедок о развитии xamarin.Forms 3 опять гугл переводчик
https://visualstudiomagazine.com/articles/2017/08/01/xamarinforms3_0.aspx

Одна вещь, о которой вы могли бы попросить, — это возможность расширения ваших приложений на другие платформы. Xamarin.Forms уже позволяет отправлять ваши приложения в iOS, Android и Universal Windows Platform (UWP), но теперь Microsoft значительно расширяет ваши возможности. Четыре новых платформы приходят к Xamarin.Forms:
Macos
Linux
Windows Presentation Foundation (WPF)
Tizen
Поддержка Linux поддерживается поверх рамки GTK #, а macOS — на Xamarin.Mac. Вы уже можете настроить таргетинг на Windows с помощью поддержки Xamarin.Forms UWP, но вскоре вы сможете создавать классические приложения WPF, если хотите. Превратив Tizen в микс, вы можете расширить свои приложения для форм на миллионы устройств Samsung, а также телевизоры, носимые и многое другое.

Дальше несколько примеров и вывод

Это лишь некоторые из основных моментов из того, что входит в Xamarin.Forms 3.0, но можно с уверенностью сказать, что структура все еще быстро развивается и становится все более мощным выбором для разработчиков. Между улучшениями производительности, расширяя целевой охват до множества новых основных платформ и увеличивая способность смешивать и сопоставлять Xamarin.Forms с родными приложениями, где это имеет смысл, самое время быть разработчиком Xamarin.

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


VD>Они обещают стандартизовать и тэги XAML-а. Но все равно они будут компилироваться под разные платформы, по этому ты не сможешь получить общего бинарника под них.

Ак как же Xamarin.Forms?
S>>и писать сразу один код для UWP и WPF по аналогии с Ксамарин, где в одном проекте ты делаешь приложение для IOS,Android,Tizen и UWP

VD>Кзамарин тебе предоставляет общий тулинг для этого. UWP и WPF — это разные платформы. Общие теги — это еще не все. Там море нюансов, которые тебе придется учитывать.

В чем проблема сделать общий тулингтдля WPF и UWP?
VD>Вот всем было бы лучше, если МС тупо выбросил все свои Кзамарины с UWP и тупо реализовал дотнет вместе с библиотеками на всех девайсах. Тогда бы не было чихарды с проектными файлами, всеми этими нюансами и т.п. И можно было бы действительно писать единый код.
Для этого и сжелан Net Standard 2, но все равно нужно использовать нативные контролы

VD>Хотя единый код для десктопа и телефона — это скорее красивая сказка. Бизнес логику и сейчас не трудно обобщить. А гуй у ни будет разный. Причем концептуально разный.

S>>То есть у тебя будет возможность сразу делать код для UWP и WPF, но ты его не будешь использовать?

VD>Да не будет этого. Плюс, конечно не буду. Я выберу WPF для десктопа. И Кзамарин для девайсов. А UWP пошлю на фиг. Ну, разве что кто-то потребует (и оплатит) разработку под виндофоны.
То есть бесплатная возможность создать приложение для UWP тебя не интересует?
Я как владелец десятки выберу UWP приложения, чем ресурсоемкий и небезопасный WPF.

VD>МС это уже понял. От того и приоритеты у него поменялись.

VD>Посмотри тренды по запросам:
VD>https://trends.google.ru/trends/explore?cat=5&q=xamarin,UWP,WPF,ASP.NET,%2Fm%2F0j45p7w

Нще раз это все до выхода NS2 и XS2. К новому году все изменится.
S>>А потом меня обвиняешь в бреде.

VD>Я не обвиняю, я констатирую факт.
Ну конечно, один ты у нас умный с с MS стою в сторонке.
VD>>>Тебе говорят, что NetStandard — это всего лишь стандарт. Он не позволит заработать UWP-приложениям под Core. Это всего лишь подмножество АПИ которое хотят сделать доступным в назных реализациях.

S>> Это не просто АПИ это еще и реализация

VD>Хрен там! NetStandard — это именно подмножество АПИ. Понятно, что дотнетные сборки можно использовать где угодно. Вопрос только в том, что за либы ты сможешь зедайствовать. Вот в Моно, например, не было полноценого МСБилда. И хоть ты обосрись, но проект в Моно должен быть другим. И XAML-а там тоже не было. UWP — это АПИ разработки для 10-й винды. Там куча нюансов связанных с их магазином и всякими политиками безопасности. Всего этого никогда не будет в NetStandard.

NetStandard это не монолит, там кстати есть пакеты только для Windows

Существуют и «серые области», наподобие System.Drawing, которые с одной стороны могут иметь смысл на всех платформах, с другой слишком завязаны на Windows с его GDI+. Подробности: github.com/dotnet/corefx/issues/20325.

Так, что от условной компиляции не исбавиться.
VD>То же XAML не будет одинаковым просто потому, что в UWP не реализовали всех наворотов из WPF. Набор базовых тегов они возможно и устаканят. Но не более того.
Их реализуют. Во всяком случае надеюсь. В этом то и смысл.
VD>Ну, и надо понимать, что WPF и UWP тупо дублируют друг друга. Все разница в UWP в том, что UWP-приложение можно тупо запихнуть в их магазин и продать.
Ну вот и я говорю, я возьму приложение UWP вместо WPF

S>>Вот только несколько диффов

S>>https://github.com/dotnet/standard/blob/master/docs/versions/netstandard2.0.md

VD>Ну, и где ты в списке пространств имен Window узрел?

VD>Ой, все! (ц) Тебе хоть кол на голове теши, ты будешь продолжать нести бред.

S>> А UWP и так работает под .Net Core в Debug режиме. Библиотеки у них одни.

VD>Что ты несешь?! А...

Влад ты, что мои ссыки не читаешь?
Еще раз специально для тебя

Читаем
В чем разница между NetFramework и NetCore

https://msdn.microsoft.com/ru-ru/magazine/mt590967.aspx

Наконец, .NET Core — это нижележащая инфраструктура, от которой зависит .NET Native. Когда проектировали .NET Native, стало понятно, что .NET Framework не подойдет в качестве фундамента для библиотек классов этой инфраструктуры. Дело в том, что .NET Native статически связывает инфраструктуру с приложением, а затем удаляет все лишнее, что не нужно приложению. (Здесь я сильно упрощаю общую картину, но идею вы уловили. Подробнее на эту тему см. «Inside .NET Native» по ссылке bit.ly/1UR7ChW.)
Традиционная реализация .NET Framework не предусматривает разбиения на модули, поэтому компоновщик (linker) не может включить в приложение лишь ту часть инфраструктуры, которая нужна приложению. Но .NET Core, по сути, является ответвлением .NET Framework, реализация которой оптимизирована с учетом модульности. Другое преимущество этой реализации — возможность поставлять .NET Core Framework как набор NuGet-пакетов, что позволяет вам обновлять индивидуальные классы вне самой .NET Framework. Однако, прежде чем двигаться дальше, давайте обсудим изменения в NuGet.

Скомпилировав и запустив программу в конфигурации Debug, вы выполняете код Intermediate Language (IL) в CoreCLR, упакованной вместе с приложением. Системные сборки .NET упаковываются наряду с кодом вашего приложения, и это приложение получает зависимость от пакета Microsoft.NET.CoreRuntime (CoreCLR). Если инфраструктура CoreCLR отсутствует на устройстве, где вы тестируете, Visual Studio автоматически обнаружит это и установит ее до развертывания вашего приложения.
Это означает, что получаете максимум удобств при разработке: быструю компиляцию и установку, богатые средства отладки и диагностики и весь инструментарий, к которому вы привыкли при .NET-разработке.
Когда вы переключаетесь в режим Release, ваше приложение по умолчанию использует цепочку инструментария .NET Native. Поскольку пакет компилируется в неуправляемый двоичный код, в этом пакете не нужны библиотеки .NET Framework. Более того, пакет зависим от новейшей установленной версии исполняющей среды .NET Native в противоположность пакету CoreCLR. Исполняющая среда .NET Native на устройстве будет всегда совместима с пакетом вашего приложения.

Читай выделенное. И разберись с предметной областью.
VD>Люди же будут вообще все больше и больше уходить в веб. Трах со всеми этими платформами никому не нужен. Десктопные приложения, конечно, останутся. Но их количество будет сокращаться. UWP станет нужным только после победы виндофонов. Кзамарин будет востребован просто потому, что многие хотя иметь клинтов для мобил.

VD>МС же делает очередные поступательные шаги вместо то того, чтобы еще 15 лет назад не делать глупостей и не превращать дотнет в виндовую яву.

VD>Правильным подходом было бы реализовать в Core все интерфейсы нужные для создания программ включая WPF. Выкинуть к чертям UWP и Кзамарин, а для Андроида и айОС реализовать полноценный фреймворк с поддержкой AOT-компиляции.

VD>Тогда все эти NetStandard-ы были бы не нужны, а поддержка всяких UWP и Виндовс сводилась бы к паре небольших библиотечек. Собственно именно это и называется Явой. Именно в Яве МС нашел фатальный недостаток на рубеже веков. И именно желание сделать привязанную к винде яву и породила всю эту котовасию.
ни как раз к этому и идут, только постепенно. А тебе нужно сразу и сейчас
Есть Net Natie для UWP и IOS, есть NetStandа насчет пару библитечек посмотри на свою нитру и оцени сколько в ней кода

Ну и на посдедок о развитии xamarin.Forms 3 опять гугл переводчик
https://visualstudiomagazine.com/articles/2017/08/01/xamarinforms3_0.aspx

Одна вещь, о которой вы могли бы попросить, — это возможность расширения ваших приложений на другие платформы. Xamarin.Forms уже позволяет отправлять ваши приложения в iOS, Android и Universal Windows Platform (UWP), но теперь Microsoft значительно расширяет ваши возможности. Четыре новых платформы приходят к Xamarin.Forms:
Macos
Linux
Windows Presentation Foundation (WPF)
Tizen
Поддержка Linux поддерживается поверх рамки GTK #, а macOS — на Xamarin.Mac. Вы уже можете настроить таргетинг на Windows с помощью поддержки Xamarin.Forms UWP, но вскоре вы сможете создавать классические приложения W PF, если хотите. Превратив Tizen в микс, вы можете расширить свои приложения для форм на миллионы устройств Samsung, а также телевизоры, носимые и многое другое.

Дальше несколько примеров и вывод

Это лишь некоторые из основных моментов из того, что входит в Xamarin.Forms 3.0, но можно с уверенностью сказать, что структура все еще быстро развивается и становится все более мощным выбором для разработчиков. Между улучшениями производительности, расширяя целевой охват до множества новых основных платформ и увеличивая способность смешивать и сопоставлять Xamarin.Forms с родными приложениями, где это имеет смысл, самое время быть разработчиком Xamarin.