Разбираем C# 15 и .NET 11: union-типы, закрытые иерархии через closed, аргументы в коллекционных выражениях, extension-индексаторы и именованные break и continue.
Разработчики на C# просили размеченные объединения (discriminated unions) почти десять лет. Обсуждение в репозитории языка годами оставалось одним из самых популярных, а команды тем временем писали свои OneOf, Result и иерархии из абстрактных record с бесконечными default: throw. В C# 15, который выходит вместе с .NET 11, союзы наконец становятся частью языка. Вместе с ними приходят закрытые иерархии, аргументы в коллекционных выражениях, extension-индексаторы и именованные break/continue. Разберём, что из этого реально пригодится в коде уже сейчас.
Microsoft представила dotnetup: менеджер для установки и обновления .NET SDK и рантаймов. Пока в публичном превью.
Всё устанавливается в папку пользователя, без sudo и прав администратора. Можно держать стабильные версии, превью и ежедневные сборки рядом, а закрепление SDK через global.json сохраняется.
Несколько полезных команд:
dotnetup init # Настроить окружение
dotnetup list # Показать установленные версии
dotnetup update # Обновить отслеживаемые версии
dotnetup sdk install preview # Установить превью SDK
Можно отслеживать обновления внутри конкретной ветки или закрепить точную версию. При обновлении ненужные компоненты очищаются автоматически.
HelmSharp позволяет рендерить шаблоны и управлять релизами Kubernetes внутри .NET-приложения.
Что умеет:
• Загружать чарты из папки и .tgz.
• Объединять values.yaml с пользовательскими параметрами.
• Упаковывать чарты и работать с HTTP-репозиториями.
• Устанавливать, обновлять, откатывать и удалять релизы.
• Хранить историю релизов в Kubernetes Secrets, совместимых с Helm v3.
Для начала:
dotnet add package HelmSharp.Action
Поддерживает .NET 8, 9 и 10, лицензия MIT.
Пригодится для собственных панелей управления и сервисов деплоя на C#. Совместимость с Helm пока частичная: свои чарты стоит проверить, особенно если они используют сложные шаблонные функции или расширения.
Тестировщик fullstack: C#-автоматизация и ручные тесты
Если вы хотели работать на сильном продукте в гибком графике – это вакансия для вас.
Задачи
• Разрабатывать автотесты на C# и улучшать тестовый фреймворк
• Проводить полный цикл тестирования и отчитываться по релизам
• Разбирать инциденты вместе с заказчиком
Какие навыки нужны
• Опыт в тестировании веб-приложений от 2 лет
• Автоматизация на C#, знание REST API, SQL/NoSQL, брокеров сообщений и CI/CD
Условия
• Зарплата в рынке и премия по результатам работы
• Полная удалёнка или гибридный график (есть ИТ-хабы в Москве, Санкт-Петербурге и Екатеринбурге)
• Поддержка сообщества QA Talks
• Технический трек развития
🔐 Passkeys можно использовать как второй фактор в ASP.NET Core.
Пользователь вводит пароль, затем подтверждает вход через Touch ID, Windows Hello или аппаратный ключ. Без SMS и шестизначных кодов.
Маартен Баллиау показал реализацию на ASP.NET Core Identity в .NET 10: провайдер второго фактора, временная cookie и два эндпоинта для запроса и проверки passkey.
Есть важный нюанс: `PasskeySignInAsync()` выполняет прямой вход и обходит отдельный этап 2FA. Поэтому в таком сценарии нужно проверить, что passkey принадлежит именно пользователю, который уже прошёл проверку пароля.
Полезный разбор для тех, кто хочет добавить устойчивый к фишингу второй фактор в существующее приложение.
SSE работает поверх обычного HTTP и поддерживает аутентификацию. Подвох в браузерном `EventSource`: он не позволяет задать заголовок Authorization.
В статье Paul Karam разобраны варианты:
• Cookies: браузер отправляет их автоматически для своего origin. Для другого нужны withCredentials: true и корректный CORS.
• Одноразовый короткоживущий токен в URL: при переподключении придётся получить новый.
• `@microsoft/fetch-event-source`: позволяет передать Bearer-токен в заголовке.
• `HttpClient`: вариант для .NET-клиентов с обычными заголовками аутентификации.
Долгоживущий access token в URL может утечь через логи сервера или прокси. На сервере SSE-эндпоинт защищается стандартными средствами ASP.NET Core, например .RequireAuthorization() при cookie-аутентификации.
class Box
{
public int Value
{
get;
set => field = value * 10;
}
}
Варианты:
A) 4 120
😎 2 120
C) 2 30
D) Код не скомпилируется
Ответ: B) 2 120
Здесь сразу две фичи C# 14.
Первая: null-conditional assignment. Теперь ?. можно ставить слева от присваивания, в том числе составного. Главный подвох в том, что если объект слева равен null, правая часть вообще не вычисляется. Поэтому для a функция Next() ни разу не вызывается, и счётчик доходит только до 2, хотя вызовов в коде четыре.
Вторая: ключевое слово `field`. Геттер остаётся автоматическим, а сеттер умножает значение на 10, обращаясь к скрытому полю без ручного объявления.