Вышел .NET 5. И что?

    Несколько недель назад вышел .NET 5. На сайте Microsoft можно найти подробный анонс со всеми изменениями, но главный вопрос для меня, как для разработчика — и что с того? Что мне с выхода пятого дотнета, как я могу его использовать, есть ли смысл переходить на новую версию прямо сейчас? На эти вопросы я постараюсь ответить дальше.


    image


    Перфоманс


    Изменения в перфомансе — это самая заметная часть релиза. О них много писали на сайте Microsoft и рассказывали на .NET Conf. Давайте посмотрим внимательнее и определимся, где, насколько и за счет чего выросла производительность.


    image


    Измерения перфоманса с этого скрина основаны на бенчмарках от TechEmpower. Здесь Microsoft сравнивают результаты замеров производительности .NET 3.1 с ожидаемыми значениями для .NET 5. Стоит заметить, что это именно ожидаемые значения — реальных результатов от TechEmpower пока не было. Однако уже эти результаты выглядят впечатляюще — ускорение на 38 процентов для Plaintext, на 42 для Json и на 20 процентов в категории Fortunes (пояснения по разным типам бенчмарков вы можете найти в вики TechEmpower).


    Помимо результатов бенчмарков от TechEmpower, Microsoft также рассказывает и о других улучшениях. Например, сериализация JSON стала работать на 20% быстрее, а сериализация больших коллекций и массивов ускорилась аж в три раза.


    Также замеры производительности делал автор библиотеки Fusion Александр Якунин. В двух статьях на Medium он сначала измерил, насколько ускорилась работа демок его библиотеки (от 20 до 105 процентов), а затем проверил пятый .NET на нескольких синтетических бенчмарках — и также получил некоторое ускорение.


    За счет чего это происходит? В первую очередь, благодаря изменениям в GC, которые привели к уменьшению количества аллокаций и ускорению сборки мусора. Кстати, все эти изменения осуществляются одновременно с переписыванием GC на C#, а значит его код становится куда доступнее, понятнее и безопаснее. Подробности можно почитать в статье от Microsoft.


    Другие изменения коснулись JIT компиляции, асинхронности и многих методов базовой библиотеки. Это касается методов, относящихся к работе со строками, регулярными выражениями и, что особенно важно, с коллекциями и сериализацией. Во все той же статье приводится много примеров таких изменений, с соответствующими пулл-реквестами и бенчмарками.


    Изменения в JSON сериализации выглядят особенно впечатляюще. Только посмотрите на результаты бенчмарка по сериализации больших массивов!


    private MemoryStream _stream = new MemoryStream();
    private DateTime[] _array = Enumerable.Range(0, 1000).Select(_ => DateTime.UtcNow).ToArray();
    
    [Benchmark]
    public Task LargeArray()
    {
        _stream.Position = 0;
        return JsonSerializer.SerializeAsync(_stream, _array);
    }

    image


    Коротко — пятый дотнет сильно вырос в производительности и это важнейшая часть нового релиза. Большинство стандартных веб-приложений могут ожидать прирост производительности на 20% и выше, а отдельные приложения могут и вовсе ускориться в несколько раз.

    Языковое


    Вместе с .NET 5 вышла и девятая версия C#. Официальную страничку с изменениями вы можете найти на сайте Microsoft, но давайте попробуем разобраться — что именно здесь стоит внимания?


    Самое заметное изменение — это record-типы, позволяющие избавиться от бойлерплейта при написании DTO. Записи — это иммутабельные ссылочные типы с простым и коротким объявлением. В них по умолчанию определены методы Equals, HashCode, Copy, Clone, PrintMembers и ToString — разумеется, все они используют значения полей типа для выполнения операций. То есть Equals корректно сравнивает две записи по значениям, а не по ссылке.


    Также записи поддерживают синтаксис копирования с изменением значений полей через with, например:


    var person = new Person { FirstName = "Mads", LastName = "Nielsen" };
    var otherPerson = person with { LastName = "Torgersen" };

    Больше о применении записей вы можете почитать в блоге Владимира Хорикова и в публикации от Konrad Kokosa.


    Другое важное изменение — это обновленный pattern matching. Теперь паттерны могут настраиваться по типам и операторам сравнения, причем несколько разных сравнений вы можете объединять через логические операторы. Например:


    DeliveryTruck t when t.GrossWeightClass switch 
    {
        < 3000 => 10.00m - 2.00m,
        >= 3000 and <= 5000 => 10.00m,
        > 5000 => 10.00m + 5.00m
    }

    Остальные изменения не столь заметны — они касаются верхнеуровневых программ (возможность писать короткие программы без базового класса и функции main), упрощенного синтаксиса для new (без указания типа), init-only сеттеров и прочего.


    Последние изменения в новом C#, которые хотелось бы упомянуть — это расширенная поддержка для source generators. Этот функционал позволяет генерировать код при компиляции проекта и зачастую очень удобен для авторов библиотек. В новом релизе работу с генераторами кода сделали чуть проще, расширив функционал partial классов (с них сняли некоторые из старых ограничений) и добавив инициализаторы модулей (методы, которые вызываются до первого доступа к любому полю/методу модуля).
    Хороший пример работы с генераторами кода вы можете найти в этой статье на Medium.


    Отдельно стоит рассказать про F# 5. В новой версии языка добавилась масса классных возможностей для скриптов (например, директива для подключения nuget пакетов), slicing для более удобной работы с данными, а также улучшилась работа с quotation expressions и computation expressions. А еще сильно улучшился интероп с C# и перфоманс. Словом, новый релиз выглядит интересно и делает F# потенциально полезнее в продакшене. Полное описание всех изменений можно найти на сайте Microsoft.


    Коротко — язык оброс разнообразным сахаром. Самое заметное изменение в C# 9 — это записи, но едва ли оно само по себе стоит обновления. С другой стороны, если вы будете обновлять версию дотнета по каким-то другим причинам, то у вас появится новый функционал, делающий язык чуть более мощным. Мелочь, а приятно.

    Прочее


    Помимо глобальных улучшений платформы Microsoft также неплохо поработали над отдельными библиотеками.


    Например, в новой версии дотнета сильно улучшилась поддержка десктопа. WinForms и WPF наконец-то получили все преимущества .NET Core — классный перфоманс, упаковка всего приложения в один .exe, работа без установленного на машине дотнета и… и нет, не кроссплатформенность. Все это работает только под Windows.


    Помимо прочего, для десктопной разработки под Windows также добавили нормальный визуальный дизайнер, тулинг, новые контролы и улучшенную поддержку для старых. Словом — если вы разрабатываете приложения с использованием WinForms или WPF, ваша жизнь станет лучше.


    С кроссплатформенностью все осталось по-прежнему. Релиз MAUI перенесли на .NET 6, а других решений для кроссплатформенного десктопа Microsoft пока не предлагает. Так что продолжаем использользовать Авалонию (или можно обратить свое внимание на Uno Platform — перспективно выглядящий фреймворк для разработки на все и сразу).


    Еще больше улучшений появилось для фулстек веб-разработки с использованием Blazor. Главное из них это улучшения производительности — Microsoft обещают, что WebAssembly версия Blazor ускорится аж в три раза. Одной из основных причин такого роста производительности стал пререндер на стороне сервера. А еще добавили ленивую подгрузку зависимостей, изоляцию CSS/JS в рамках файла, новые контролы и многое другое. В общем, если вы собирались попробовать Blazor, но все никак не доходили руки — сейчас он выглядит куда более production-ready технологией.


    image


    Из оставшихся изменений заметнее всего смотрятся те, которые призваны помочь микросервисам и работе с облачными сервисами в целом. Здесь и уменьшение размеров Docker-контейнеров, и улучшенная поддержка gRPC, и поддержка OpenAPI по умолчанию, и многое другое. Кстати, Azure полностью поддерживает .NET 5 со дня релиза.


    А еще Microsoft выкатили Project Tye, который как раз является инструментом для удобного управления микросервисами. На текущий момент трудно сказать, стоит ли использовать Tye в продакшене, но обратить внимание и поиграться с ним в свободное время определенно нужно.


    Коротко — Microsoft улучшили поддержку отдельных инструментов и добавили приятных фич для облака. Если вы используете WinForms, WPF или Blazor — обновиться определенно стоит.

    Миграция


    Давайте разберемся, насколько сложно будет мигрировать ваше приложение с .NET Core 3 на .NET 5?


    Гайд по миграции от Microsoft говорит нам, что основные сложности в миграции коснутся приложений на Blazor, там произошло много ломающих изменений. Для большинства же остальных приложений понадобится просто обновить версию дотнета в application.json, файл проекта и версии зависимостей. А еще адрес докер-контейнера с .NET 5 немного отличается от соответствующего адреса для .NET 3.1:


    docker pull mcr.microsoft.com/dotnet/core/aspnet:3.1
    docker pull mcr.microsoft.com/dotnet/aspnet:5.0

    Другие отзывы о миграции, которые я смог найти — например, вот этот гайд от Alexandre Malavasi и твит о миграции Fusion от Александра Якунина — тоже говорят, что миграция проходит без каких-то специфических трудностей. Я также не столкнулся с особыми проблемами, пока мигрировал свои проекты и демки на новый дотнет. В любом случае, перед миграцией на новую версию советую внимательно изучить список ломающих изменений. А еще стоит посмотреть доклад про миграцию с .NET Conf.


    Итого


    Подведем итоги. Стоит ли мигрировать на новый дотнет и ради чего?


    Кажется, самое важное, ради чего стоит заморачиваться — это перфоманс. Ускорили практически все и достаточно заметно. Как на низком уровне — через улучшения в GC и JIT — так и на уровне отдельных частей фреймворка. Так что, если вы хотите выиграть в производительности, стоит как минимум попробовать обновить версию фреймворка и замерить, насколько ускорились основные сценарии.


    Другие важные причины для миграции — это улучшения для Blazor и WPF/WinForms. Если вы используете любой из этих фреймворков, стоит попробовать перейти на .NET 5, все же изменения достаточно заметные и полезные. Однако стоит учитывать, что для Blazor миграция выйдет достаточно непростой.


    C# 9 определенно не является серьезным мотивом для переезда на новый дотнет, но принесет с собой приятных обновлений синтаксиса за компанию‎. В то же время и рекорды, и паттерн матчинг добавляют много возможностей сделать код более запутанным — советую обсудить это в команде и решить, как лучше использовать (или не использовать) их в проекте.


    И на этом все! Удачной миграции на новый дотнет. Оставайтесь на связи, мы вернемся с более подробными материалами про современные возможности дотнета.

    Контур
    Делаем веб-сервисы для бизнеса

    Похожие публикации

    Комментарии 99

      +8
      C# 9 определенно не является серьезным мотивом для переезда на новый дотнет


      Узнаю старый-добрый контур.
        +3
        Рано узнавать старый-добрый, я тут всего месяц!
        А вообще — я и впрямь не вижу ничего особо впечатляющего в C# 9. Приятные мелочи, не более.
          +5

          Если вы собираетесь использовать Nullable Reference Types то до C#9 писать обобщённые методы было немного затруднительным.

            +8

            Да, мне тоже очень этот момент понравился.


            А что особенно понравилось, так это что тулчейном .NET 5.0 можно собирать проекты и .NET Core, и .NET Framework, задействуя новые возможности языка. То есть нет смысла ломать проект и менять целевую платформу на .NET 5.0. Достаточно просто обновить компилятор и радоваться жизни.

              +2

              Это так происходит с незапамятных времён начиная с C# 3 разве что кроме Expression, которому нужна поддержка самого .NET.


              Кстати если нужна поддержка старых фреймворком с новыми компиляторами есть замечательный проект
              https://github.com/theraot/Theraot/

                0

                Да много полезного существует. Ещё вот:
                https://www.nuget.org/packages/Microsoft.NETFramework.ReferenceAssemblies/
                Можно компилировать под .NET Framework даже при его отсутствии (есть у меня такой сценарий).

                  0

                  Начиная с .NET 5 SDK, этот нугет нет необходимости указывать — сдк сделает это за вас :)

                0

                Можно указать единственный net5.0 TargetFramework и при этом остаться на .NET Framework 2.0 ;)


                Целевая платофрма не так важна, как TargetFrameworkIdentifier

          +1
          У меня есть проект с WPF, который где то под 4.7, если не 4.6. Оставлено так ради поддержки Windows Vista \ 7.
          Если я обновлюсь на net5, мой проект на WPF сможет запускаться хотя бы на Win7? Ну и сюда же в кучу — WPF на свежих дотнетах теперь требует self-host приложения с кучей длл, нельзя просто exe файл буквально использовать? =)
            +1
            .NET Core 3.1 работала на Win7
              0
              > exe файл буквально использовать?
              Можно, если не использовать self-hosted )
                0
                Ну давайте до конца тогда уж — потребуется установка каких то рантаймов на машину, наверное? WPF работает из коробки, self-host от netcore3 с например avaloniaui после установки свежего vcredist — тоже заводится. Заведется ли так net5 c WPF?
                  +1

                  Лично у меня с net5 были проблемы. В self-contained app то одного не хватает, то другого, то вообще запуститься не в состоянии. А вот при сборке под netcoreapp3.1 работает всегда и везде. Принципиальной разницы между по функционалу net5.0 и netcoreapp3.1 не вижу, поэтому остаюсь на netcoreapp3.1, но с новыми фишками c#9.0

                +2

                Почему нет?
                В плане поддержки системы различий между 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

                +4
                Время установки пакетов (desktop runtime) драматично сократилось, где то в десятки раз. Это же неспроста…
                В связи с этим чисто утилитарные вопросы:
                — Если на голую win7 установить только dot5, то будут ли работать приложения, которые в своих требованиях хотят dot4.x, нативно не представленной в win7?
                — Для x64-сборок достаточно ли установить только x64-инсталлятор, или дополнительно требуется и x86-установка для x86-приложений?
                — Какой из предлагаемых пакетов наиболее полный (не рассматривая SDK-пакет: ASP Core Runtime, Desktop Runtime, Runtime)?
                  0

                  Присоединяюсь к вопросу.
                  Вот только сегодня помогал человеку установить одну софтину (как обычно, простой пользователь сообщения об ошибках не читает никогда, максимум "он там что-то написал, я закрыл, ну и все закрылось"). Сообщение установщика заключалось в том, что ему требуется для установки .NET 4.5, а на Windows 7 на тот момент был установлен 4.8. Проблему удалось решить удалив 4.8 и установив 4.5, затем установив 4.8 обратно. Понятно, что в установщике зачем-то жестко прописано "==" вместо ">=", и сам .NET тут возможно не при чем. Но это просто последний такой случай в моей практике из множества аналогичных, т.е. тенденция имеется, вопрос: сохранится ли?

                    +2
                    .NET Framework — компонент Windows, поэтому нельзя параллельно установить несколько разных версий его. .NET Core / .NET 5 более автономный, вплоть до того, что приложение может таскать его с собой (штатный режим сборки, включается буквально парой ключей) или вообще завернуть в один жирный экзешник (тоже штатный режим).
                      +1
                      Можно. Просто загляни в C:\Windows\Microsoft.NET\Framework
                        +2
                        Ну как я понимаю, есть какая-то мажорная версия фреймворка, которая с собой для совместимости таскает некоторый набор предыдущих версий. Насколько мне известно, невозможно параллельно установить несколько мажорных версий .NET Framework (4.5 и 4.8, к примеру, как в ситуации выше по треду). Я не настоящий сварщик, так что выводы сделал по пользовательским ситуациям, подобным описанным выше, когда приходилось удалять и устанавливать разные версии фреймворка, чтобы заставить работать приложение.
                          +1
                          Формально да — 2.Х и 4.Х. Но по факту 4.Х действительно только один.
                            0
                            Еще отдельная 3.5
                              +1
                              Ноу, 3.5 это расширение 2.Х. Там хитрая система с тем что часть фреймворка в этом случае лежит в 3.5 директориях а часть в 2.Х. Но при этом формально на машине будет стоять 3.5 и 4.Х.
                      +1
                      1) Если под «голой» win7 вы подразумеваете Windows 7 SP1 без единого установленного обновления — то dot5 у вас установится, но приложения работать не будут, пока вы не поставите обновление KB2533623 (ныне доступно только через Web Archive) или его заменитель KB3063858 (доступно на сайте MS) — обсуждение на github
                      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)
                        0
                        Спасибо, всё ясно.
                        1) эти обновления в системе есть.
                        2) Да, это я тоже замечал, проблема появилась после dotnet 4.6.2. Я добавлял сертификаты через политики.
                        3)- я не девелопер, просто потребитель и мне неизвестно, что заложено в приложении. Судя по ответу — да, нужно устанавливать оба x64+x86, если система 64, для всех вариантов (возможных) приложений. И впридачу, крайняя 4.х версия тоже необходима.
                          0
                          3) Для ОС x64 минимально необходимый набор — это .NET Farmework 4.8 и .NET 5.0 x64. (т. к. подавляющее большинство приложений собирается в конфигурации Any CPU — на OC x64 приложение тоже будет x64). Но чисто теоретически ничто не мешает разработчику собрать приложение в конфигурации x86 — для таких (довольно редких) случаев вам всё же придётся поставить и .NET 5.0 x86.
                      +2
                      Какой из предлагаемых пакетов наиболее полный (не рассматривая SDK-пакет: ASP Core Runtime, Desktop Runtime, Runtime)

                      Не совсем корректный вопрос, потому что
                      ASP.Net Core Runtime = Net Runtime + поддержка ASP.Net
                      Desktop Runtime = Net Runtime + поддержка десктопного UI
                        +3
                        Другие отзывы о миграции, которые я смог найти — …

                        На мой взгляд, лучшую статью на тему миграции на .NET 5.0 написал Rick Strahl.

                          +2
                          И впрямь отличная, спасибо!
                          +8
                          В регулярных выражениях помимо увеличения производительности, также исправили серьезную ошибку совместимости с ECMAScript. В предыдущих версиях .NET при создании регулярных выражений с флагом RegexOptions.ECMAScript возникали ошибки при разборе шаблонов, содержащих следующий символьный класс – [^] (например, ^(\s*)([^]*\S)(\s*)$). Данная ошибка создавала множество проблем при работе с JavaScript-движками, написанными на чистом .NET (Jint, Jurassic и NiL.JS).
                            +3
                            На самом деле, каждая версия дотнета исправляет большое количество ошибок и это радует.
                            Хотя каждая и добавляет новых. Например, в чате DotNetRu рассказали, что кое-где новая версия дотнета вызвала заметное падение производительности.
                          +2
                          C# 9 определенно не является серьезным мотивом для переезда на новый дотнет

                          Добавлю. Новый шарп — это в основном синтаксические накрутки, генерируемый IL не изменяется. Например, record — это на самом деле класс под капотом. А значит можно использовать многие фичи девятого шарпа даже на netstandard2.0.


                          Для этого вам нужно написать следующий костыль где-нибудь.


                          Либо почитайте пост от автора Nullables, который сделал nuget-пакет для этой же цели (чтобы использовать девятый шарп в < 5 версиях)


                          У меня есть проект (библиотека), таргетящий 2.0, и при этом использующий девятый шарп. Очень удобно

                            +1
                            генерируемый IL не изменяется

                            Разве это не основной смысл иметь IL не привязанный к языку? Или вы хотите, чтобы была версия .NET с изменённым IL?
                              0

                              Ну а как добавлять какие-то вещи типа generics? Или вот DIM (default interface member)? Хотя про последнее не уверен, может это только от рантайма зависит

                                +1
                                Если что-то можно добавить без внедрения несовместимого IL — назовите хоть одну причину почему это не добавить без внедрения несовместимого IL?
                                Generics требовали переделки архитектуры, но это было очень давно, когда C# был молод и когда ещё не был основательно продуман.
                                И то, что практически все новые фичи под капотом являются просто сахаром, это однозначный плюс — если что непонятно, всегда можно заглянуть под капот и понять что как работает.
                              +1

                              Так можно говорить про каждую версию и остаться в итоге на net20 ;)


                              Теже рекорды особо не нужны, когда можно было просто использовать ValueObject. Но всеже, в каждом релизе, что-то да новое есть, например аттрибут ModuleInitializer или SkipLocalsInit, поднимающие версии рантайма. Да и всякий синтаксический сахар, все-таки, упращает читаемость кода. Поэтому как-то неочень ультимативно заявлять, что новая версия языка, рантайма или SDK ничего не приносит

                                +1
                                Теже рекорды особо не нужны, когда можно было просто использовать ValueObject.

                                Вы бы исходники того проекта хотя бы почитали. Как proof-of-concept — норм, но в продакшн я бы и на пушечный выстрел такое не подпустил.

                                  0

                                  Речь больше шла о реализации IEquatable<T>

                                    +1

                                    Я её и имею в виду. Там оно сделано через рефлексию со всеми её минусами.

                                      0

                                      Это опенсорс решение. У кого есть желание, может улучшить предложенный вариант. И кажется, что этот репозиторий будет хорошей песочницей перед тем, как предложить свои измнения в код, который используется в проде

                                        0

                                        Ну конкретно этот метод — затычка, он не нуждается в оптимизации, потому что вы не можете в пользовательском коде унаследоваться от System.ValueType. От него неявно наследуются типы-структуры, но если вы структуры сравниваете через object.Equals(), то вы делаете что-то не так.


                                        Да, теоретически можно было бы его расширить и на пользовательские классы, добившись той же логики сравнения, что и для структур, но зачем это нужно, когда ввели более эффективные рекорды?

                                  +1
                                  Так можно говорить про каждую версию и остаться в итоге на net20

                                  Я на нем и остаюсь (если вы не про core2.0 или боже упаси второй fw).
                                  ValueObject выполняет другую задачу. С рекордами вы получаете возможность построить граф из коробки. Ну и паттерн матчинг.


                                  ValueObject обычно для небольших оберток, я никогда не видел структуры, которая достаточно самостоятельна и выполняет какую-то ключевую задачу.

                                    +4
                                    Я на нем и остаюсь (если вы не про core2.0 или боже упаси второй fw).

                                    Про легаси. Речь шла больше про те проекты, где не находят применения новым возможностям по каким-либо причинам. Больше удручает, когда это проиводит к затяжному застою без каких-либо проблем в применимости


                                    С рекордами вы получаете возможность построить граф из коробки

                                    С таким не приходилось связываться, поэтому не могу оценить о чем идет речь :)


                                    Для меня, пока что, рекорды убирают бойлерплейт, связанный с реализацией IEquatable<T>

                                • НЛО прилетело и опубликовало эту надпись здесь
                                  –2

                                  Можно расходится, снова nodejs Electron программисты будут тыкать пальцем и смеяться над кроссплатформенностью .Net. Майкрософт, ну как так???


                                  P.S. Не надо писать про сторонние фреймворки типа авалонии — куда смотрят мелкомягкие??? 2021 год на носу, а они нам дальше консольку и веб парят. А я так ждал гуй из коробки...

                                    +2
                                    Кроссплатформенный GUI обещают в .NET 6, MAUI. Но да, не в этой версии.
                                    Кстати, можно поучиться у тех самых nodejs Electron программистов и пользоваться Electron.NET. На все той же .NET Conf был неплохой доклад про это.
                                      +2

                                      Да, обещают уже давно. И в 5ке обещали.
                                      Авалония вполне годный вариант. Вопрос в развитии продукта от самого майкрософта. Обидно ж.

                                      0
                                      Это те ребята у которых хело волд занимает полгектара в памяти и пару сотен метров на диске?..
                                      +2
                                      Индийский сахар какой-то. Как-то мало полезного из синтаксиса.
                                        +7
                                        Как по мне — и фиг бы с ним, с синтаксисом. C# и без того мощный язык, а вот перфоманса и багфиксов много не бывает.
                                          +1
                                          Как по мне, сейчас главная проблема .NET — не язык, в котором уже столько сахара, что жопа слипается (и бойлерплейты не страшны, благодаря стандартным практикам, кодогенератору и автодополнению). Главная проблема — это плодящийся зоопарк: .NET Framework, .NET Standard, .NET Core, Mono, Xamarin, UWP… Без политуры новичку уже и не разберёшь за что браться, что устарело, а что ещё слишком ново.
                                            0

                                            Да ладно новичку… Вот решил вспомнить и попробовать утилиту сделать… И выходит что winforms живее всех живых среди мёртвых а на чём начинать на будущее непонятно.

                                              0

                                              Мне на ARM64 нужны были интерфейсы, в том числе блютуз, и конечно формочки. Пощупал .NET 5 и перешёл на Qt. Там тоже есть вопросы, но вроде пока всё решаемо...

                                              0
                                              Поэтому и подводят всё к одному .NET. Часть названных это фреймворки для разработки под мобилку, десктоп-планшеты.
                                              .NET Standard — просто общая API для всего этого зоопарка. С зоопарком JS'а ничего не сравнится.
                                                0
                                                Я-то знаю и я нарочито смешал всё до кучи.
                                                А так — сравнивать с худшими не повод для радости. Старый .NET был хорош именно тем, что это была единая среда с разными версиями, а весь «зоопарк» состоял из WinForms vs WPF, ну и Mono где-то рядом бегал и пытался не отставать. Хочешь создавать что-то новое — создаёшь на последней версии и не паришь себе мозг.
                                                (окей, да, я явно лукавлю, т.к. если делается dll расширения для старых приложений, то выбора что использовать не было — только старый фреймворк)
                                            0
                                            Вот да. А фундаментальные недостатки некоторые так и не решены: generic арифметика и классы типов.
                                            +8
                                            — Чем отличается инсталляция от перфоманса? Если ты, допустим, насрал человеку под дверь, а потом уже позвонил в звонок – это инсталляция. А вот если ты сначала человеку позвонил, а когда он вышел из квартиры, то ты сел перед ним и насрал, – это уже перфоманс.


                                            А в программировании как-то всё больше скорость вычислений или производительность.

                                            Еще любят генерацию вместо поколений использовать почему-то.
                                              +2
                                              А что будет, если таргет будет старый (netstandard2.0, например), а рантайм новый? Плюшки по производительности будут? Или всё-таки IL-код оптимизируется ещё новым тулчейном?
                                              Ну или совсем гулять — новым тулчейном компилять под netstandard2.0 и запускать на новом рантайме.
                                              На всякий случай, отвечу на вопрос зачем: если не надо новых фич, то в целом повышать версию выглядит бессмысленно, бывает легаси и прочие замороженные проекты, которые нет смысла переводить на новый фреймворк, а зависимости свежие использовать хочется.
                                                +1

                                                .NET Standard — это лишь API. Ему можно подсунуть любой удовлетворяющий рантайм. .NET — это продолжение идей .NET Standard. Поэтому, если вам не нужны фичи из .NET, то можете смело оставаться на стандарте


                                                When to target net5.0 vs. netstandard

                                                  +3
                                                  Это я понимаю, но вопросы были в следующем:
                                                  1. Будет ли прирост производительности просто от подсовывания нового рантайма
                                                  2. Не вылезут ли проблемы из-за того, что совместимость именно что декларируется. Т.е. могут взять метод и убрать у него реализацию (типа у нас новые правила) или изменить реализацию, что приведёт к косякам. А то у нас был весёлый пример с использованием рантайма 2.2 при разработке на 2.1. Несколько недель поиска проблемы.
                                                    +1
                                                    Насколько я понимаю — в обоих случаях ответ ДА.
                                                    Но убирать реализацию врядли будут, скорее наоборот — добавят для каких то вещей.
                                                    ПС: мне казалось, net core 3 уже целиком реализовывал стандарт? Остались методы без реализации, но заявлены в стандарте?
                                                      0
                                                      Похоже, всё-таки не всё будет гладко.
                                                      Вот сейчас выяснил, что сломали Thread.Abort
                                                      Т.е. код начнёт эпично валиться в непредсказуемых местах. И вот сколько таких мест может быть?
                                                        +1
                                                        МС не рекомендовали им пользоваться со времен появления тасок =)

                                                        Более того, работать с ним было намного неудобнее, чем с тасками.

                                                        Да, кому то обновление будет не бесплатно. Но судя по МСДН — будет варнинг, кто пользуется — должны быть внимательнее.
                                                          +1
                                                          Он по-другому работает. Таска сама проверяет, что её попросили сдохнуть и делает всё для этого, а это насильное убийство. Нужно обычно как средство последнего шанса, но бывают ситуации, когда очень нужно.
                                                          При компиляции ворнинг будет, но изначально вопрос был в том — что просто поставили новый фреймворк и взяли старый код. Тут, похоже, будет очень неприятно.
                                                      +8
                                                      1. Будет ли прирост производительности просто от подсовывания нового рантайма

                                                      Моя библиотека, поддерживающая .NET Standard 2.1, стала быстрее работать на 20-25% при запуске под .NET 5.0 вместо .NET Core App 3.1.



                                                        0

                                                        Вопрос: а с чем это связано? С оптимизациями при JIT-компиляции или же с новыми версиями библиотек?

                                                          0
                                                          Думаю, что и с тем, и с другим, потому что в моей библиотеке используется много регулярных выражений.
                                                  –6
                                                  а где полная статья по миграции с 3 на 5?
                                                  или опять 100 системных файлов править руками по пиксельно?
                                                    +3

                                                    В статье упущены значительные улучшения single-file applications — почти полностью ушли от распаковки файлов во временную директорию, скорость первого запуска в связи с этим заметно увеличилась.

                                                      +2
                                                      Измерения перфоманса
                                                      Таки сложно написать «измерения производительности»? Тем более что данный англицизм имеет в русском языке совершенно другое устоявшееся значение.
                                                        +1
                                                        еще Microsoft выкатили Project Tye, который как раз является инструментом для удобного управления микросервисами. На текущий момент трудно сказать, стоит ли использовать Tye в продакшене, но обратить внимание и поиграться с ним в свободное время определенно нужно.


                                                        странная любовь MS к таким названиям, не то кириллица, не то латиница… То бот-расист Tay (Тэй или Тау?), теперь Туя какая-то…
                                                          –1

                                                          А что шарписты про Dart скажут. Плюсы/минусы какие?

                                                            0
                                                            С точки зрения шарписта, есть некоторое количество WTF.
                                                            Например, встречал инфу, что «void возвращает null», хотя во второй версии говорят void это вообще тип.
                                                            Или отсутствие явных интерфейсов, а не явно каждый class это интерфейс. То есть один и тот же класс, можно как наследовать, так и имплементировать =)

                                                            С точки же прикладной, dart похоже выстрелил только на мобилках как flutter, соответственно Dart — язык одного фреймворка. Как в свое время Ruby с Ruby on Rails. Хотя сейчас есть бетка flutter под десктоп, мб и на десктопе выстрелит.
                                                            0

                                                            Есть инфа, на Юнити C# 9 скоро можно использовать будет?

                                                              0
                                                              В бете 2020.2 только поддержку C# 8 добавили, можно посмотреть в роадмапе
                                                              0
                                                              Мы вот Utf8JSON прикрутили давно, и рады. Он сразу в Stream льет, без промежуточных этапов в виде UTF16-строк.

                                                              Но вообще, в мире заботы о экологии и энергопотреблении, давно уже пора заменить JSON чем-нибудь менее расточительным. А то всякие возобновляемые источники ставят, и прочее. Чтобы потом в датацентрах процентов 30 сжигать чисто на преобразование в этот уродливый формат.

                                                              Меня, лично, останавливает исключительно отсутствие минимальной поддержки в Chrome Dev Tools. Если кто-нибудь прикрутит preview какого-нибудь BSON в Network-табе — я сразу начну свои аппы переводить. А в идеале — сразу брать что-нибудь типа AVRO, чтобы уже два раза не вставать.
                                                                +4
                                                                Стоит отметить, что .NET 5 это не LTS версия, если это для кого-то важно dotnet.microsoft.com/platform/support/policy/dotnet-core
                                                                  0
                                                                  Похоже на бету. Ждем LTSC, хотя я думаю, недолго
                                                                  0
                                                                  Вот чем мне нравится современный МС, так это стремлением всё упростить и сделать удобнее.
                                                                  Вот есть у меня маленькая консольная утилита, ей ничего особо не нужно для работы, под старый фреймворк я ее компилил очень сложным устаревшим путем вызова csc.exe /target:exe dup.cs /r:… (ну и там всякие фреймворковские длл, не суть). На выходе получался -exe файл в той же папке, что и -cs.

                                                                  Теперь же у нас всё просто! Нет csc — нет проблем.
                                                                  1.Сначала надо сделать csproj файл (100500 настроек, наслаждайтесь комбинированием)
                                                                  2. потом дернуть dotnet build, который сгенерирует 2 папки, с 4 подпапками.в каждой, десяток доп-файлов и наслаждайтесь чтением доков, чтобы это все как-то привести к старому неудобному результату работы csc.exe, ага

                                                                  … потратил больше двух часов гуглежа на это все — останусь-ка я, пожалуй, на старом фреймворке.
                                                                    +1

                                                                    Только что попробовал: csc из .NET 5.0 по-прежнему прекрасно компилирует код из одного файла.


                                                                    Сначала надо сделать csproj файл

                                                                    dotnet new console

                                                                      0
                                                                      Да-да, так я его и сгенерировал в итоге. Пришлось правда долго и упорно гуглить, ведь я искал аналог csc — а его там больше нет.
                                                                      Ну и я ж и не говорю, мой проект не скомпилировался и не заработал в итоге.
                                                                      Просто по-старому я это делал одной командой имея на руках 1 .cs файл и получая на выходе 1 .exe файл. Итого — 2 (ну ладно, три — третьим идет .bat с вызовом csc, чтобы не вспоминать потом правильный набор ключей и не дергать справку).
                                                                      Теперь же нужно обязательно иметь .csproj (и + тот самый bat файл), который фиг настроишь самостоятельно (ключей — много) и на выходе вы еще и обязательно получите кучу вспомогательных файлов/папок. Да, там есть команда для авторазвертывания в целевую папку, но это всё равно никак не решает проблемы возникновения кучи доп. файлов.
                                                                      Ну т.е. если раньше я мог накодить эксперимент чуть ли не в блокноте, скомпилить его и пользоваться, то теперь мне надо сначала настроить практически полноценное окружение (а еще лучше — не париться и взять Visual Studio, которой MS прямо тычет на каждой странице про dotnet и его инсталлятор).
                                                                      Юзабилити.

                                                                      P.S.: и да, я сначала установил сам дотнет 5ый, без sdk, в итоге dotnet new console проект-то мне сделал, но после смены там на net5.0 сказал, что у него лапки и компилировать отказался. Пока я не скачал еще и sdk-инсталлятор. Замечу, что предыдущие версии (начиная с первой!) работали и компилировали сразу после установки, являясь цельной средой.
                                                                        +1
                                                                        оторый фиг настроишь самостоятельно

                                                                        Эмм, вот весь 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/

                                                                          0
                                                                          Эмм, вот весь 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
                                                                    0

                                                                    del

                                                                      0
                                                                      По-моему, релиз сырой. У меня C# компилятор выдаёт internal compiler error на новых указателях на функции:
                                                                      delegate* unmanaged<RefStruct>
                                                                      Перестали работать части NonCopyableAnalyzer, тоже из-за внутренних ошибок Roslyn.

                                                                      П.С. Всё зарепортил уже.
                                                                        0
                                                                        Как обстоят дела с Win7? Ставится?
                                                                        0
                                                                        > Релиз MAUI перенесли на .NET 6
                                                                        Не перенесли, а изначально планировали на .NET 6, пруф
                                                                          0

                                                                          А GUI на Linux (X11) не планируется шоли? "As we consider what building device applications will look like in a unified .NET, we see many devices across multiple platforms used, from Android and iOS to Windows and macOS." Ага, еще плагин для тиктока интегрировали бы...

                                                                            0
                                                                            Там вроде MAUI под линукс будет community supported, как с xamarin.
                                                                            Да и зачем это делать микрософту, когда десктопный UI под линукс и так существует?
                                                                          0

                                                                          Кстати, насчёт производительности. Сравнил следующий код на 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# уже вполне можно писать производительный код?

                                                                            0
                                                                            Год назад C# отставал от C++ в этом тесте почти в 2 раза, сейчас — практически паритет. Получается, C++ не нужен, и на C# уже вполне можно писать производительный код?
                                                                            Можно, только надо еще с GC моменты учитывать.
                                                                              0

                                                                              Ну если рассматривать обработку изображений, то частых выделений памяти там нет. Только большие куски памяти под сами изображения, которые целесообразнее выделять в unmanaged памяти.

                                                                                0
                                                                                Вот только фактически, ты не управляешь этими моментами, как только вышло за пределы твоего кода.

                                                                                Есть GC, или нет, сам ты не контролируешь. Дернул стандартную библиотечную ф-цию и все.
                                                                            0

                                                                            Пока Designer не допилят, WinForms под 5.0, к сожалению, не готов к реальной разработке. Мы сделали пробное портиррование нашего немаленького продукта и все на удивление завелось без больших проблем. Там и тут чутка подпилить да подстучать и все работает. Но застопорились на двух проблемах:


                                                                            • Дизайнер сырой на удивление, хотя и заявленно, что обкатали его вместе с большими производителями контролов. И что, никто не пробовал иконки из глобальных русурсов использовать? https://github.com/dotnet/winforms/issues/3958
                                                                            • Stimulsoft Report, который мы используем для отчетов, под Core не умеет в Compile. Придется видимо отчеты переделывать.

                                                                            Кто-то пробовал новый Designer в формах с приличным колличеством контролов? Он у вас такой же медленный? У меня после клика контрол фокусируется раздражающе меделенно.

                                                                              –1
                                                                              а кто в курсе, какие планы по поводу новой студии? чет не удалось нагуглить сходу. хочется закупиться, но свежей, дабы побольше сохранить актуальность…
                                                                                0
                                                                                А комьюнити издание не устраивает?

                                                                                Мне хватает на все задачи.
                                                                                  0
                                                                                  ну это для коммерческой организации.
                                                                                    0
                                                                                    Попробуйте Rider. Он сильно дешевле студии и решарпер ещё бонусом идёт.

                                                                              Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                              Самое читаемое