Комментарии 102
C# 9 определенно не является серьезным мотивом для переезда на новый дотнет
Узнаю старый-добрый контур.
А вообще — я и впрямь не вижу ничего особо впечатляющего в C# 9. Приятные мелочи, не более.
Если вы собираетесь использовать Nullable Reference Types то до C#9 писать обобщённые методы было немного затруднительным.
Да, мне тоже очень этот момент понравился.
А что особенно понравилось, так это что тулчейном .NET 5.0 можно собирать проекты и .NET Core, и .NET Framework, задействуя новые возможности языка. То есть нет смысла ломать проект и менять целевую платформу на .NET 5.0. Достаточно просто обновить компилятор и радоваться жизни.
Это так происходит с незапамятных времён начиная с C# 3 разве что кроме Expression, которому нужна поддержка самого .NET.
Кстати если нужна поддержка старых фреймворком с новыми компиляторами есть замечательный проект
https://github.com/theraot/Theraot/
Да много полезного существует. Ещё вот:
https://www.nuget.org/packages/Microsoft.NETFramework.ReferenceAssemblies/
Можно компилировать под .NET Framework даже при его отсутствии (есть у меня такой сценарий).
Можно указать единственный net5.0 TargetFramework и при этом остаться на .NET Framework 2.0 ;)
Целевая платофрма не так важна, как TargetFrameworkIdentifier
Если я обновлюсь на net5, мой проект на WPF сможет запускаться хотя бы на Win7? Ну и сюда же в кучу — WPF на свежих дотнетах теперь требует self-host приложения с кучей длл, нельзя просто exe файл буквально использовать? =)
Можно, если не использовать self-hosted )
Лично у меня с net5 были проблемы. В self-contained app то одного не хватает, то другого, то вообще запуститься не в состоянии. А вот при сборке под netcoreapp3.1 работает всегда и везде. Принципиальной разницы между по функционалу net5.0 и netcoreapp3.1 не вижу, поэтому остаюсь на netcoreapp3.1, но с новыми фишками c#9.0
Почему нет?
В плане поддержки системы различий между 3.1 и 5.0 практически нет.
https://github.com/dotnet/core/blob/master/release-notes/3.1/3.1-supported-os.md
https://github.com/dotnet/core/blob/master/release-notes/5.0/5.0-supported-os.md
В связи с этим чисто утилитарные вопросы:
— Если на голую win7 установить только dot5, то будут ли работать приложения, которые в своих требованиях хотят dot4.x, нативно не представленной в win7?
— Для x64-сборок достаточно ли установить только x64-инсталлятор, или дополнительно требуется и x86-установка для x86-приложений?
— Какой из предлагаемых пакетов наиболее полный (не рассматривая SDK-пакет: ASP Core Runtime, Desktop Runtime, Runtime)?
Присоединяюсь к вопросу.
Вот только сегодня помогал человеку установить одну софтину (как обычно, простой пользователь сообщения об ошибках не читает никогда, максимум "он там что-то написал, я закрыл, ну и все закрылось"). Сообщение установщика заключалось в том, что ему требуется для установки .NET 4.5, а на Windows 7 на тот момент был установлен 4.8. Проблему удалось решить удалив 4.8 и установив 4.5, затем установив 4.8 обратно. Понятно, что в установщике зачем-то жестко прописано "==" вместо ">=", и сам .NET тут возможно не при чем. Но это просто последний такой случай в моей практике из множества аналогичных, т.е. тенденция имеется, вопрос: сохранится ли?
2) «будут ли работать приложения, которые в своих требованиях хотят dot4.x, нативно не представленной в win7» — если имеется в виду, что приложение dot5 использует библиотеку например dot4.8 — то устанавливать dot4.8 придётся. Причём опять же таки, если речь идёт о Windows 7 SP1 без единого установленного обновления — то установщик dot4.8 выдаст ошибку какого-то там сертификата, пока вы не поставите обновление KB3004394-v2
3) «Для x64-сборок достаточно ли установить только x64-инсталлятор, или дополнительно требуется и x86-установка для x86-приложений» — к сожалению не понял вопроса, их же тут два… Если Вы собирали под x64 — то для работы понадобится x64 runtime, если собирали под x86 — то для работы понадобится x86 runtime (т. е. если в вашем софте есть смешение архитектур — то придётся ставить оба runtime)
4) Как вам уже написали ниже:
Net Runtime — минимальный набор (только для библиотек и консольных приложений)
ASP .Net Core Runtime = Net Runtime + поддержка ASP .Net Core
Desktop Runtime = Net Runtime + поддержка десктопного UI (WPF/WinForms)
1) эти обновления в системе есть.
2) Да, это я тоже замечал, проблема появилась после dotnet 4.6.2. Я добавлял сертификаты через политики.
3)- я не девелопер, просто потребитель и мне неизвестно, что заложено в приложении. Судя по ответу — да, нужно устанавливать оба x64+x86, если система 64, для всех вариантов (возможных) приложений. И впридачу, крайняя 4.х версия тоже необходима.
Какой из предлагаемых пакетов наиболее полный (не рассматривая SDK-пакет: ASP Core Runtime, Desktop Runtime, Runtime)
Не совсем корректный вопрос, потому что
ASP.Net Core Runtime = Net Runtime + поддержка ASP.Net
Desktop Runtime = Net Runtime + поддержка десктопного UI
Другие отзывы о миграции, которые я смог найти — …
На мой взгляд, лучшую статью на тему миграции на .NET 5.0 написал Rick Strahl.
RegexOptions.ECMAScript возникали ошибки при разборе шаблонов, содержащих следующий символьный класс – [^] (например, ^(\s*)([^]*\S)(\s*)$). Данная ошибка создавала множество проблем при работе с JavaScript-движками, написанными на чистом .NET (Jint, Jurassic и NiL.JS).Хотя каждая и добавляет новых. Например, в чате DotNetRu рассказали, что кое-где новая версия дотнета вызвала заметное падение производительности.
C# 9 определенно не является серьезным мотивом для переезда на новый дотнет
Добавлю. Новый шарп — это в основном синтаксические накрутки, генерируемый IL не изменяется. Например, record — это на самом деле класс под капотом. А значит можно использовать многие фичи девятого шарпа даже на netstandard2.0.
Для этого вам нужно написать следующий костыль где-нибудь.
Либо почитайте пост от автора Nullables, который сделал nuget-пакет для этой же цели (чтобы использовать девятый шарп в < 5 версиях)
У меня есть проект (библиотека), таргетящий 2.0, и при этом использующий девятый шарп. Очень удобно
генерируемый IL не изменяется
Разве это не основной смысл иметь IL не привязанный к языку? Или вы хотите, чтобы была версия .NET с изменённым IL?
Ну а как добавлять какие-то вещи типа generics? Или вот DIM (default interface member)? Хотя про последнее не уверен, может это только от рантайма зависит
Generics требовали переделки архитектуры, но это было очень давно, когда C# был молод и когда ещё не был основательно продуман.
И то, что практически все новые фичи под капотом являются просто сахаром, это однозначный плюс — если что непонятно, всегда можно заглянуть под капот и понять что как работает.
Так можно говорить про каждую версию и остаться в итоге на net20 ;)
Теже рекорды особо не нужны, когда можно было просто использовать ValueObject. Но всеже, в каждом релизе, что-то да новое есть, например аттрибут ModuleInitializer или SkipLocalsInit, поднимающие версии рантайма. Да и всякий синтаксический сахар, все-таки, упращает читаемость кода. Поэтому как-то неочень ультимативно заявлять, что новая версия языка, рантайма или SDK ничего не приносит
Теже рекорды особо не нужны, когда можно было просто использовать ValueObject.
Вы бы исходники того проекта хотя бы почитали. Как proof-of-concept — норм, но в продакшн я бы и на пушечный выстрел такое не подпустил.
Речь больше шла о реализации IEquatable<T>
Я её и имею в виду. Там оно сделано через рефлексию со всеми её минусами.
Это опенсорс решение. У кого есть желание, может улучшить предложенный вариант. И кажется, что этот репозиторий будет хорошей песочницей перед тем, как предложить свои измнения в код, который используется в проде
Ну конкретно этот метод — затычка, он не нуждается в оптимизации, потому что вы не можете в пользовательском коде унаследоваться от System.ValueType. От него неявно наследуются типы-структуры, но если вы структуры сравниваете через object.Equals(), то вы делаете что-то не так.
Да, теоретически можно было бы его расширить и на пользовательские классы, добившись той же логики сравнения, что и для структур, но зачем это нужно, когда ввели более эффективные рекорды?
Так можно говорить про каждую версию и остаться в итоге на net20
Я на нем и остаюсь (если вы не про core2.0 или боже упаси второй fw).
ValueObject выполняет другую задачу. С рекордами вы получаете возможность построить граф из коробки. Ну и паттерн матчинг.
ValueObject обычно для небольших оберток, я никогда не видел структуры, которая достаточно самостоятельна и выполняет какую-то ключевую задачу.
Я на нем и остаюсь (если вы не про core2.0 или боже упаси второй fw).
Про легаси. Речь шла больше про те проекты, где не находят применения новым возможностям по каким-либо причинам. Больше удручает, когда это проиводит к затяжному застою без каких-либо проблем в применимости
С рекордами вы получаете возможность построить граф из коробки
С таким не приходилось связываться, поэтому не могу оценить о чем идет речь :)
Для меня, пока что, рекорды убирают бойлерплейт, связанный с реализацией IEquatable<T>
Кстати, можно поучиться у тех самых nodejs Electron программистов и пользоваться Electron.NET. На все той же .NET Conf был неплохой доклад про это.
Да ладно новичку… Вот решил вспомнить и попробовать утилиту сделать… И выходит что winforms живее всех живых среди мёртвых а на чём начинать на будущее непонятно.
.NET Standard — просто общая API для всего этого зоопарка. С зоопарком JS'а ничего не сравнится.
А так — сравнивать с худшими не повод для радости. Старый .NET был хорош именно тем, что это была единая среда с разными версиями, а весь «зоопарк» состоял из WinForms vs WPF, ну и Mono где-то рядом бегал и пытался не отставать. Хочешь создавать что-то новое — создаёшь на последней версии и не паришь себе мозг.
(окей, да, я явно лукавлю, т.к. если делается dll расширения для старых приложений, то выбора что использовать не было — только старый фреймворк)
— Чем отличается инсталляция от перфоманса? Если ты, допустим, насрал человеку под дверь, а потом уже позвонил в звонок – это инсталляция. А вот если ты сначала человеку позвонил, а когда он вышел из квартиры, то ты сел перед ним и насрал, – это уже перфоманс.
А в программировании как-то всё больше скорость вычислений или производительность.
Еще любят генерацию вместо поколений использовать почему-то.
Ну или совсем гулять — новым тулчейном компилять под netstandard2.0 и запускать на новом рантайме.
На всякий случай, отвечу на вопрос зачем: если не надо новых фич, то в целом повышать версию выглядит бессмысленно, бывает легаси и прочие замороженные проекты, которые нет смысла переводить на новый фреймворк, а зависимости свежие использовать хочется.
.NET Standard — это лишь API. Ему можно подсунуть любой удовлетворяющий рантайм. .NET — это продолжение идей .NET Standard. Поэтому, если вам не нужны фичи из .NET, то можете смело оставаться на стандарте
1. Будет ли прирост производительности просто от подсовывания нового рантайма
2. Не вылезут ли проблемы из-за того, что совместимость именно что декларируется. Т.е. могут взять метод и убрать у него реализацию (типа у нас новые правила) или изменить реализацию, что приведёт к косякам. А то у нас был весёлый пример с использованием рантайма 2.2 при разработке на 2.1. Несколько недель поиска проблемы.
Но убирать реализацию врядли будут, скорее наоборот — добавят для каких то вещей.
ПС: мне казалось, net core 3 уже целиком реализовывал стандарт? Остались методы без реализации, но заявлены в стандарте?
Вот сейчас выяснил, что сломали Thread.Abort
Т.е. код начнёт эпично валиться в непредсказуемых местах. И вот сколько таких мест может быть?
Более того, работать с ним было намного неудобнее, чем с тасками.
Да, кому то обновление будет не бесплатно. Но судя по МСДН — будет варнинг, кто пользуется — должны быть внимательнее.
При компиляции ворнинг будет, но изначально вопрос был в том — что просто поставили новый фреймворк и взяли старый код. Тут, похоже, будет очень неприятно.
1. Будет ли прирост производительности просто от подсовывания нового рантайма
Моя библиотека, поддерживающая .NET Standard 2.1, стала быстрее работать на 20-25% при запуске под .NET 5.0 вместо .NET Core App 3.1.
или опять 100 системных файлов править руками по пиксельно?
В статье упущены значительные улучшения single-file applications — почти полностью ушли от распаковки файлов во временную директорию, скорость первого запуска в связи с этим заметно увеличилась.
Измерения перфомансаТаки сложно написать «измерения производительности»? Тем более что данный англицизм имеет в русском языке совершенно другое устоявшееся значение.
А что шарписты про Dart скажут. Плюсы/минусы какие?
Например, встречал инфу, что «void возвращает null», хотя во второй версии говорят void это вообще тип.
Или отсутствие явных интерфейсов, а не явно каждый class это интерфейс. То есть один и тот же класс, можно как наследовать, так и имплементировать =)
С точки же прикладной, dart похоже выстрелил только на мобилках как flutter, соответственно Dart — язык одного фреймворка. Как в свое время Ruby с Ruby on Rails. Хотя сейчас есть бетка flutter под десктоп, мб и на десктопе выстрелит.
Есть инфа, на Юнити C# 9 скоро можно использовать будет?
Но вообще, в мире заботы о экологии и энергопотреблении, давно уже пора заменить JSON чем-нибудь менее расточительным. А то всякие возобновляемые источники ставят, и прочее. Чтобы потом в датацентрах процентов 30 сжигать чисто на преобразование в этот уродливый формат.
Меня, лично, останавливает исключительно отсутствие минимальной поддержки в Chrome Dev Tools. Если кто-нибудь прикрутит preview какого-нибудь BSON в Network-табе — я сразу начну свои аппы переводить. А в идеале — сразу брать что-нибудь типа AVRO, чтобы уже два раза не вставать.
Вот есть у меня маленькая консольная утилита, ей ничего особо не нужно для работы, под старый фреймворк я ее компилил
Теперь же у нас всё просто!
1.Сначала надо сделать csproj файл (100500 настроек, наслаждайтесь комбинированием)
2. потом дернуть dotnet build, который сгенерирует 2 папки, с 4 подпапками.в каждой, десяток доп-файлов и наслаждайтесь чтением доков, чтобы это все как-то привести к старому
… потратил больше двух часов гуглежа на это все — останусь-ка я, пожалуй, на старом фреймворке.
Только что попробовал: csc из .NET 5.0 по-прежнему прекрасно компилирует код из одного файла.
Сначала надо сделать csproj файл
dotnet new console
Ну и я ж и не говорю, мой проект не скомпилировался и не заработал в итоге.
Просто по-старому я это делал одной командой имея на руках 1 .cs файл и получая на выходе 1 .exe файл. Итого — 2 (ну ладно, три — третьим идет .bat с вызовом csc, чтобы не вспоминать потом правильный набор ключей и не дергать справку).
Теперь же нужно обязательно иметь .csproj (и + тот самый bat файл), который фиг настроишь самостоятельно (ключей — много) и на выходе вы еще и обязательно получите кучу вспомогательных файлов/папок. Да, там есть команда для авторазвертывания в целевую папку, но это всё равно никак не решает проблемы возникновения кучи доп. файлов.
Ну т.е. если раньше я мог накодить эксперимент чуть ли не в блокноте, скомпилить его и пользоваться, то теперь мне надо сначала настроить практически полноценное окружение (а еще лучше — не париться и взять Visual Studio, которой MS прямо тычет на каждой странице про dotnet и его инсталлятор).
Юзабилити.
P.S.: и да, я сначала установил сам дотнет 5ый, без sdk, в итоге dotnet new console проект-то мне сделал, но после смены там на net5.0 сказал, что у него лапки и компилировать отказался. Пока я не скачал еще и sdk-инсталлятор. Замечу, что предыдущие версии (начиная с первой!) работали и компилировали сразу после установки, являясь цельной средой.
оторый фиг настроишь самостоятельно
Эмм, вот весь csproj-файл, чего там настраивать-то?
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net5.0</TargetFramework>
<RootNamespace>RootNamespace</RootNamespace>
</PropertyGroup>
</Project>Потом выполняется dotnet run. Это ещё проще, чем csc с заданием ключей.
А если вдруг раздражают директории bin и obj, ну что ж, внутрь них заглядывать даже не надо.
Ну т.е. если раньше я мог накодить эксперимент чуть ли не в блокноте, скомпилить его и пользоваться
Попробуйте это:
https://habr.com/ru/company/microsoft/blog/475110/
Эмм, вот весь csproj-файл, чего там настраивать-то?
Именно! Да. И на выходе — куча бесполезных для меня файлов. Я, например, так и не понял, зачем мне сгенерировались 2 штуки .dll файлов рядом с .exe (один — в подпапке) и 3 json-файла, в которых в явном виде написана целевая среда исполнения и тоже не очень понятно, что будет если их убрать.
Ну и в конечном итоге — я пишу не о том, что оно не работает… А о том, что простейшая команда в итоге превратилась в какие-то танцы с гуглом и кучей телодвижений — причем итоговый результат тот же.
Попробуйте это:
habr.com/ru/company/microsoft/blog/475110
По сути — visual studio, вид сбоку. Не, ну я утрирую, конечно, но суть в том, что в итоге вместо использования того, что и так уже заведомо есть в ОС (в десятке — даже из коробки уже), необходимо магическими заклинаниями что-то докачивать, устанавливать и только получив полноценную среду разработки — работать дальше.
Удобно же!
Особенно удобно эти магические заклинания гуглить, если про Jupyter Lab и Anaconda Navigator ни разу не слышал. Абсолютно интуитивно понятно же:
dotnet tool install -g dotnet-try
dotnet try jupyter install
jupyter lab
Специально зарегался на Хабре, что бы оставить Вам это.
Язык C#
Командная строка компиляции
"{home}\dotnet.exe" "{home}\sdk\3.1.100\Roslyn\bincore\csc.dll" -reference:"{home}\packs\NETStandard.Library.Ref\2.1.0\ref\netstandard2.1\netstandard.dll" -langversion:8.0 -out:Solution.dll -define:ONLINE_JUDGE -debug- -optimize+ -nologo -warn:3 "{srcFile}"
Командная строка запуска
"{home}\dotnet.exe" exec --runtimeconfig "{home}\sdk\3.1.100\dotnet.runtimeconfig.json" "{location}\Solution.dll"
del
Не перенесли, а изначально планировали на .NET 6, пруф
Кстати, насчёт производительности. Сравнил следующий код на C#:
[MethodImpl(MethodImplOptions.AggressiveOptimization)]
static unsafe void SumUnmanagedUnsafeScanlineVector(UnmanagedImage<float> img1, UnmanagedImage<float> img2, UnmanagedImage<float> res)
{
var w8 = res.Width / 8 * 8;
for (int j = 0; j < res.Height; j++)
{
var p1 = img1.GetScanLine(j);
var p2 = img2.GetScanLine(j);
var p3 = res.GetScanLine(j);
for (int i = 0; i < w8; i += 8)
{
Avx.Store(p3, Avx.Add(Avx.LoadVector256(p1), Avx.LoadVector256(p2)));
p1 += 8;
p2 += 8;
p3 += 8;
}
for (int i = w8; i < res.Width; i++)
*p3++ = *p1++ + *p2++;
}
}и код на C++:
void ImageSumVector(Image<float> &img1, Image<float> &img2, Image<float> &res)
{
int w8 = res.Width() / 8 * 8;
for (int j = 0; j < res.Height(); j++)
{
float *p1 = &img1(0, j);
float *p2 = &img2(0, j);
float *p3 = &res(0, j);
for (int i = 0; i < w8; i += 8)
{
_mm256_storeu_ps(p3, _mm256_add_ps(_mm256_loadu_ps(p1), _mm256_loadu_ps(p2)));
p1 += 8;
p2 += 8;
p3 += 8;
}
for (int i = w8; i < res.Width(); i++)
*p3++ = *p1++ + *p2++;
}
}Код на C# в Release отрабатывал примерно за 4.3 мкс, код на C++ — за 3.75 мкс (одинаково с флагами -O1, -O2 и -O3). Тот же вариант, но невекторизованный, отрабатывал на C# и C++ (-O1) одинаково за 12.5 мкс. Правда, начиная с -O2 в C++ врабалась автовекторизация.
Год назад C# отставал от C++ в этом тесте почти в 2 раза, сейчас — практически паритет. Получается, C++ не нужен, и на C# уже вполне можно писать производительный код?
Год назад C# отставал от C++ в этом тесте почти в 2 раза, сейчас — практически паритет. Получается, C++ не нужен, и на C# уже вполне можно писать производительный код?Можно, только надо еще с GC моменты учитывать.
Пока Designer не допилят, WinForms под 5.0, к сожалению, не готов к реальной разработке. Мы сделали пробное портиррование нашего немаленького продукта и все на удивление завелось без больших проблем. Там и тут чутка подпилить да подстучать и все работает. Но застопорились на двух проблемах:
- Дизайнер сырой на удивление, хотя и заявленно, что обкатали его вместе с большими производителями контролов. И что, никто не пробовал иконки из глобальных русурсов использовать? https://github.com/dotnet/winforms/issues/3958
- Stimulsoft Report, который мы используем для отчетов, под Core не умеет в Compile. Придется видимо отчеты переделывать.
Кто-то пробовал новый Designer в формах с приличным колличеством контролов? Он у вас такой же медленный? У меня после клика контрол фокусируется раздражающе меделенно.
Вышел .NET 5. И что?