🔐 NuGet: Microsoft меняет сертификат подписи

С 23 сентября Microsoft использует новый сертификат для подписи NuGet-пакетов. Если у вас настроен allowlist доверенных сертификатов, сборки могут начать падать с NU3034.

Что сделать:

dotnet nuget trust author Microsoft \
9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 \
--algorithm SHA256

Старые сертификаты удалять не нужно — они нужны для уже опубликованных пакетов.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#async_news

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#garbage_collector

👨‍💻 Не показывайте технические ошибки пользователям

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

⏬ Что происходит на практике

Допустим, в ASP.NET приложении возникает необработанное исключение. Без явной настройки middleware фреймворк вернёт подробный ExceptionDetails с именем метода, строкой кода и трассировкой стека. Атакующий получает информацию о структуре проекта, версиях библиотек и логике работы приложения без каких-либо усилий.

⏬ Как это закрыть

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

В ASP.NET это делается через UseExceptionHandler:

app.UseExceptionHandler(errorApp =>
{
    errorApp.Run(async context =>
    {
        var exceptionHandlerPathFeature =
            context.Features.Get<IExceptionHandlerPathFeature>();

        var logger = context.RequestServices
            .GetRequiredService<ILogger<Program>>();

        logger.LogError(exceptionHandlerPathFeature?.Error,
            "Unhandled exception");

        context.Response.StatusCode = 500;

        await context.Response.WriteAsJsonAsync(new
        {
            message = "Something went wrong. Please try again later."
        });
    });
});

⏬ Что здесь происходит

Middleware перехватывает исключение, передаёт его в ILogger — туда, где его увидит только команда разработки — и возвращает клиенту простой JSON с универсальным сообщением об ошибке. Никаких деталей реализации наружу не уходит.

ILogger пишет в вашу систему мониторинга — будь то Application Insights, Seq, Serilog или любой другой инструмент. Вы по-прежнему видите полный стек вызовов и можете разобраться в причине ошибки. Пользователь при этом получает понятное сообщение, а не технический мусор.

Это базовая практика защиты приложений. Она не требует сложной архитектуры, достаточно одного middleware, настроенного в точке входа приложения.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#sharp_view

📝 Логирование со строковой интерполяцией

Логирование c интерполяцией строк один из самых распространённых источников лишних аллокаций в .NET-приложениях.

Особенность в том, что код выглядит абсолютно нормально и работает правильно — просто дорого.

⏬ Что происходит с интерполяцией:

logger.LogInformation($"User {userId} logged in at {time}");

⏬ Компилятор разворачивает это примерно в:

logger.LogInformation(string.Format("User {0} logged in at {1}", userId, time));

Строка формируется до вызова метода. Если уровень логирования Information отключён, строка всё равно создаётся, занимает память и тут же выбрасывается сборщиком мусора.

⏬ Структурное логирование решает проблему:

logger.LogInformation("User {UserId} logged in at {Time}", userId, time);

Здесь строка — это шаблон. Аргументы передаются отдельно. Логгер сначала проверяет, активен ли уровень, и только потом форматирует сообщение. Если уровень выключен — аллокации нет вообще.

Бонус: структурное логирование позволяет индексировать поля в системах вроде Seq, Elasticsearch, Datadog — вы сможете искать по UserId как по полю, а не парсить текст.

⏬ Начиная с .NET 6 есть ещё лучший вариант через compile-time source generators:

// Генерирует оптимальный код на этапе компиляции:
[LoggerMessage(Level = LogLevel.Information, Message = "User {UserId} logged in at {Time}")]
partial void LogUserLogin(int userId, DateTime time);

Никаких аллокаций, никакого боксинга, максимальная производительность — и всё это без изменения читаемости кода.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#il_люминатор

Перенос MiniJinja с Rust на Go силами Opus и Codex

Около десяти часов работы агента и примерно 45 минут активного участия автора. Так Армин Ронахер оценивает основной перенос MiniJinja с Rust на Go. MiniJinja собирает текст по шаблонам.

Он начал с Opus 4.5 внутри Pi, а оставшиеся исправления тестов передал GPT-5.2 Codex. Рабочая среда оставалась той же; Go-реализацию сверяли с сохранёнными результатами тестов Rust-версии.

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

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека Go-разработчика

👀 Как вы смотрите видео?

Разбираете урок, слушаете интервью фоном или начинаете на телефоне, а продолжаете на большом экране?

Хотим узнать, что делает просмотр удобным для вас. Вспомните последнее видео — ролик, урок, фильм или серию сериала — и расскажите о своём опыте. Если детали не запомнились, можно так и ответить.

🕰️ Опрос займёт около 3 минут.

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

🔗 Поделиться опытом

🐸 Библиотека программиста

🚀 C# Dev Kit: сначала открытый файл, потом весь solution

Открыли большой solution и ждёте, пока IDE разберётся со всеми проектами? В предварительной версии C# Dev Kit 11.0 Microsoft изменила порядок загрузки: активный файл получает подсказки и диагностику первым.

В замерах команды для Aspire с 407 проектами готовность активного файла сократилась с «до 84,1 секунды» до 0,47 секунды. Весь solution загрузился за 3 секунды вместо 84,1. Это результаты конкретного проекта, не обещание ускорить любой репозиторий в 180 раз.

⏬ Что изменили под капотом

— добавили кеш модели проектов для повторных открытий;
— объединили шесть managed-процессов в один сервер;
— собрали этот сервер через Native AOT.

Версия 11.0 пока доступна в pre-release. Если хотите проверить эффект на своём solution, переключитесь на предварительную версию расширения. Первое построение кеша и повторная загрузка — разные сценарии: измерять их стоит отдельно.

🔗 Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#async_news

🧠 Кеш пустой, а в базу одновременно пришли сто запросов

Популярная запись исчезла из кеша. Сто запросов одновременно увидели промах и пошли за ней в базу. Кеш есть, а нагрузка всё равно прилетела залпом — это cache stampede.

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

var product = await cache.GetOrCreateAsync(
    $"product:{id}",
    async token => await repository.LoadAsync(id, token),
    cancellationToken: cancellationToken);

Для регистрации нужен пакет Microsoft.Extensions.Caching.Hybrid и вызов builder.Services.AddHybridCache();. Без Redis тоже работают локальный кеш и защита от такого залпа.

⏬ Важная граница

Объединение запросов действует внутри одного экземпляра HybridCache. Два сервера могут одновременно обратиться к базе, даже если используют общий Redis. Это полезная защита локального кеша, но не распределённая блокировка на весь кластер.

🔗 Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека шарписта

#il_люминатор