День восемьсот четвёртый. #ЗаметкиНаПолях
Что такое Debugger.Launch?
Допустим, вы запускаете приложение (например, веб-приложение или службу Windows), в котором есть startup метод, который вы хотите отладить. Часто это может быть настройка внедрения зависимостей, раннее чтение файла конфигурации или что-то подобное. Допустим, вы не можете просто нажать F5 в Visual Studio и начать отладку. Вам нужно запустить приложение, а потом подключить отладчик. Для веб-приложений это иногда связано с тем, что вы используете IIS и переходите по URL-адресу своего приложения. А службу Windows, вы хотите отладить, когда она на самом деле исполняется как служба Windows.

Можно добавить в нужное место кода Thread.Sleep(10000); и попытаться подключить отладчик, в течение этого времени. Но гораздо проще это сделать с помощью:
System.Diagnostics.Debugger.Launch();

Тогда, если вы запустите приложение (не через отладку из Visual Studio), то, когда исполнение дойдёт до этой строчки, появится диалоговое окно, где вам будет предложено выбрать отладчик для этого приложения. Можно выбрать Visual Studio, и приложение откроется в режиме отладки.

А что насчёт Debugger.Break()?
Этот метод также использовался для начала отладки. Но, как говорится в документации Microsoft, начиная с .NET Framework 4, если не выбран отладчик, то не гарантируется, что метод Break приведёт к вызову окна выбора отладчика. Вместо этого в систему отчётов об ошибках Windows (WER) направляется сообщение об ошибке. Таким образом, документация советует для старта отладчика использовать Debugger.Launch.

Если же отладчик уже подключен, Debugger.Break заставляет код останавливать выполнение так же, как и точка останова. Так что в некотором смысле это похоже на точку останова, которую могут использовать разработчики на разных машинах вместо ручной инструкции: «Поместите точку останова в строку XX файла YYY…». Это может показаться не очень полезным, кроме случая, который мы рассмотрим далее.

Когда Debugger.Launch не работает
В очень редких случаях Debugger.Launch не предлагает пользователю отладить код. Либо требуется отладка в приложении, не представленном во всплывающем окне. Тогда есть простое решение:

// Ждём подключения отладчика.
while(!System.Diagnostics.Debugger.IsAttached)
{
  Thread.Sleep(100); //либо Task.Delay()
}
System.Diagnostics.Debugger.Break();

Если отладчик не подключен, программа ожидает его подключения в бесконечном цикле. После подключения отладчика цикл будет прерван, и мы продолжим выполнение. Debugger.Break немедленно останавливает выполнение и действует как точка останова, позволяя нам начать пошаговое выполнение кода, если мы хотим.
Этот код можно обернуть в конструкцию

#if DEBUG
…
#endif

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

Источник: https://dotnetcoretutorials.com/2021/04/03/i-wish-i-knew-about-debugger-launch-earlier/

День восемьсот пятый.
Microsoft Azure Virtual Training Day: DevOps with GitHub
Рекомендую посетить очередной бесплатный вебинар из серии Microsoft Azure Virtual Training Day. На нём расскажут, как использовать GitHub для управления рабочими процессами и сокращения цикла разработки. Пошаговые инструкции по добавлению элементов управления качеством и безопасностью в процесс сборки, а также по улучшению уведомлений и ответов для обеспечения согласованной и повторяемой автоматизации.

Темы мероприятия:
- Использование GitHub для улучшения совместной работы и производительности команды.
- Интеграция средств контроля безопасности и качества в конвейеры автоматизации, непрерывной интеграции и непрерывной доставки (CI/CD) и среды выполнения.
- Внедрение передовых методов, чтобы помочь удаленным командам разработчиков повысить отказоустойчивость программного обеспечения.

Вебинар пройдёт в 2 дня:
Среда, 21 апреля 2021, 11:00-13:55 Мск.
Четверг, 22 апреля 2021, 11:00-13:10 Мск.
Язык: Английский, доступны русские субтитры.

Регистрация по ссылке: https://mktoevents.com/microsoft+event/247969/157-gqe-382

Большая техническая конференция о .NET-разработке начинается уже на следующей неделе.

DotNext 2021 — 20-23 апреля, онлайн.

4 дня, несколько десятков докладов и воркшопов от авторов популярных технологий и инструментов, живое общение со спикерами и коллегами и многое другое.

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

✅ Посмотреть всю программу и купить билет со скидкой можно на https://bit.ly/3dYUGJk

Промокод на Personal-Standard билет: netdevdiary2021JRGpc
Промокод на Full Pass билет: JugRuCommunityBonus – это если решите посмотреть все конференции сезона 😉

День восемьсот седьмой.
FluentValidation
Сегодня предлагаю вам посмотреть полезное видео - запись вебинара «OSS Power-Ups: FluentValidation». Это первый вебинар из серии Open-Source Power-Ups про популярные проекты с открытым исходным кодом в сообществе .NET.

FluentValidation - это библиотека для создания строго типизированных правил валидации, пользующаяся огромной популярностью и имеющая более 50 миллионов загрузок на NuGet. Джереми Скиннер, поддерживающий проект, поможет нам начать работу с некоторыми базовыми примерами, написанием пользовательских валидаторов, локализацией сообщений об ошибках и интеграцией валидации в ASP.NET Core.

День восемьсот восьмой. #ЗаметкиНаПолях
Как Посмотреть Параметры Конфигурации в ASP.NET
Существует простой способ раскрыть конфигурацию приложения как конечную точку в вашем приложении ASP.NET Core.

GetDebugView() - это метод расширения IConfigurationRoot, который возвращает строку, описывающую конфигурацию приложения. В этой строке отображаются все ключи конфигурации в вашем приложении, связанное значение и источник значения.

Рассмотрим пример «стандартного» вывода метода GetDebugView():

AllowedHosts=* (JsonConfigurationProvider for 'appsettings.json' (Optional))
applicationName=temp (Microsoft.Extensions.Configuration.ChainedConfigurationProvider)
ASPNETCORE_ENVIRONMENT=Development (EnvironmentVariablesConfigurationProvider)
ASPNETCORE_URLS=https://localhost:5001;https://localhost:5000 (EnvironmentVariablesConfigurationProvider)
Logging:
  LogLevel:
    Default=Information (JsonConfigurationProvider for 'appsettings.json' (Optional))
MySecretValue=TOPSECRET (JsonConfigurationProvider for 'secrets.json' (Optional))
…

Некоторые особенности вывода:
1. Параметры конфигурации выдаются в алфавитном порядке ключей.
2. Формат строки:

Ключ=значение (источник значения)

Например:
- Ключ AllowedHosts имеет значение * и предоставлен из файла appsettings.json провайдером JsonConfigurationProvider.
- Ключ MySecretValue имеет значение TOPSECRET и предоставлен из файла пользовательских секретов secrets.json.
3. Строка отформатирована по разделам, что видно по ключу Logging, содержащему раздел LogLevel, в котором находится ключ Default.
4. Прочие провайдеры конфигурации:
- ChainedConfigurationProvider – первоначальные значения конфигурации, задаются хостом,
- EnvironmentVariablesConfigurationProvider – переменные среды,
- CommandLineConfigurationProvider – параметры командной строки.

Заметьте, что значения одного провайдера могут переписывать значения другого (например, значения из appsettings.json заменяются значениями из секретных данных или переменных среды). В выводе GetDebugView() будет присутствовать только конечное значение.

Применение
Информация, предоставляемая GetDebugView(), может быть очень полезной, когда вам нужно отладить проблему конфигурации в вашем приложении. Возможность точно увидеть, откуда берется значение конфигурации, крайне важно, когда что-то работает не так, как вы ожидаете.

Один из очевидных подходов - предоставить конечную точку в приложении ASP.NET Core, где вы можете запросить это представление. В следующем примере использован метод MapGet для предоставления простой конечной точки:

app.UseEndpoints(endpoints => {
  if(env.IsDevelopment()) {
    endpoints.MapGet("/debug-config", ctx => {
      var config = 
        (Configuration as IConfigurationRoot)
        .GetDebugView();
      return ctx.Response.WriteAsync(config);
    });
  }
});

Источник: https://andrewlock.net/debugging-configuration-values-in-aspnetcore/

День восемьсот девятый. #Оффтоп #97Вещей
97 Вещей, Которые Должен Знать Каждый Программист
84. Мыслите Состояниями
У людей в реальном мире странные понятия состояний. Утром я зашёл в кофейню, чтобы подготовиться к очередному дню преобразования кофеина в код (купить латте). Но девушка ответила: "Извините, у нас вообще, совсем нет никакого молока, ни капли."

С точки зрения программиста это странное заявление. Когда дело доходит до наличия или отсутствия молока, это нельзя измерить. Молоко либо закончилось, либо нет. Возможно, она пыталась сказать мне, что у них не будет молока всю неделю, но результат был бы тот же – сегодня я пью эспрессо.

В большинстве реальных ситуаций такая вольная трактовка состояний людьми не является проблемой. Но, к сожалению, многие программисты также неряшливо обращаются с состоянием программ. А это уже проблема.

Рассмотрим простой интернет-магазин, который работает только по предоплате. Класс заказа, может содержать такой метод:

public bool IsComplete() => IsPaid() && HasShipped();

Вроде логично. Но, даже если это выражение аккуратно извлечено в метод, а не продублировано повсюду, такого выражения не должно существовать вообще. Тот факт, что оно существует, говорит о проблеме. Почему? Потому что заказ не может быть отправлен до оплаты. Таким образом, HasShipped() не может быть true, если IsPaid() не true, что делает эту часть выражения избыточной. Возможно, вам всё равно нужен метод IsComplete() для ясности кода, но тогда он должен выглядеть так:

public bool IsComplete() => HasShipped();

В своей работе я постоянно встречаюсь как с недостаточными, так и с избыточными проверками. Этот пример крошечный, но, если добавить сюда отмену заказа и возврат денег, он станет более сложным, и потребность в хорошей обработке состояния возрастёт. В нашем случае заказ может находиться только в одном из трёх состояний:
- В обработке: можно добавлять или удалять элементы. Нельзя отправлять.
- Оплачен: нельзя добавлять или удалять элементы. Возможна отправка.
- Отправлен: Готово. Больше никакие изменения не доступны.

Эти состояния важны, т.к. нужно убедиться, что:
1. вы находитесь в ожидаемом состоянии, прежде чем выполнять операции,
2. вы можете перейти только в одно из доступных состояний.
То есть, вы должны тщательно защитить свои объекты в нужных местах.

Но как начать мыслить состояниями? Извлечение выражений в осмысленные методы - очень хорошее начало, но это только начало. Основа - понимание конечных автоматов. Я знаю, что у вас могут возникнуть плохие воспоминания об уроках информатики, гоните их прочь. Конечные автоматы не так трудны. Визуализируйте их, чтобы сделать их простыми для понимания и обсуждения. Протестируйте свой код, чтобы выявить допустимые и недопустимые состояния и переходы и сохранить их правильность. Изучите паттерн Состояние, почитайте про программирование по контракту. Оно поможет вам обеспечить допустимое состояние, проверяя входящие данные и сам объект при входе и при выходе из каждого публичного метода.

Если ваша программа находится в неправильном состоянии, - это ошибка, и вы рискуете испортить данные, если не прервёте операцию. Если вы обнаружите, что проверки состояния вносят в код слишком много шума, изучите возможности IDE, генераторы кода или аспектное программирование (weaving), чтобы скрыть их. Независимо от того, какой подход вы выберете, мышление состояниями сделает ваш код более простым и надёжным.

Источник: https://www.oreilly.com/library/view/97-things-every/9780596809515/
Автор оригинала – Niclas Nilsson

День восемьсот десятый. #ЧтоНовенького
.NET 6: Новые Структуры Даты и Времени
Давняя проблема библиотеки базовых классов .NET заключается в невозможности раздельного представления значений даты и времени. Новые структуры .NET 6 DateOnly и TimeOnly призваны исправить это упущение.

Как следует из названия, они предназначены для хранения только даты и только времени соответственно. Таким образом, они отвечают принципу SRP в том смысле, что не могут играть разные роли (раньше DateTime использовалась для хранения и только даты, и только времени, и даже интервалов).

Исходное имя структуры DateTime было просто Date. Это всё ещё справедливо для VB, где ключевое слово Date продолжает ссылаться на DateTime. Таким образом, название DateOnly было выбрано, чтобы избежать путаницы. Другая причина заключается в том, что DateTime.Date возвращает значение DateTime. Это уже нельзя изменить, но новички часто ожидают, что это свойство возвращает только дату. Поэтому новое свойство, возвращающее DateOnly, можно назвать DateTime.DateOnly.

Точно так же имя TimeOfDay проблематично, поскольку многие свойства и методы используют его для ссылки на значение DateTime или TimeSpan.

Сериализация
DateOnly и TimeOnly не будут реализовывать атрибут Serializable. В .NET Core и более поздних версиях этот атрибут считается устаревшим, как и библиотеки сериализации, которые на него полагаются.

Был запрос на атрибут IXmlSerializable и его эквивалент в для JSON. Однако DateOnly и TimeOnly должны быть помещены в одну из библиотек нижнего уровня NET, где такие атрибуты недоступны. Таким образом, сериализаторам необходимо будет включить собственную обработку этих новых типов. Такое же изменение придётся сделать и в драйверах баз данных.

Это может привести к тому, что после выпуска .NET 6 в течение какого-то времени нельзя будет использовать DateOnly и TimeOnly в некоторых сценариях, пока сериализаторы не подстроятся.

DateTimeOnly

Пытаясь решить проблему часового пояса, .NET 2 представила свойство DateTime.Kind. Разработчики имели возможность аннотировать свои значения даты и времени с помощью флага, указывающего, представляет ли значение местный часовой пояс, всемирное координированное время или неуказанный часовой пояс. На самом деле это привело к тому, что разработчики были вынуждены указывать эту информацию или сталкиваться с неожиданными ошибками.

Что еще хуже, свойство Kind использовалось непоследовательно. Например, многие сериализаторы, видя его, добавляли смещение при экспорте значения. Это приводило к трудно диагностируемым ошибкам, поскольку только некоторые даты (например, полученные из DateTime.Now) сериализовывались со смещением. А операторы сравнения полностью игнорировали Kind. Предполагалось, что разработчик сам проверит свойство Kind и при необходимости выполнит преобразование часового пояса.

Чтобы устранить эти проблемы, есть запрос на новую структуру DateTimeOnly, которая в основном работает так же, как DateTime в .NET 1 (т.е. дата и время без указания часового пояса).

Источник: https://www.infoq.com/news/2021/04/Net6-Date-Time/

День восемьсот одиннадцатый.
5 Советов по Снижению Затрат в Azure
Давненько я не рекомендовал видео от Тима Кори. Вот вчера он выпустил довольно интересный ролик «5 Cost-Saving Tips for Azure»

Как разместить полноценный сайт на Azure всего за 1 цент в месяц? Как снизить стоимость MSSQL с тысяч долларов в месяц до нескольких десятков долларов? Как найти и убрать ненужные сервисы или установить лимит месячного бюджета? В видео нет особых откровений. В принципе, большинство материала упоминается в курсе Microsoft Learn по Azure, но есть и некоторые нюансы, который могут быть полезны.

День восемьсот двенадцатый. #ЧтоНовенького
Visual Studio 2022
Этим летом выйдет первая предварительная версия Visual Studio 2022. Её обещают сделать более быстрой, доступной, легкой и впервые в истории 64-разрядной. Пользовательский интерфейс будет более чистым, интеллектуальным и ориентированным на продуктивность.

64-битная VS 2022 больше не будет ограничена 4ГБ памяти для основного процесса devenv.exe. Теперь вы сможете открывать, редактировать, запускать и отлаживать даже самые большие и сложные решения, не исчерпывая памяти. Хотя Visual Studio переходит на 64-разрядную версию, это не меняет типа или разрядности приложений, которые вы создаёте с её помощью.

Разработка современных приложений
Azure
VS 2022 позволит быстро и легко создавать современные облачные приложения в Azure. Для начала работы вы сможете использовать большое количество репозиториев, описывающих общие шаблоны, используемые в современных приложениях. Эти репозитории состоят из проверенного кода, показывающего эти шаблоны в действии, ресурсов Azure, а также предварительно настроенных рабочих процессов и действий GitHub, подготавливающих для вас полноценное решение CI/CD сразу при создании проекта. Кроме того, в репозитории будет определена необходимая среда разработки, чтобы вы могли сразу приступить к кодированию и отладке.

.NET
Visual Studio 2022 будет иметь полную поддержку .NET 6 и его единой платформы разработки веб-, клиентских и мобильных приложений как для Windows, так и для Mac. Это включает в себя .NET MAUI для кроссплатформенных клиентских приложений в Windows, Android, macOS и iOS. Вы также можете использовать веб-технологии ASP.NET Blazor для написания настольных приложений через .NET MAUI. Кроме того, для большинства типов приложений вы сможете использовать .NET Hot Reload для применения изменений кода без необходимости перезапуска и без потери состояния приложения.

Диагностика и отладка
VS 2022 будет включать улучшения производительности в основном отладчике с дополнительными функциями, такими как диаграммы нагрузки в профилировщике для помощи в определении горячих путей, зависимые точки останова для более точной отладки и интегрированные возможности декомпиляции, которые позволят вам выполнять по шагам даже код, которого у вас фактически нет.

Сотрудничество в реальном времени
Live Share представит интегрированный текстовый чат, чтобы вы могли быстро обсуждать свой код без переключений контекста. У вас будет возможность запланировать повторяющиеся сеансы с повторным использованием одной и той же ссылки, что упростит совместную работу с вашими частыми контактами. Чтобы лучше поддерживать Live Share в организациях, также появятся политики сеансов, содержащие любые требования для совместной работы.
VS 2022 также будет включать новую мощную поддержку Git и GitHub. Появится много встроенной логики и контрольных точек, которые помогут вам эффективно пройти процесс слияния и проверки.

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

Как всегда, вы можете перейти в новое сообщество разработчиков, чтобы просмотреть существующие запросы функционала, проголосовать и прокомментировать их или предложить свою идею.

Источник: https://devblogs.microsoft.com/visualstudio/visual-studio-2022/

День восемьсот тринадцатый. #МоиИнструменты
Обработка Изображений в Вашем Репозитории GitHub
ImgBot - удобный бот, который вы можете добавить в свой репозиторий GitHub. Он бесплатный для проектов с открытым исходным кодом. Его задача - сжимать изображения, чтобы они были оптимизированы для отображения в интернете (то есть ваш сверхширокий снимок экрана размером 8МБ, который должен отобраться на странице блога с разрешением 600x200, не сожрёт много трафика).

Каждый раз, когда вы делаете коммит в основной репозиторий, ImgBot действует как CI-процесс и проверяет, есть ли в коммите изображения, которые он может обработать. Если изображения есть, он их сожмёт и сделает пул реквест с оптимизированными изображениями.

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

Настройка
Добавьте ImgBot в свой GitHub репозиторий, используя GitHub Marketplace и настройте план (бесплатный для проектов с открытым исходным кодом). Как только вы предоставите ImgBot доступ к своему репозиторию, он просканирует его и отправит вам серию пул реквестов. По умолчанию он использует сжатие без потерь, поэтому не беспокойтесь, что он испортит ваши красивые изображения.

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

Что по ценам
Как сказано выше, он бесплатный для проектов с открытым кодом. Однако, если у вас есть закрытый проект, в котором вы хотели бы его использовать, можете посмотреть расценки. На момент написания поста это 10 долларов в месяц для индивидуальной лицензии для личных проектов и 30 долларов в месяц для организаций.

Источник: https://ardalis.com/add-imgbot-to-github-repository/

День восемьсот четырнадцатый. #ЗаметкиНаПолях #GC
Топ Вопросов о Памяти в .NET. Начало 1-4
Вчера в нашем чате поделились интересной ссылкой на тест по организации памяти в .NET. Кому интересно попробовать свои силы перед тем, как читать дальше - https://quiz.dotnetmemoryexpert.com/

1. Что чаще всего вызывает сборку мусора в приложении .NET?
Наиболее распространённой причиной является случай, когда вы выделяете объект, и (грубо говоря) для него не хватает места. Таким образом, если приложение не выделяет новых объектов, есть небольшая вероятность, что сборки мусора вообще произойдёт. Вот почему вы могли слышать о zero-allocation коде. Такой код имеет хорошую производительность не только потому, что он не использует аллокации, но также значительно снижает вероятность сборки мусора и связанных с этим накладных расходов. А знать о том, когда происходит выделение памяти и избегать ненужных выделений - один из наиболее важных навыков при написании требовательного к памяти и производительности кода.

Другой, менее распространенный триггер сборки мусора - когда операционная система замечает нехватку доступной памяти. Она передаёт так называемое «уведомление о нехватке памяти», и различные программы могут реагировать на него (или игнорировать его). Среда выполнения .NET реагирует запуском сборки мусора, а также переключением в «режим низкого потребления памяти», что приводит к более агрессивному освобождению памяти.

Очевидно, что вызов GC.Collect может (или не может, в зависимости от его параметров) запускать сборку мусора. Но такие вызовы довольно редки, как и другие, менее распространённые триггеры.

2. В .NET 5 и Blazor (WebAssembly) одинаковые алгоритмы сборки мусора?
Blazor WebAssembly, начиная с .NET 5, работает на Mono (изначально написанном на C), но компилируется в WebAssembly. Таким образом, поскольку среда выполнения совершенно другая, она имеет и другой сборщик мусора. Хотя в будущем всё может измениться, потому что Mono интенсивно развивается и активно экспериментирует (например, в использовании «основного сборщика мусора» .NET).

3. Что означает так называемая «полная» сборка мусора?
При полной сборке мусора сборщик обрабатывает все поколения в SOH, а также LOH и POH (добавленной в .NET 5). Поэтому такую сборку следует воспринимать как самую «дорогую» с точки зрения загрузки памяти и процессора. В хорошо работающем приложении это должно происходить заметно реже, чем сборка в поколениях 0 и 1.

В настоящее время существует 2 варианта полной сборки мусора: параллельная и уплотняющая. Может выполняться один из вариантов, но не оба вместе. Параллельная (или фоновая) является наиболее распространённой и предпочтительной, поскольку приводит к коротким паузам, что не сильно влияет на поведение приложения. Но память при этом не сжимается, что приводит к фрагментации: свободному пространству, которое не всегда можно использовать повторно. Если фрагментация станет сильной, может начаться уплотняющая полная сборка мусора, которая может привести к длительным паузам в работе приложение. В противном случае процесс будет потреблять всё больше и больше памяти.

4. Что такое «кризис среднего возраста»?
Под «кризисом среднего возраста» мы понимаем нарушение так называемых гипотез поколений, на которых построены все «поколенческие» сборщики мусора (в том числе и .NET). Они подразумевают, что большинство объектов умирают молодыми, и что существует небольшая группа объектов, живущих долго. «Если объект молодой, он, вероятно, скоро умрёт. Если он живет долго, он, вероятно, проживет ещё дольше».

Поэтому объект, живущий достаточно долго, чтобы считаться «старым», а затем умирающий, нарушает это правило. Это негативно влияет на поведение сборщика мусора, которое настроено на противоположное поведение: чаще собирать мусор в молодых поколениях и реже в старых. «Кризис среднего возраста» - одна из наиболее распространённых проблем с памятью .NET, которая вызывает более высокую загрузку процессора и паузы.

Продолжение следует...

Источник: https://dotnetmemoryexpert.com

День восемьсот пятнадцатый. #ЧтоНовенького
.NET 6: Улучшения в Асинхронности
Из более, чем сотни изменений, предложенных для выпуска в .NET 6 сегодня рассмотрим наиболее существенные, относящиеся к асинхронному программированию.

Новые методы WaitAsync
Хотя в идеале все асинхронные функции подразумевают возможность отмены операции, иногда эта возможность не предоставляется. Для этих случаев в классы Task и Task<TResult> были добавлены три новых метода WaitAsync:

public Task WaitAsync(CancellationToken cancellationToken);
public Task WaitAsync(TimeSpan timeout);
public Task WaitAsync(TimeSpan timeout, CancellationToken cancellationToken);

Как следует из сигнатуры, эти методы используют отмену по таймауту и/или по токену отмены. Любой из них может использоваться для прекращения ожидания завершения асинхронной операции. Обратите внимание, что это не означает прерывания самой операции. Операция может продолжаться, даже если вызывающий код её больше не ожидает.

На заметку: Microsoft теперь считает ошибкой значения таймаута в виде целых миллисекунд. В дальнейшем все значения таймаута должны быть выражены исключительно как TimeSpan.

Многоразовый CancellationTokenSource
Когда запускается операция, инициируемая извне, например веб-запрос, часто требуется создать CancellationTokenSource. Это позволяет обработчику запросов прерываться, если запрашивающая сторона отменяет запрос, разрывается соединение и т. д. Однако в большинстве случаев запрос не отменяется, то есть CancellationTokenSource не используется.

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

Новый метод CancellationTokenSource.TryReset исправляет это, отключая все старые токены от CancellationTokenSource. Таким образом, любая отмена новой операции не сможет повлиять на предыдущие операции. Старые токены будут существовать, но не смогут получать сообщения от этого CancellationTokenSource.

Название TryReset использовано из-за того, что повторно использовать можно будет только неиспользованный объект CancellationTokenSource. То есть, если на этом объекте уже была вызвана отмена операции, придётся создать новый. Использование будет примерно таким:

if (!cts.TryReset())
  cts = new CancellationTokenSource();

События отмены
Один из способов определить, что была запрошена отмена, - зарегистрировать делегат через CancellationToken.Register. Он будет выполнен при отмене, либо немедленно, если к моменту регистрации токен уже в состоянии отмены. Иногда этому делегату требуется доступ к используемому токену. Новая перегрузка CancellationToken.Register предложит эту возможность:

public CancellationTokenRegistration Register<T>(Action<T, CancellationToken> callback, T state);
public CancellationTokenRegistration UnsafeRegister<T>(Action<T, CancellationToken> callback, T state);

UnsafeRegister отличается тем, что не захватывает контекст исполнения.

Источник: https://www.infoq.com/news/2021/04/Net6-Async/

День восемьсот шестнадцатый.
FluentAssertions
Сегодня предлагаю вам посмотреть второе видео из серии Open-Source Power-Ups про популярные проекты с открытым исходным кодом в сообществе .NET.
Запись вебинара «OSS Power-Ups: FluentAssertions».

FluentAssertions - это обширный набор методов расширения, который позволяет более естественно описывать ожидаемый результат модульных тестов в стиле TDD или BDD. Деннис Думен, создатель этой библиотеки, поможет вам начать работать с FluentAssertions, а также расскажет о некоторых не самых известных нюансах использования.

День восемьсот семнадцатый. #ЗаметкиНаПолях
Тестирование Исключений с Помощью xUnit и Action
Когда вы пишете модульные тесты для метода, рекомендуется тестировать различные условия отказа («печальные пути») в дополнение к проверке того, что всё работает («счастливого пути»). В частности, если у вас есть метод, который может генерировать исключения, особенно если это пользовательские типы исключений, специфичные для вашего домена, вы должны быть уверены, что тестируете это поведение. Другой распространённый источник исключений - это защитные предложения, которые используются для поддержания чистоты вашего метода и обеспечения того, чтобы входные данные соответствовали ожиданиям метода.

В отличие от NUnit и MSTest, которые в основном используют атрибуты для ожидаемых исключений, xUnit предоставляет метод Assert.Throws<T>, который используется для проверки ожидаемых исключений (в NUnit3 также появился аналогичный метод):

Customer customer = null;
Assert.Throws<NullReferenceException>(
   () => customer.LastName);

Кроме того, метод возвращает пойманное исключение, которое можно обработать:

var ex = Assert.Throws<NameRequiredException>(
   () => customer.UpdateName("", ""));
Assert.Equal("Имя не задано", ex.Message);

Arrange, Act, Assert и Исключения
Многие тесты используют шаблон тестирования AAA (Arrange, Act, Assert – Настройка, Действие, Утверждение). Проблема с предыдущим примером в том, что перехват исключения метода относится как к блоку Act, так и к блоку Assert. Кроме того, эта строка получается слишком длинной.

В этом случае для строгого следования шаблону AAA делегат для Assert.Throws можно выделить в отдельную переменную типа Action:

[Fact]
public void ThrowsExceptionGivenInvalidName {
  // Arrange
  var customer = new Customer();
  // Act
  Action act = () => customer.UpdateName("", "");
  // Assert
  var ex = Assert.Throws<NameRequiredException>(act);
  Assert.Equal("Имя не задано", ex.Message);
}

Теперь блок Действие явно содержит нужную операцию, а строка Assert.Throws гораздо короче и понятнее.

Заметьте также, что имя теста явно говорит о том, что тест выбрасывает исключение и при каких условиях.

FluentAssertions
Об этой библиотеке подробно было рассказано во вчерашнем видео. Если вы используете её, то код утверждения будет выглядеть примерно так:
[Fact]
public void ThrowsExceptionGivenInvalidName {
// …

// Assert
action.Should()
.Throw<NameRequiredException>()
.WithMessage("Имя не задано");
}

Источник: https://ardalis.com/testing-exceptions-with-xunit-and-actions/

День восемьсот восемнадцатый. #ЧтоНовенького
Эпик Фейл при Демонстрации Горячей Перезагрузки в Blazor
Во время прямой трансляции мероприятия ASP.NET Community Standup на тему «Обновления ASP.NET Core в .NET 6 Preview 3» Дэниел Рот, главный программный менеджер ASP.NET столкнулся с неожиданной проблемой при демонстрации одного из самых ожидаемых нововведений - Blazor Hot Reload.

Около четырех минут на глазах тысяч зрителей Рот пытался победить подготовленный пример. Рот и ведущий Джон Гэллоуэй изучали новые функции ASP.NET Core, обещанные в .NET 6, выпуск которого запланирован на ноябрь.

В сегменте горячей перезагрузки Blazor Дэниэл демонстрировал, как можно вносить изменения в код, чтобы результаты мгновенно отражались в работающем приложении с сохранением состояния приложения. Он показал, как с помощью dotnet watch некоторые типы изменений кода, которые не поддаются горячей перезагрузке, по умолчанию автоматически перезагружались, обеспечивая бесперебойную работу.

Однако внезапно возникла странная ошибка невозможности записи файла, которую Рот и Гэллоуэй какое-то время пытались победить при помощи комментариев от публики. Рот даже зашёл в диспетчер задач и убил один из процессов .NET, пообещав, что «нам не придётся этого делать».

Всё веселье начинается на 43й минуте ролика (ссылка выше).

Помимо горячей перезагрузки, которую обещают распространить на все виды приложений .NET, Джон и Дэниэл рассматривают и другие нововведения в .NET 6:
- MAUI
- улучшения в производительности .NET
- нативную облачную разработку
- изменения в MVC (теперь рабочий сайт можно создать буквально в 3 строчки кода)
- одностраничные приложения
- улучшения в производительности Blazor Webassembly
и многое другое.

Источник: https://visualstudiomagazine.com/articles/2021/04/23/epic-fail.aspx?m=1

День восемьсот девятнадцатый. #TipsAndTricks
Когда-то давно я писал про горячие клавиши в Visual Studio. Кроме того по тегу #TipsAndTricks можете поискать другие полезные советы. А сегодня расскажу вам о некоторых фишках Visual Studio Code. В конце концов, это самый популярный редактор кода.

Горячие клавиши
- для Mac
- для Windows
- для Linux

Если вы фанат лигатур посмотрите на бесплатные Fira Code и Cascadia Code.

Полезные расширения
1. Emmet
Это плагин для многих популярных текстовых редакторов, позволяющий генерировать стандартные блоки HTML и CSS.

2. Quokka.js
Предпросмотр значений переменных и функций JS и TypeScript во время набора кода.

3. Bracket Pair Colorizer
Подсветка соответствующих скобок разными цветами.

4. Live Server
Локальный сервер для предпросмотра создаваемых веб-страниц.

5. Settings Sync
Позволяет синхронизировать настройки, темы, иконки, горячие клавиши и т.п. на разных машинах с помощью GitHub Gist.

6. Prettier Extension
Тонкая настройка форматирования кода на разных языках.

7. Polacode
Позволяет быстро делать скриншоты кода и обрабатывать их.

8. Better Comments
Выделяет разные типы комментариев: TODO, важные замечания, документацию и т.п.

9. Markdown Lint
Проверка оформления и стилей документов MarkDown.

10. VS Code Icons
Содержит несколько коллекций иконок.

Красивые темы
1. Cobalt 2
2. Night Owl
3. One Dark Pro
4. Dracula Official
5. Winter is Coming
6. Shades of Purple
7. Material Theme
8. Rainglow

День восемьсот двадцатый. #ЗаметкиНаПолях #GC
Топ Вопросов о Памяти в .NET. Продолжение 5-8
Начало 1-4

5. Какие ограничения на размер занимаемой памяти у приложений .NET?
Ограничения размера приложения .NET такие же, как у любого процесса, ограниченного виртуальным адресным пространством - объемом памяти, который может быть выделен, исходя из разрядности приложения. И хотя в настоящее время подавляющее большинство операционных систем являются 64-битными, мы всё ещё можем компилировать/запускать наши программы и как 32-, и как 64-битные. То же самое относится к среде выполнения .NET, выполняющей наше приложение .NET. См. также про 64-битную VS 2022.

32-битному приложению может быть выделено до 4 ГБ памяти, но по умолчанию половина его предназначена для операционной системы Windows, а половина - для самого приложения. Таким образом, ограничение по умолчанию составляет 2 ГБ. Однако в случае 64-битной Windows мы можем запускать 32-битные приложения в так называемом режиме обработки больших адресов (Large Address Aware), который позволяет выделять больше памяти - около 3 ГБ. Этот флаг, например, используется при размещении 32-разрядных приложений ASP.NET Framework внутри IIS. В Linux действуют аналогичные ограничения. Таким образом, около 2 или 3 ГБ - это предел для 32-разрядного приложения .NET.

64-битному приложению теоретически можно выделить до 16 ЭБ (эксабайт!) памяти. В настоящее время большая часть оборудования использует только 48 бит для выделения верхних и нижних 128 ТБ всего адресного пространства (для операционной системы и приложения). Это предел для приложений .NET.

6. Что такое LOH (Large Object Heap)?
Куча больших объектов - это специальная часть управляемой кучи. С самого начала .NET порог по умолчанию для обработки объекта как «большого» составляет 85000 байт. Недавно добавилась возможность увеличить этот лимит. Каждый большой объект выделяется в LOH и остаётся там до тех пор, пока не будет собран мусор.

LOH отделён от SOH (Small Objects Heap – кучи малых объектов), потому что «большие» объекты имеют другие характеристики: их создание и перемещение (сжатие) памяти может повлечь за собой большие накладные расходы. Поскольку ожидается, что таких объектов будет немного, затраты на их размещение выше (включая очистку памяти и некоторые накладные расходы на многопоточную синхронизацию). Т.к. нет другого способа очистки LOH, кроме полной сборки мусора, если ваше приложение часто размещает большие объекты и приводит к нехватке памяти, оно может приводить к дорогостоящим полным сборкам мусора.

7. Для чего нужна утилита dotnet trace?
dotnet trace - это один из инструментов командной строки (CLI) для сбора различных «диагностических трассировок» процесса .NET. Вы можете использовать три предопределенных профиля:
- cpu-sampling - выборка профилировщика CPU для наблюдения за использованием процессора,
- gc-collect - отслеживание высокоуровневых данных сборщика мусора с очень низкими накладными расходами,
- gc-verbose – то же, что выше, плюс грубая выборка распределения объектов. Созданная трассировка может быть затем открыта в Visual Studio или в инструменте PerfView.

8. Для чего нужна утилита dotnet gcdump?
dotnet gcdump - еще один инструмент диагностики, который может запускать сборщик мусора и записывать специальные диагностические данные, выдаваемые во время него. Это позволяет создавать «gcdump» - не обычный дамп памяти, содержащий всю или часть памяти процесса, а «диагностический снимок» состояния управляемой памяти. Он включает информацию о том, какие управляемые объекты были обнаружены и собраны во время сборки мусора (без содержания этих объектов). Поэтому «gcdump» намного меньше, чем снимок всей памяти, потребляемой процессом. Его можно проанализировать в Visual Studio или PerfView (включая информацию об отношениях между объектами).

Продолжение следует…

Источник: https://dotnetmemoryexpert.com

День восемьсот двадцать первый. #ВопросыНаСобеседовании
4 Частых Ошибки на Собеседовании
Всех с предпраздничной пятницей, дорогие подписчики. На сегодня приготовил вам тему для обсуждения. Основан пост на недавно вышедшем видео Клемента Михайлеску, который какое-то время проработал интервьюером в Google. Его список ошибок основан на личном опыте. Понятно, что наш опыт может отличаться от тамошнего, поэтому добро пожаловать в комментарии. Продолжайте список того, чего не стоит делать на собеседовании.

Приведённые ниже ошибки относятся к решению задач на собеседовании. Они общие для всех интервью и не затрагивают каких-то узких технических моментов.

1. Излишняя болтливость
Коммуникабельность очень важна для программиста. Важно умение выражать и доносить свои мысли. Но всё хорошо в меру. Не стоит озвучивать все свои мысли. Беспорядочный поток сознания собьёт интервьюера. Сообщать нужно уже готовые, «продуманные» мысли. Даже если вас просят озвучивать ваши размышления, лучше попросите минуту-другую и отсейте хотя бы самые бредовые идеи, озвучив лучшее, что сможете придумать.

2. Угадывание
Разновидность первой ошибки: если застрял - вываливать всё, что знаешь. То есть вместо объяснения, что конкретно вызывает затруднение, предлагать беспорядочный набор известных вам структур данных, алгоритмов, библиотек и т.п., которые могу иметь, но чаще всего не имеют никакого отношения к решению задачи.
Интервьюеру важнее понять, насколько вы можете мыслить логически. Его вряд ли впечатлит простой перебор всего, что вы знаете. Это скорее наведёт его на мысль, что вы вообще не понимаете, о чём говорите. Лучше выбрать хоть сколько-нибудь подходящий вариант решения и объяснить, почему вы его выбрали, даже если он в итоге окажется неверным.

3. Спешка в написании кода
Это также часто случается и в работе. Не стоит, решая задачу, бросаться писать какой-нибудь код. Чаще всего код при этом получается плохо структурированный, непонятный и с кучей ошибок. В результате рано или поздно запутаетесь и вы, и интервьюер. Опять же, попросите минуту-другую времени, продумайте структуру программы. Здесь может очень помочь Процесс Программирования с Псевдокодом.

4. Недопонимание
Опять же, частая ошибка и в обычной работе – недопонимание задачи. На собеседовании лучше переспросить, правильно ли вы поняли задачу. Приведите пару примеров возможных входных данных, и что должно получиться в результате, чтобы чётко определиться, что вы с интервьюером понимаете друг друга. А также убедиться, что вы решаете ту задачу, которую вас просят решить, а не тратите время, решая то, что вам показалось. Помимо этого, подбор парочки примеров может помочь вам найти решение задачи.

Источник: https://youtu.be/nf6vrGcGDSI

День восемьсот двадцать второй. #Юмор

Помните эту шутку на первое апреля? Так вот, в Stack Overflow заморочились и решили реально посчитать, как часто люди копипастят код с их сайта. Получилось, что каждый четвертый посетитель сайта, копирует что-то в течение пяти минут после перехода на страницу.

Так что, перестаньте корить себя за копирование кода! Зачем изобретать велосипед, если всю тяжелую работу уже проделал кто-то другой? Этот сайт основан на повторном использовании знаний.

Вы можете использовать предыдущий опыт других для создания новых ценных вещей. Вы всё равно должны следовать некоторым правилам, чтобы предотвратить проникновение ошибок в ваш код или проблемы с безопасностью при копировании. Поэтому убедитесь, что вы понимаете, что делаете, прежде чем копировать что-то. Несмотря на это, Stack Overflow призывают всех делиться преимуществами того, что создано сообществом.

Источник: https://stackoverflow.blog/2021/04/19/how-often-do-people-actually-copy-and-paste-from-stack-overflow-now-we-know

День восемьсот двадцать третий.
Snoop
Сегодня предлагаю вам посмотреть третье видео из серии Open-Source Power-Ups про популярные проекты с открытым исходным кодом в сообществе .NET.

Запись вебинара «OSS Power-Ups: Snoop»

Snoop - это швейцарский армейский нож, когда дело касается анализа пользовательского интерфейса в WPF. В отличие от диагностики XAML внутри Visual Studio, его можно легко установить и использовать на любом компьютере - даже на сайте заказчика - без сложной установки. Бастиан Шмидт, нынешний сопровождающий проекта, даст нам хорошее представление о нём. В видео показано, как просматривать и изменять значения свойств, проверять триггеры из стилей и шаблонов, диагностировать ошибки привязки представлений и другие распространенные ошибки в WPF, устранять неполадки в событиях и выяснять, где они обрабатываются, предварительно просматривать и масштабировать части пользовательского интерфейса (даже в 3D) и многое другое.