Релиз .NET 6 вышел достаточно громким – если вы пишете под эту платформу, то навряд ли могли пропустить такое событие. Мы тоже не смогли пройти мимо и решили проверить, что интересного удастся найти в исходном коде библиотек .NET.

До сих пор в этой серии я рассматривал новые минимальные API хостинга, созданные с использованием WebApplication и WebApplicationBuilder. Они обеспечивают более простую модель для создания веб-приложений, сохраняя при этом те же общие функциональные возможности, что и приложения .NET Core 3.x/5 на основе универсального хоста.

Однако c этим упрощением есть проблемы. Более сложный код запуска в ранних версиях, обычно разделённый между Program.cs и Startup, имел преимущества, так как он предоставлял хорошо известные точки расширения (hooks), которые инструменты могли использовать для перехвата процесса запуска приложения.

Классическим примером этого является инструментарий EF Core^*EN. Если вы когда-либо использовали EF Core, возможно, вы знакомы с проблемами, возникающими при попытке изменить код запуска. А уж когда фреймворк меняет свой код запуска по умолчанию, понятно, что без проблем не обойтись!

Часть 1. ConfigurationManager
Часть 2. WebApplicationBuilder

В предыдущем посте я сравнивал новый WebApplication с универсальным хостом. В этом посте я рассмотрю код, лежащий в основе WebApplicationBuilder, чтобы увидеть, как он обеспечивает более чистый, минимальный API хостинга, при этом обеспечивая ту же функциональность, что и универсальный хост.

В свое время я случайно узнал, что исключения в моём горячо любимом языке C# — и, как следствие, во всем .NET — не все ведут себя одинаково. Причём, что ещё гораздо интереснее, далеко не все и не всегда могут быть обработаны и перехвачены. Что, казалось бы, полностью противоречит интуитивному восприятию конструкции try-catch-finally. 

Изучая этот вопрос, я находил всё новые и новые исключения среди исключений, которые оказывались «сильнее», чем конструкция try-catch-finally. К тому моменту, когда мой список вырос до 7 пунктов, я внезапно осознал, что нигде не было такого места, где можно было бы найти их все сразу. Максимум — 2 или 3 случая, рассмотренных в одной статье. 

Это и подтолкнуло меня к написанию данной статьи. 

Часто бывает так, что эффективная коммуникация – один из основных движущих факторов в современных программных системах, даже в мире, живущем по законам микросервисной архитектуры. Технология gRPC может справляться с этими требованиями. В этой статье будут рассмотрены некоторые основы gRPC, а еще мы реализуем первое клиент-серверное приложение с применением .NET. Кроме того, клиент на основе Python демонстрирует, насколько эффективной может быть коммуникация между различными сервисами.

Всем привет! Меня зовут Илья Никулин, с марта 2021 года я руковожу командой по развитию EMM-системы «Магнита». Каждый, кто решает рабочие задачи с помощью мобильных устройств, знает, что для большой компании важно «не тормозить»: быстро доставлять точную информацию покупателям, сотрудникам, поставщикам. А еще все корпоративные устройства нужно постоянно обслуживать. Именно Enterprise Mobility Management-системы позволяют удаленно управлять мобильными устройствами, отслеживать их работу и получать безопасный доступ к корпоративным информационным ресурсам.

Мы продолжаем поддерживать и внедрять инновации в среду выполнения Windows Forms. В этой статье обсудим, что мы сделали в рамках .NET 6.0. В том числе среди улучшений: улучшения и исправления специальных возможностей; начальная загрузка приложения; обновления шаблона; больше конструкторов среды выполнения; высокий DPI и улучшения масштабирования и другое.

По материалам статьи Esther Xin «Prevent SQL Server Dump Generation in Hot Cases: Common Ways & Scenarios»
14 ноября 2021г.
В этой статье будут описаны способы предотвращения создания дампа SQL Server для наиболее часто встречающихся видов исключений. В промышленной среде это позволит продержаться до решения проблемы, в случае, когда генерация дампов сильно мешает нормальной работе. Подразумевается, что у вас уже есть файл дампа, пригодный для расследования RCA. Также, вы должны быть уверены, что причиной создания дампов является одно и то же исключение, о чём говорит одинаковый стек вызовов для потока, приведшего к дампу.

В продуктиве, особенно когда SQL Server является частью кластера (SQL AG или FCI), в качестве быстрого решения для защиты от сбоев, вызванных процессом генерации дампа, поддержка Майкрософт может предложить рассмотреть возможность отключения процесса создания дампа.
Главной опасностью того, что файл дампа не будет генерироваться после того, как произойдёт исключение, является невозможность дальнейшего поиска и устранения проблем на основании содержащейся в дампе информации. Кроме того, само отключение возможности создания дампа не может избавить от возникновения исключения в процессе SQL Server. Применяя этот метод, будьте осторожны и учитывайте возможные риски, связанные с тем, что отсутствие дампов может ввести в заблуждение при оценке состояния сервера. Обязательно согласуйте отключение дампов со всеми заинтересованными сторонами, прежде чем вносить какие-либо изменения.
Конечно, увеличение тайм-аута проверки статуса сервера и тайм-аута проверки работоспособности может быть альтернативным вариантом реакции на череду дампов, но в типичном продуктиве в случае аварии, когда требуется быстрый отклик и быстрая отработка отказа, такой вариант не подходит (нежелательно ждать генерации дампа перед отработкой отказа или длительное создание дампа само может стать причиной отработки отказа).
Ниже показаны несколько флагов трассировки, которые позволяют отключить создание дампа в наиболее часто встречающихся случаях. В других случаях, следует обратиться к документации Майкрософт, которая описывает соответствующие флаги трассировки и поведение сервера после их включения.

Вот уже в десятый раз подряд открывает свои двери Клуб анонимных Дедов Морозов.

Идея совершенно проста:

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

Завершающая часть перевода статьи о внутреннем устройстве MS SQL Server – здесь будут разобраны блокировки, процесс записи изменённых данных, а также дополнительные команды SQL Server.

SqlBulkCopy можно использовать в трех вариантах: вставка данных, представленных в виде DataTable, массива DataRowили IDataReaderэкземпляра. В этой статье я продемонстрирую две реализации IDataReaderинтерфейса, которые используются в сочетании с SqlBulkCopyвысокопроизводительной вставкой в ​​базу данных. Два других варианта похожи друг на друга и могут использоваться для относительно небольших объемов данных, поскольку они требуют, чтобы все записи были предварительно загружены в память перед их передачей SqlBulkCopy. Напротив, этот IDataReaderподход более гибкий и позволяет работать с неограниченным количеством записей в «ленивом» режиме, что означает, что данные могут передаваться SqlBulkCopyна лету так быстро, как сервер может их использовать. Это аналогично подходу IList<T>vs.IEnumerable<T>.

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

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

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

О лицензировании MS SQL по подключениям (CAL)

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

Проблемы с производительностью, такие как аномально низкая скорость работы и высокое потребление памяти, могут быть обнаружены самыми разными способами. Такие недостатки приложения выявляются тестами, самими разработчиками или тестировщиками, а при менее удачном раскладе – пользователями. Увы, но обнаружение аномалий – лишь первый шаг. Далее проблему необходимо локализовать, ведь в противном случае решить её не получится. Тут возникает вопрос – как найти в большом проекте причины, приводящие к излишнему потреблению памяти и замедлению работы? Есть ли они вообще? Быть может, дело и не в приложении вовсе? Эта статья посвящена истории о том, как разработчики C#-анализатора PVS-Studio столкнулись с подобной проблемой и смогли решить её.