Библиотека шарписта | C#, F#, .NET, ASP.NET – Telegram
Библиотека шарписта | C#, F#, .NET, ASP.NET
22.4K subscribers
2.52K photos
40 videos
85 files
4.76K links
Все самое полезное для C#-разработчика в одном канале.

По рекламе: @proglib_adv

Учиться у нас: https://proglib.io/w/b60af5a4

Для обратной связи: @proglibrary_feeedback_bot

РКН: https://gosuslugi.ru/snet/67a5c81cdc130259d5b7fead
Download Telegram
📊 Рейтинг постов

Вы всю неделю ставили нам лайки, а мы выбрали топ по реакциям:

100 RPS Rate Limiting
Закон Брукса в разработке
Антиспам в .NET
FluentValidation в API
StackTraceHiddenAttribute

Давайте выберем самый лучший пост в голосовании.

Что добавить в следующий спринт? Пишите! 👇


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

#entry_point
Please open Telegram to view this post
VIEW IN TELEGRAM
🥰5🔥1
⚙️ Один обработчик вместо сотни try catch

Когда в проекте десятки эндпоинтов, разъезжающий по коду try catch быстро превращается в свалку. Гораздо проще один раз настроить глобальный маппинг исключений в HTTP статус и возвращать нормальные ProblemDetails для всех ошибок.

ASP.NET уже умеет работать с ProblemDetails из коробки, нужно только включить службу и повесить обработчик ошибок.

В примере вся логика перевода исключений в HTTP ответы живет в одном месте:
builder.Services.AddProblemDetails();

var app = builder.Build();

app.UseExceptionHandler(appErr =>
{
appErr.Run(async ctx =>
{
var ex = ctx.Features.Get<IExceptionHandlerFeature>()?.Error;

var (status, noscript) = ex switch
{
ConcurrencyException => (StatusCodes.Status409Conflict, "Concurrency conflict"),
NotFoundException => (StatusCodes.Status404NotFound, "Resource not found"),
_ => (StatusCodes.Status500InternalServerError, "Server error")
};

ctx.Response.StatusCode = status;

await ctx.Response.WriteAsJsonAsync(new ProblemDetails
{
Status = status,
Title = noscript,
Detail = app.Environment.IsDevelopment() ? ex?.Message : null,
Instance = ctx.Request.Path
});
});
});


Любые новые исключения добавляются через одну запись в switch, без походов по контроллерам, а все ответы об ошибках приходят в едином формате application/problem+json, что упрощает жизнь фронту и интеграциям.

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

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

#sharp_view
Please open Telegram to view this post
VIEW IN TELEGRAM
22👍15
👨‍💻 Не хватает комментария «Создаёт переменную x равную 10»

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

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

#garbage_collector
Please open Telegram to view this post
VIEW IN TELEGRAM
😁401🥰1🌚1👾1
Сборщик мусора для старых знаний

В экосистеме .NET всё меняется, но фундамент вечен. Если чувствуешь, что уперся в потолок сеньорити, пора инвестировать в хард-скиллы, а не просто учить новый синтаксис C
12.

Оффер 1 + 2:

Покупаешь один курс (по старшей цене) — получаешь доступ к трем.

Выбор .NET-комьюнити:

— архитектуры и шаблоны проектирования (SOLID, GRASP и вот это всё);
— алгоритмы и структуры данных.

Скомпилировать успех

Акция до 31 декабря.
NullReferenceException при выборе? Пиши сюда: @manager_proglib
2🥰1
🚦 SemaphoreSlim в проде — не просто «асинхронный lock»

SemaphoreSlim часто кидают в код как самое простое решение и успокаиваются. В проде этого мало, ведь малейшая ошибка с Release, областью блокировки или per-key словарем легко превращается в дедлок, гонку или утечку памяти.

Самый частый фейл — банальное «забыли Release». Исключение между WaitAsync и finally и семафор навсегда занят поэтому все будущие вызовы повисают. Помогает только жесткое правило всегда оборачивать WaitAsync в try finally и не вставлять лишний код между ними особенно никакой логики которая может бросить исключение.

Вторая классика — блокировки внутри async кода. Варианты вроде _lock.Wait() или .Result внутри секции под SemaphoreSlim открывают прямую дорогу к дедлокам, потому что блокирующий вызов держит поток, а продолжение ждет этот же поток.

Общий принцип не блокировать внутри асинхронной критической секции если нужно синхронное API выносить его в Task.Run до входа в lock.

Поэтому в проде почти всегда лучше прятать SemaphoreSlim за абстракцией AsyncLock. Обертка с LockAsync() возвращающей IDisposable снимает часть рисков.

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

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

#il_люминатор
Please open Telegram to view this post
VIEW IN TELEGRAM
10🥰1
GetElapsedTime вместо ручного Stopwatch шаблона

Многие до сих пор измеряют время в .NET по старинке создают экземпляр Stopwatch, вызывают Start, ждут выполнение и читают Elapsed.

Но есть более простой и аккуратный способ через Stopwatch.GetTimestamp и Stopwatch.GetElapsedTime.

Классический шаблон выглядит так:
long start = Stopwatch.GetTimestamp();

// код, который нужно измерить
await ProcessOrderAsync();

TimeSpan elapsed = Stopwatch.GetElapsedTime(start);


GetElapsedTime вычисляет разницу между текущим timestamp и сохранённым значением и возвращает TimeSpan без создания экземпляра Stopwatch. В результате нет лишней аллокации.

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

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

#sharp_view
Please open Telegram to view this post
VIEW IN TELEGRAM
👍375🥰4
👨‍💻 Microsoft показали рабочий рецепт iOS виджетов

В официальном .NET блоге появилась большая статья о том как собирать iOS виджеты поверх .NET MAUI не теряя нативности.

Автор делится практическим опытом, который раньше приходилось выкапывать по кускам в доках Apple и чужих репозиториях.

Статья не пошаговый туториал, а набор ключевых шагов и граблей от настроек App Groups и bundle id до интеграции Xcode виджет расширения в MAUI проект.

➡️ Читать статью

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

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

#sharp_view
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7
🎁 Письмо Деду Морозу

До Нового Года 15 дней! Что бы вы хотели получить в подарок? Годовая премия не в счёт, это всегда как рулетка — повезёт/не повезёт.

Админ хотел бы набор оперативной памяти, желательно гига 32, откладывал до последнего и вот итог..

💬 Делитесь своими хотелками или сразу вишлистами в комментах 👇

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

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

#entry_point
Please open Telegram to view this post
VIEW IN TELEGRAM
😁5
🛠 Инструмент для трассировки без шума в коде

В ASP.NET трассировка маршрутизации, middleware и хостинга держится не на конкретном логгере, а на связке DiagnosticSource и DiagnosticListener.

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

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

Простой пример:
public static class OrderDiagnostics
{
public static readonly DiagnosticListener Listener =
new("MyApp.Orders");
}

public async Task ProcessOrder(Order order)
{
if (OrderDiagnostics.Listener.IsEnabled("OrderProcessed"))
OrderDiagnostics.Listener.Write("OrderProcessed", new { order.Id });

// основная логика обработки
}


Если никто не подписан, проверка IsEnabled сразу вернет false и код почти ничего не стоит по времени. Как только появляется listener, он может наблюдать за событиями, строить трейс, метрики или слать данные в OpenTelemetry.

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

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

#il_люминатор
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥5👍32