Небольшая подборка интересных докладов с конференций для C# и .NET разработчиков за последние несколько лет.

Свою предыдущую статью на Хабре я написал в 2016 году, и она была посвящена подборку команды стартапа. Примерно в это время я погрузился в историю создания собственного продукта и стало не до создания контента. Так получилось, что в 2020 году мне пришлось сделать свою реализацию библиотеки для создания, редактирования и индексирования документов формата Microsoft Word, стандартизированного как OOXML WordprocessingML и получившего в свое время расширение файла .docx. Именно ей и хотелось бы поделиться с сообществом.

Несколько недель назад в блоге «.NET Blog» появилась статья «Что такое .NET, и почему вы должны выбрать его?». В нем был представлен высокоуровневый обзор платформы, кратко описаны различные компоненты и архитектурные решения, а также обещаны более подробные посты по затронутым темам. Этот пост является первым таким продолжением, в котором подробно рассматривается история создания, архитектурные решения и детали реализации async/await в C# и .NET.

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

Веб платформа ASP.NET за последние десятилетия получила достаточно широкое распространение. С ее помощью разрабатывают веб-сайты и веб-приложения с помощью таких средств как HTML, CSS и JavaScript. Также с помощью ASP.NET можно создавать веб-API и веб сокеты.

Одной из основных проблем при разработке в контексте безопасности является невозможность функциональной проверки у того, или иного приложения. То есть, при разработке приложения мы не можем просто подключить какие-то библиотеки, сделать какие-то настройки при сборке проекта, и затем сказать, что все, наше приложение защищено и можно передавать его в продакшен. Так не бывает. На практике возможны два основных сценария: худший когда мы узнаем о проблемах с безопасностью нашего приложения из СМИ и интернета, например, когда приложение взломали или, когда в сеть утекли данные, обрабатываемые нашим приложением (да, обычно эти утечки организуют бывшие или действующие сотрудники, и это не совсем вина приложения, но, как говориться  осадочек все-равно остается). Более мягким является сценарий, когда мы узнаем об уязвимостях в нашем приложении в результате пентеста или когда сознательные исследователи сами сообщают разработчикам о найденных уязвимостях, например в рамках баг баунти. В таком случае нас скорее всего еще не скомпрометировали и репутационного ущерба для компании разработчика не будет. Ну а срочные баг фиксы выпускают все.

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

Хабр, привет!

Сегодня я предлагаю совершить небольшое исследование на тему "как нам обустроить интеграционное тестирование и встроить его в сиайку".
Написать эту заметку меня сподвигла дискуссия, случившаяся недавно на работе. Инициативная группа "четырехглазых в свитерах" пыталась родить меры по улучшению качества нашего изделия и снижения трудозатрат QA-инженеров на проведение рутинного регрессионного тестирования. Как это часто бывает, разработчики если и писали тесты, то только модульные, оставляя интеграционные и end-to-end для тестировщиков. Для выполнения интеграционного тестирования QA-инженеры используют "тестовый стенд", на котором развернуты компоненты приложения (еще около 40, с позволения сказать, "микросервисов"), сервер базы данных (с не всегда ясным наполнением этой самой базы), брокер сообщений (RabbitMQ) и все остальное, что может потребоваться для запуска приложения. На этот тестовый стенд натравливаются автотесты, которые шатают приложение за все доступные снаружи конечные точки, таблицы БД и элементы UI пытаясь проверить максимальное количество тестовых сценариев в границах (и за ними!) возможных входных данных.

Статья‑гайд от ведущего.NET‑разработчика «ITQ Group» Александра Берегового.

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

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

Обычно моя работа связана с разработкой функционала REST веб-сервисов. Чаще всего, разработка эта ведется на базе уже существующих приложений, созданных и настроенных ранее по шаблону Web API в VisualStudio. Создавать новые приложения приходится не часто, последнее созданное мной, было еще на .NET Core 3.1, поэтому, когда возникает подобная задача, приходится тратить время на повторное изучение технологий первоначальной настройки приложения, чтобы оно отвечало всем требованиям бизнес-процесса компании, в которой я работаю. Столкнулся с этой задачей накануне, решил создать шаблон приложения (ссылка на репозиторий GitHub), в котором уже все настроено и готово. Краткое описание процесса привожу в этой статье. Постарался разбить сам процесс на независимые блоки, чтобы для реализации одного из них не приходилось изучать другие. Намеренно подробно освящаю настройку базовых функции, не вдаваясь в описание принципа работы той или иной функции - для более глубокого понимания привожу ссылки на документацию, по которой учился сам. Статья моя будет полезна для новичков в качестве отправной точки для изучения тех или иных функций .Net Core 6, а так же для специалистов, которые как и я, сосредоточены на реализации бизнес-логики приложения и требуется сократить время восстановления в памяти технологии его первоначальной настройки.

C постепенным переходом проектов на .NET Core фреймворки все большую популярность набирает стандартная реализация внедрения зависимостей от Microsoft. При использовании любого фреймворка для внедрения зависимостей рано или поздно разработчики сталкиваются с проблемой забытой или неправильной регистрации зависимостей, что влечет за собой ошибку в рантайме приложения. В этой статье разбираемся как покрыть unit-тестами внедрение зависимостей стандартной библиотеки Microsoft.Extensions.DependencyInjection.

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

Надеюсь, данная статья поможет ответить на эти и другие вопросы. На примере своей библиотеки с открытым исходным кодом – DryWetMIDI – рассмотрим различные аспекты создания подобных проектов. И хотя речь будет идти про .NET/C#, уверен, многое применимо и к другим популярным платформам и языкам программирования.

Продолжаем делиться полезными материалами в backend-разработке. Осваивая новые инструменты, специалисты SimbirSoft часто читают материалы зарубежных авторов, чтобы быть в курсе актуальных тенденций. В этот раз наш выбор пал на серию материалов британского разработчика Эндрю Лока про новые возможности .NET 6. С разрешения автора мы перевели статью, в которой он разбирает функции внедрения зависимостей в .NET 6. Материал будет полезен тем, кто хочет познакомиться с нововведениями в .Net 6 при переходе на эту технологию.

Мы на Хабр Карьере шесть месяцев собирали зарплаты IT-специалистов, чтобы сейчас традиционно представить наш большой зарплатный отчет. В основе анализа — 12 000 зарплат айтишников в первом полугодии 2022 года. 

Впервые за почти пять лет средняя зарплата IT-специалистов спустя полгода не изменилась — как и в конце 2021 года, она составляет 140 000 ₽. В Санкт-Петербурге зарплата айтишников тоже осталась без изменений — 150 000 ₽. А вот в Москве и регионах выросла на 3 и 4% — 180 000 ₽ и 120 000 ₽ соответственно.

RabbitMQ – это брокер сообщений, служба, отвечающая за обмен сообщениями между разными программными сервисами.

RabbitMQ держит сообщения в очереди (Queue), которая является именованным буфером, хранящим адресованные ему сообщения.

Программа, посылающая сообщения в очередь RabbitMQ, называется поставщиком (Producer).

Программа, принимающая сообщения, называется подписчиком (Consumer). Такие программы подписываются на события поступления сообщения в очередь, и всегда находятся в ожидании новых сообщений.

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

Для тех кто хочет погрузиться в проектирование .Net микросервисов, Kubernetes, Azure и Azure DevOps процессы. 

Эта статья является продолжением двух предыдущих занудных статей под общим заголовком "О классах Program и Startup — инициализация ASP.NET приложения": "Program и IHostBuilder"[1] и "IWebHostBuilder и Startup"[2] — в которых подробно написано о том, что происходит в процессе инициализации приложения ASP.NET, сделанного по шаблону Generic Host. В тех двух статьях я рассказывал, как производится настройка и выполняется создание объектов конфигурации (она доступна через интерфейс IConfiguration), контейнера сервисов (он же DI-контейнер, его интерфейс — IServiceProvider) и размещения (интерфейс IHost). А в этой статье я собираюсь подробно рассказать, что происходит сразу после того, как приложение запускается на выполнение в объекте размещения.
Написав третью статью на примерно одну и ту же тему, я подумал, что и первые две, и эта должны стать частью одной серии, которую я для себя озаглавил "Под капотом" (см. КДПВ)

Но если вам все ещё интересно (или не интересно, но читать все равно зачем-то надо) — добро пожаловать под кат (и не говорите, что я вас не предупреждал, что легкого чтения не будет).

Пакет Entity Framework 7 (EF7) Preview 6 опубликован и доступен для загрузки через nuget.org (в конце поста есть ссылки на индивидуальные компоненты пакета). Этот пост блога раскрывает реализованные в пакете улучшения, направленные на увеличение производительности [запросов]; полный перечень изменений EF7 Preview 6 доступен на этой странице.

Все материалы, которые будут показываться в ходе данной статьи будут доступны по данной ссылке https://github.com/vliashko/CommunicationWithDB. Вполне возможно, что со временем данный репозиторий будет обновляться, или, некоторые захотят сами принять участие в его развитии.

Можно ли сегодня представить разработку, будь то десктопы или веб, без использования баз?

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

В чем же так плоха файловая система? Ну на самом деле, говоря на своем опыте, можно выделить следующие пункты:

1. Блокировка файла, в который идет запись

2. Отсутствие специализированных программ для работы с файлами (аналог СУБД)

Да, в какой-то мере можно выделить еще минусы, или попытаться закрыть уже названные мной. Но в целом главная идея базы данных – это удобство для чтения данных, а также наличие огромного числа инструментов для работы с данными (возможность быстрого поиска по полям таблицы, соединение таблиц, группировка записей, индексирование и т.д.)

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

Тогда давайте рассмотрим как пользоваться базами данных на платформе .NET с использованием языка C#.