
В .NET 9 появилась новая библиотека для кэширования — HybridCache. В статье расскажу, что это такое, какие задачи решает, разберу примеры использования и особенности внутреннего устройства.
User
В .NET 9 появилась новая библиотека для кэширования — HybridCache. В статье расскажу, что это такое, какие задачи решает, разберу примеры использования и особенности внутреннего устройства.
Долгое время в метод Contains(), который используется в Entity Framework для фильтрации данных по списку значений, не вносили изменения. До выхода Entity Framework 8 коллекция с этим методом внутри оператора запросов where LINQ транслировалась в значения в виде констант внутри оператора IN для SQL. Если количество элементов равно одному, то преобразование происходило в выражение с оператором ‘=’ на стороне MS SQL Server. Аналогично транслируется и метод расширения Where() LINQ.
Использование в EF8 функции OPENJSON
устраняет часть проблем с кэшем планов запросов для SQL Server, но не применимо к старым версиям (compatibility level) баз данных. Да и оптимальность генерируемого ею кода в некоторых случаях вызывает сомнения.
В недавно вышедшем Entity Framework 9 добавили больше настроек для возможности транслирования метода Contains()
коллекций как с помощью OPENJSON, так и «по-старому» — в виде констант.
Сегодня мы поделимся неожиданным решением, которое перевернуло наше представление о тестировании в C# проектах. Скажем только одно: мы кое-что позаимствовали у фронтендеров — и это избавило нас от проблем с тестами навсегда. Что за трюк? Читайте дальше!
Примерно пару назад я открыл для себя великолепный инструмент в арсенале разработчика под названием Docker. Вкратце, Docker — это открытая платформа для разработки, доставки и эксплуатации приложений. Сам Docker работает по принципу виртуализации, то есть каждое приложение представляет из себя виртуальный образ, который помещается в контейнер. Docker использует возможности операционной системы создавать изолированные контейнеры. Контейнер отличается от виртуальной машины тем, что контейнер не эмулирует железо и использует операционную систему хоста.
С помощью Docker, приложение будет безопасно изолированно в контейнере. Есть возможность управлять и ограничивать характеристики контейнера такие как CPU, Memory и другие, а также мониторить производительность и затрачиваемые ресурсы.
Возможности Docker достаточно обширны, однако в данной статье хотелось бы остановиться на трех:
В прошлой статье мы рассмотрели чрезвычайно популярный инструмент для выкатки приложений Jenkins. Мы подружили его через плагины с SSH, с GitHub, построили простой пайплайн с помощью Groovy. И вроде все здорово, все работает как должно, но все равно есть ощущение, что можно сделать лучше. И действительно, наш процесс можно улучшить, перестав проводить сборку на VPS.
Ранее для сборки мы использовали агент Jenkins, который был установлен на нашем хостинге, где и происходила сборка приложения и его выкатка. Конечно, в реальных проектах существует больше одного боевого сервера, существуют промежуточные серверы – тестовые, демо, стейдж. Не всегда и везде, конечно, но когда у вас несколько серверов, то и сборку приложений можно проводить на каких-то промежуточных, а после всех тестов и проверок, рабочее собранное приложение доставлять до прода. Но у нас все по простому, сразу в прод и агент был там же.
В этой статье предлагаю воспользоваться альтернативным подходом – собирать наше приложение, не покидая репозиторий, никаких дополнительных программ, и никаких агентов. Одним из таких инструментов является GithubActions, который позволяет создавать пайплайн деплоя и настроить доставку приложения на хостинг различными способами.
При чтении логов из базы данных, а именно, из LDF данных, в большинстве случаев вы наткнётесь на такие функции в запросе sys.fn_dblog(null, null), sys.fn_dblog_xtp(null, null)
Читать из LDF Вы захотите по различным причинам, но так или иначе основная проблема будет «у нас откуда‑то списались деньги остатки, пропал товар, упал прод, разберитесь».
Допустим, Вы захотите воскресить удалённый, дропнутый объект из базы.
Типичный скрипт
Добро пожаловать на первый выпуск нашего дайджеста, посвященного новостям и событиям в мире .NET! Команда C# разработчиков из PVS-Studio собрала для вас самые интересные и полезные материалы, чтобы держать вас в курсе последних тенденций и разработок. Поехали!
Привет, Хабр! Меня зовут Давид, я C#-разработчик в SimbirSoft. В современном программировании эффективное управление ресурсами и контроль за выполнением задач становятся ключевыми аспектами для создания надежных и масштабируемых приложений. В C# одним из важнейших инструментов в для достижения этих целей является механизм Cancellation Token. Эта концепция позволяет разработчикам изящно и безопасно управлять долгосрочными или ресурсоемкими операциями, обеспечивая возможность их отмены по требованию.
В этой статье мы погрузимся в мир Cancellation Token в C#, исследуя его роль, принципы работы и практическое применение. Мы обсудим, как эта технология позволяет разработчикам улучшить производительность и надежность их приложений, а также — как избежать распространенных ошибок при работе с асинхронными операциями. Подробно рассмотрим примеры кода, демонстрирующие использование Cancellation Token в различных сценариях, что сделает наше обсуждение не только теоретически насыщенным, но и довольно практичным для программистов любого уровня.
В прошлой статье мы рассмотрели способы запуска наших проектов на удаленном VPS. Для этого мы арендовали хостинг, создали шаблонное приложение, перенесли его на хостинг через простое копирование через ssh и через git clone, запустили через dotnet run / dotnet publish
, а также развернули приложение в докере.
Действительно, такой подход сложно назвать правильным даже для учебных целей, уж тем более его вряд ли можно назвать хорошим для реальных рабочих проектов. Поэтому предлагаю рассмотреть сценарий развертывания контейнеризированного .NET приложения с использованием Jenkins.
Недавно мы публиковали подборку докладов по C++, но не будем же мы обделять и C# разработчиков. Поэтому предлагаем вашему вниманию интересные доклады из мира .NET и C#.
Когда я первый раз услышал про .NET Aspire, я подумал что это какая-то очередная лажа от Майкрософта, про которую все забудут через неделю.
Особенно, учитывая какую дичь часто завозят в шарп (например те же ужасно спроектированные Primary Constructor'ы про которые я писал, или вот прикол-пропозал от самого Тоуба). Так что ожидания у меня, честно говоря, были ниже нуля.
Но попробовав его лично, я был, честно говоря, шокирован. Трепещите, жависты!! Трепещите гошники! Трещепищите питонисты - такого вы еще точно не видели.
Я даже представить не мог, что DevEx можно сделать настолько офигительным.
Давным-давно, когда Linux был ещё на ядре 2.6, а PHP5 был глотком свежего воздуха, я впервые заинтересовался миром веб-технологий. Читал учебники, статьи, зависал на форумах, но все равно мало мог понять как код, который я вижу на экране, превращается в волшебные сайты с кнопками, формами и анимациями. Узнал про LAMP и его аналоги для Windows, узнал, что, оказывается, есть хостинги, где такие сайты размещаются. Как только появился внешний интернет без трафика, я поспешил перенести свои локальные поделия во внешний мир, попутно узнав про замечательный протокол FTP. Просто мир волшебных открытий был для меня, особенно когда узнал, что не нужно писать свой форум с нуля, а можно использовать что-то из phpBB, vBulletin и других уже готовых движков.
И когда я много лет спустя переключился в мир .NET, перечисленные ранее умения сыграли со мной злую шутку – я долго не мог понять, как мне найти хостинг для .NET приложений. Почему все известные мне хостинги с лёгкостью предоставляли возможность развернуть PHP приложения, причём даже предлагая какие-то предустановленные версии CMS, но днём с огнём не сыщешь хостинг под .NET. Мое непонимание принципа развертывания приложений усугубляли статьи, которые предлагали их размещать в подходящих сервисах типа Heroku, Digital Ocean или Azure – ведь это так просто и дешево…
Поэтому предлагаю максимально подробно рассмотреть вопрос публикации .NET приложений в арендованном VPS.
Давным-давно, во времена, когда по Земле бродили цифровые динозавры, а разработчики .NET ещё помнили, зачем нужна технология WebForms (и какие у неё были проблемы с производительностью), в Контуре появился продукт под названием Фокус, предназначенный для проверки контрагентов. И у этого продукта довольно быстро появился API, ориентированный на крупных клиентов.
ASP.NET MVC был ещё в новинку, до появления WebAPI оставались годы, и отцы-основатели проекта приняли вполне актуальное, с учётом реалий того времени, решение: делать API на базе ashx-хендлеров, чтобы максимально повысить скорость работы.
Шли годы, .NET Framework сперва меняла версии как ветреная красавица перчатки, а потом и вовсе перешла в разряд «для поддержки жизнедеятельности требуется опытный некромант», .NET Core сперва появился, а потом благополучно переименовался в просто .NET, дорос до 6-й, а потом и 7-й версии… а API Фокуса всё ещё жил по старому, доброму принципу «работает — не трогай». И вот, наконец небосвод провернулся, и звёзды сошлись в нужной позиции. Мы поехали на .NET 6.
Оговорюсь сразу, что сам переезд произошёл примерно полгода назад, когда .NET 8 ещё находилась в стадии альфы. Именно поэтому в качестве целевой версии .NET была выбрана именно стабильная 6-я. Тем не менее большинство проблем будут актуальны и при миграции на 8-ю версию.
Серьёзно, банк на облачной платформе? Те читатели, кто занимается инфобезом в финтехе, сейчас, наверное, или смеются, или в ужасе думают о последствиях такого решения.
И тем не менее мы в ОТП Банке полтора года назад взялись за эту задачу — и сейчас в Yandex Cloud чувствуем себя отлично. Привет, я из трайба IT4IT ОТП Банка. Мы занимались разработкой нашего закрытого облака. Под катом расскажу, зачем нам облако понадобилось, почему собственное решение не устроило и как мы выполнили требования Управления информационной безопасности (УИБ) никого не впускать и не выпускать — не забыв при этом сделать облако мощным инструментом для наших разработчиков.
Любой, кто работал на крупном корпоративном проекте, знает, что утечки памяти подобны крысам в большом отеле. Вы можете не замечать их, когда их мало, но вы всегда должны быть начеку на случай, если они расплодятся, проберутся на кухню и загадят все вокруг.
Умение обнаруживать, исправлять и предупреждать утечки памяти — очень важный навык. Здесь я перечислю 8 лучших практик, используемых мной и моими коллегами старшими .NET разработчиками, которые и вдохновили меня написать эту статью. Эти методы научат вас определять, когда в приложении возникает утечка памяти, находить и исправлять ее. Наконец, я включил в статью стратегии для мониторинга и отчета об утечках памяти в уже развернутых программах.
.NET 8 вышел в релиз, значит можно начинать переносить свои проекты на новую версию. В этой статье мы рассмотрим новые улучшения и фишки: C# 12, производительность, Native AOT, GC, новые типы, направленные на повышение производительности, NuGet Audit и прочее.
Приветствую читатели, в этой статье я бы хотел рассказать о написанной мной OpenSource библиотеке MediaFileProcessor под платформу .NET (.netstandart 2.0).
Статья-туториал от ведущего разработчика "ITQ-Group" Александра Берегового, в которой мы рассмотрим применение обобщенного подхода при разработке WEB API.