[CLI] Build-time performance improvements.
[CLI] Global tools; replaces .NET CLI Tools (DotNetCliToolReference).
[CoreCLR] Minor-version roll-forward.
[CoreCLR] No-copy array slicing with Span<T>.
[CoreFX] HttpClient performance improvements.
[CoreFX] Windows Compatibility Pack.
[ASP.NET] SignalR is available for .NET Core.
[ASP.NET] HTTPS is on by default for ASP.NET.
[EF] Basic lazy loading support.
[EF] Support for Azure Cosmos DB.
И опять ничего для десктопного GUI. Почему и как с этим жить?
Здравствуйте, Tom, Вы писали:
BE>>Electron — тормоз. Заказчики не поймут. Tom>Пойду пацанам из VsCode расскажу, а то они не вкурсе
Ты им только правильно мысль сформулируй: GUI их VsCode тормозит по сравнению с "нормальным" Visual Studio.
Вот, например, у меня на компе intellisense у Visual Studio 2013 срабатывает быстрее, чем у VsCode.
И вообще Visual Studio с большими файлами работает лучше. Тормозов меньше.
Хотя, может быть только у меня так?..
Красота — наивысшая степень целесообразности. (c) И. Ефремов
spans support the notion of reinterpret casts, meaning you can cast a Span<byte> to be a Span<int> (where the 0th index into the Span<int> maps to the first four bytes of the Span<byte>). That way if you read a buffer of bytes, you can pass it off to methods that operate on grouped bytes as ints safely and efficiently
In support of Span<T> and friends, hundreds of new members and types are being added across .NET. Many of these are overloads of existing array-based and string-based methods, while others are entirely new types focused on specific areas of processing. For example, all the primitive types like Int32 now have Parse overloads that accept a ReadOnlySpan<char> in addition to the existing overloads that take strings.
Здравствуйте, Vladek, Вы писали:
V>На всех платформах есть хорошие тулкиты для создания нативного GUI — Gtk#, WPF, Avalonia (сырое, но живое). Пиши и радуйся.
Довольно глупо пвыбирать переносимые средства разработки и привязываться к платформе гуёвой библитекой. Довольно логично было бы иметь переносимый ГУЙ для Явы.
Но МС снова занимается протекционистской политикой. Ее интересует только продажа своих облоков. А для десктопа есть Виндовс.
В прочем, Xamarin прекрасно подходит на межплатформный Гуй. Жаль только Моно малось все портит. Все же качество далекое от МСного. Но уже вполне юзебельное.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, BlackEric, Вы писали:
BE>И опять ничего для десктопного GUI. Почему и как с этим жить?
Усиленно хоронят flash, а на нём можно было шикарные кросплатформенные gui делать.
Теперь только кутэ или уеб
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>>Следи за Xamarin.Forms S>>https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap
VD>И причем тут Core?
Тебе шашечки или ехать? Например Тизен использует Xamarin.Forms, но не использует моно.
В Xamarin.Forms можно создавать UWP приложения, это конечно в конечном итоге не совсем .Net Core, а .Net Native, но на уровне отладки используется Core
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Тебе шашечки или ехать? Например Тизен использует Xamarin.Forms, но не использует моно.
Т.е. Самсунг прикрутил Core к Xamarin-у? Где об этом можно почитать?
Есть ли там поддержка АРМов? И что работает ли это дело под Виндой (десктопной)?
S>В Xamarin.Forms можно создавать UWP приложения, это конечно в конечном итоге не совсем .Net Core, а .Net Native, но на уровне отладки используется Core
К сожалению, переносимость приложений в Xamarin-е далеко не полная. У Xamarin-иновских приложений есть переносимая часть, которая тупо препроцессится в целевую платформу (в Яву под андроидом, в код под iOS-ом и (видимо) в UWP под Виндофоном. Но для каждого из приложений надо написать не мало системно-зависимого кода. Что довольно трудоемко. Я вот сейчас смотрю один проект в котором исходно хотели создать решение для всех основных телефонов (Ябылофона, Ведройда и Виндофона). Но по факту остался только Ведройд, так как Виндафон никому на фиг не нужен (по факту он сдох коммерчески), а для Яблофона начали пилить отдельную версию отдельной командой. Вот такая переносимость... на словах.
Что касается десктопного софта, то как бы тут тоже будет та же байда. Проще взять Яву, GTK или QT. Там не придется выписывать системный код для маков и писюков. В прочем, по подводу десктопа я только догадываюсь, так как у меня даже малейшего желания не было создвать гуй на Xamarin-е.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Тебе шашечки или ехать? Например Тизен использует Xamarin.Forms, но не использует моно.
VD>Т.е. Самсунг прикрутил Core к Xamarin-у? Где об этом можно почитать?
VD>Есть ли там поддержка АРМов? И что работает ли это дело под Виндой (десктопной)?
Starting last year with enabling Linux/ARM32 support, this year we are continuing our work on enabling Linux/x86 support with ARM32 RyuJIT backend implementation in parallel. In addition, through the four Tizen .NET preview releases since last November, we have seen the potential of .NET as a new application platform in Tizen and received much interest and feedback from the community.
S>>В Xamarin.Forms можно создавать UWP приложения, это конечно в конечном итоге не совсем .Net Core, а .Net Native, но на уровне отладки используется Core
VD>К сожалению, переносимость приложений в Xamarin-е далеко не полная. У Xamarin-иновских приложений есть переносимая часть, которая тупо препроцессится в целевую платформу (в Яву под андроидом, в код под iOS-ом и (видимо) в UWP под Виндофоном. Но для каждого из приложений надо написать не мало системно-зависимого кода. Что довольно трудоемко. Я вот сейчас смотрю один проект в котором исходно хотели создать решение для всех основных телефонов (Ябылофона, Ведройда и Виндофона). Но по факту остался только Ведройд, так как Виндафон никому на фиг не нужен (по факту он сдох коммерчески), а для Яблофона начали пилить отдельную версию отдельной командой. Вот такая переносимость... на словах.
VD>Что касается десктопного софта, то как бы тут тоже будет та же байда. Проще взять Яву, GTK или QT. Там не придется выписывать системный код для маков и писюков. В прочем, по подводу десктопа я только догадываюсь, так как у меня даже малейшего желания не было создвать гуй на Xamarin-е.
Xamarin.Forms сейчас хорош для раного рода установщиков, утилит не требовательных к ГУЮ. Разные задачи.
А так они как раз и прикручивают и GTK, и WPF
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Serginio1, Вы писали:
S>> Тебе шашечки или ехать? Например Тизен использует Xamarin.Forms, но не использует моно.
VD>Т.е. Самсунг прикрутил Core к Xamarin-у? Где об этом можно почитать?
VD>Есть ли там поддержка АРМов? И что работает ли это дело под Виндой (десктопной)? https://developer.tizen.org/blog/celebrating-.net-core-2.0-looking-forward-tizen-4.0
Starting last year with enabling Linux/ARM32 support, this year we are continuing our work on enabling Linux/x86 support with ARM32 RyuJIT backend implementation in parallel. In addition, through the four Tizen .NET preview releases since last November, we have seen the potential of .NET as a new application platform in Tizen and received much interest and feedback from the community.
"It has been an exciting and unique experience to participate in enabling RyuJIT for ARM32 in .NET. Although we started this work last December with little knowledge of RyuJIT, we have been able to introduce new features to RyuJIT for ARM32 with help from many developers and maintainers. Reviews from maintainers were very detailed, giving us an insight into the internal workings of RyuJIT, and even the smallest comments have been greatly appreciated. I want to express my deepest gratitude to all those who have helped us, especially Bruce Forstall (@BruceForstall) and Carol Eidt (@CarolEidt), for their dedicated help. RyuJIT for ARM32 would not exist without them. Of course, there have been some difficulties due to working in different time zones, but we have managed to take advantage of the time difference to keep development and reviews going 24 hours a day with the help of the maintainers and developers involved in RyuJIT. RyuJIT is still being improved, and I believe that our relationship will endure and we can continue to improve RyuJIT and .NET in the future.“
— Hyung-Kyu Choi (@hqueue), leader of the Tizen .NET ARM32 RyuJIT team
S>>В Xamarin.Forms можно создавать UWP приложения, это конечно в конечном итоге не совсем .Net Core, а .Net Native, но на уровне отладки используется Core
VD>К сожалению, переносимость приложений в Xamarin-е далеко не полная. У Xamarin-иновских приложений есть переносимая часть, которая тупо препроцессится в целевую платформу (в Яву под андроидом, в код под iOS-ом и (видимо) в UWP под Виндофоном. Но для каждого из приложений надо написать не мало системно-зависимого кода. Что довольно трудоемко. Я вот сейчас смотрю один проект в котором исходно хотели создать решение для всех основных телефонов (Ябылофона, Ведройда и Виндофона). Но по факту остался только Ведройд, так как Виндафон никому на фиг не нужен (по факту он сдох коммерчески), а для Яблофона начали пилить отдельную версию отдельной командой. Вот такая переносимость... на словах.
.NET Standard 2.0 All code moved to .NET Standard 2.0. Pull Request Complete
VD>Что касается десктопного софта, то как бы тут тоже будет та же байда. Проще взять Яву, GTK или QT. Там не придется выписывать системный код для маков и писюков. В прочем, по подводу десктопа я только догадываюсь, так как у меня даже малейшего желания не было создвать гуй на Xamarin-е.
По ссылке выше
GTK# Backend Preview Runs Xamarin.Forms on Linux using GTK# 2. Complete
GTK# Backend Preview Improvements from community Planned
iOS Native Swipe Replace implementation of swipe for context actions to use native. Planned
WPF Backend Preview Improvements from community Planned
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, stomsky, Вы писали:
S>Ты им только правильно мысль сформулируй: GUI их VsCode тормозит по сравнению с "нормальным" Visual Studio. S>Вот, например, у меня на компе intellisense у Visual Studio 2013 срабатывает быстрее, чем у VsCode. S>И вообще Visual Studio с большими файлами работает лучше. Тормозов меньше. S>Хотя, может быть только у меня так?..
2013 студия в 2018 году — так себе аргумент. гордиться тут особо нечем.
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Судя по написанному там есть не проверенный в реальных условиях код для 32-битной версии. Им нужны годы до того как это можно будет использовать в реальной работе. Плюс нужна поддержка 64-бит.
S> Ну сейчас активно заменяется на .Net Standard https://github.com/xamarin/Xamarin.Forms/wiki/Feature-Roadmap S>
S>.NET Standard 2.0 All code moved to .NET Standard 2.0. Pull Request Complete
Я тебе уже многократно говорил, что у тебя каша в голове. Попробуй написать реальный проект и поймешь какую чушь ты несешь.
.NET Standard это всего общие библиотеки и соглашения. Ты не можешь взять и написать приложение под Андроид на .NET Standard. Ты будешь вынужден создать приложение на Monodroid под Андроид и уже к нему подключить переносимую библиотеку созданную под .NET Standard. Вся возня с телефоном у тебя будет в обертках над явовскими библиотеками. Хочешь получить уведомление от ОС? Напиши лисенер и зарегистрируй его средтсвами Android SDK.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, Serginio1, Вы писали:
S>>> Тебе шашечки или ехать? Например Тизен использует Xamarin.Forms, но не использует моно.
Скажи, тебе просто нравится сидеть в бане за оверквотинг?
Учти, что любое твое следующее в котором будет строка: S>Здравствуйте, Некоторый Пользователь, Вы писали:
будит приводить тебя к бане. Лимит предупреждений исчерпан.
Так что цитируй, плиз, только то что нужно для понимания твоих слов.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
