Библиотека шарписта | C#, F#, .NET, ASP.NET (@csharpproglib) — Telegram-канал | Telegram Dialogs
Telegram Dialogs — логотип
Все каналы
Библиотека шарписта | C#, F#, .NET, ASP.NET

Библиотека шарписта | C#, F#, .NET, ASP.NET

@csharpproglib

21.6K подписчиков технологии 💬 Комментарии открыты

Все самое полезное для C#-разработчика в одном канале. Наши курсы: https://clc.to/y3LDtw По рекламе: @tproger_sales_bot Для обратной связи: @proglibrary_feeedback_bot РКН: https://gosuslugi.ru/snet/67a5c81cdc130259d5b7fead

Последние публикации

Библиотека шарписта | C#, F#, .NET, ASP.NET
07.10.2026 10:01 · 👁 1.9K
Альфа-Банк ищет скиллового коллегу QA Fullstack на C# Полная удалёнка или гибрид в Москве, Питере и Екатеринбурге. Что нужно делать: — Разрабатывать автотесты на C#; — Запускать функциональные, регрессионные и интеграционные тесты, включая API; — Снижать количество дефектов в диалоге с разработкой и бизнесом. Навыки: — Опыт автоматизации на C# и ручного тестирования от года; — Знание API (SOAP, REST), SQL, основ клиент-серверной архитектуры и тест-дизайна. Условия и развитие: — Сильное сообщество QA и C#-разработчиков: можно получить совет и поделиться опытом на митапе и в блоге на Хабре: — Реальная перспектива роста: технический трек развития, в том числе до C#-лида. Оставляйте отклик по ссылке.
Библиотека шарписта | C#, F#, .NET, ASP.NET
05.10.2026 10:02 · 👁 2.2K
🦈 Открытое собеседование на Middle C# | 6 октября, 19:00 МСК Приглашаем на открытое собеседование: Senior C# разработчик проведёт его в прямом эфире. Можно посмотреть, как всё устроено изнутри, и понять, насколько ты готов к такому интервью. Как это будет: 📂 Собеседует Александр Моргунов — Senior C# разработчик, 7+ лет в европейских высоконагруженных сервисах. Отвечает разработчик-доброволец; 📂 Всё как на настоящем собесе: Александр задаёт те вопросы и задачи, которые даёт кандидатам на своих интервью. Заранее их никто не знает; 📂 После каждого ответа Александр даст обратную связь: что прозвучало сильно, а что стоило раскрыть иначе. Так станет понятнее, на что обращают внимание на собесе; 📂 В конце можно задать любой вопрос. Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для C# разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы. Переходи в нашего бота, чтобы получить ссылку на эфир -> @shortcut_csharp_bot Реклама. О рекламодателе.
Библиотека шарписта | C#, F#, .NET, ASP.NET
30.09.2026 10:41 · 👁 3.2K
📝 Логирование со строковой интерполяцией Логирование 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_люминатор
Библиотека шарписта | C#, F#, .NET, ASP.NET
28.09.2026 17:34 · 👁 3K
👨‍💻 Не показывайте технические ошибки пользователям Когда приложение падает с необработанным исключением, стандартное поведение многих фреймворков — вывести стек вызовов прямо в ответ. Пользователь видит внутренние пути файлов, названия классов, фрагменты кода. Для злоумышленника это готовая карта уязвимостей. ⏬ Что происходит на практике Допустим, в 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#, F#, .NET, ASP.NET
26.09.2026 10:47 · 👁 3.4K
📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #garbage_collector
Библиотека шарписта | C#, F#, .NET, ASP.NET
25.09.2026 14:04 · 👁 3.9K
🔐 NuGet: Microsoft меняет сертификат подписи С 23 сентября Microsoft использует новый сертификат для подписи NuGet-пакетов. Если у вас настроен allowlist доверенных сертификатов, сборки могут начать падать с NU3034. Что сделать: dotnet nuget trust author Microsoft \ 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 \ --algorithm SHA256 Старые сертификаты удалять не нужно — они нужны для уже опубликованных пакетов. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #async_news
Библиотека шарписта | C#, F#, .NET, ASP.NET
24.09.2026 16:14 · 👁 3.9K
🤩 Как поймать зависший .NET-сервис Приложение начинает тормозить, запросы зависают, а в логах — ничего полезного? Можно автоматически снять memory dump в момент проблемы и потом разобрать состояние процесса. ➡️ Идея простая: var task = Task.Run(() => { }); if (!task.Wait(3000)) { // ThreadPool, вероятно, перегружен // → создаём memory dump } ➡️ Dump позволяет посмотреть: — какие потоки зависли; — где стоят Task; — что происходит в ThreadPool; — какие объекты находятся в памяти. На Windows для создания dump можно использовать MiniDumpWriteDump, а в Linux — встроенный в .NET createdump. А дальше .dmp открывается в Visual Studio — можно исследовать call stacks, переменные и состояние потоков. 💡 Особенно полезно для production-проблем, которые невозможно нормально воспроизвести локально. 🔗 Источник 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view
Библиотека шарписта | C#, F#, .NET, ASP.NET
23.09.2026 12:01 · 👁 3.6K
⚙️ yield return не бесплатный Итераторы выглядят просто, но работают иначе: IEnumerable<int> GetIds() { foreach (var item in _items) yield return item.Id; } Читается как обычный цикл. Но компилятор превращает такой метод в конечный автомат со вспомогательными классами и состоянием. Именно поэтому итераторы такие выразительные — но и именно поэтому они не бесплатны. ❓ Где это становится проблемой На большинстве путей yield return это правильный выбор. Код чище, API удобнее, читаемость выше. Но на горячих путях, где метод вызывается тысячи раз в секунду, повторное создание объектов итератора и дополнительные слои абстракции начинают влиять на производительность. Не катастрофически, но измеримо. ❓ Что делать на критичных участках Если профилировщик показал, что итератор узкое место, есть несколько альтернатив. 🟡 Заполнение буфера, переданного вызывающей стороной: void FillIds(Span<int> buffer) { for (int i = 0; i < _items.Count; i++) buffer[i] = _items[i].Id; } 🟡 Возврат конкретной коллекции: List<int> GetIds() { var result = new List<int>(_items.Count); foreach (var item in _items) result.Add(item.Id); return result; } 🟡 Прямой цикл внутри горячего кода без промежуточных перечислений: for (int i = 0; i < _items.Count; i++) Process(_items[i].Id); yield return стоит использовать тогда, когда он делает API лучше и код понятнее. Но не стоит считать его нулевым по стоимости. Если участок горячий, то сначала замерьте, потом решайте. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #il_люминатор
Библиотека шарписта | C#, F#, .NET, ASP.NET
22.09.2026 06:47 · 👁 3.1K
💡 Replace, Regex или StringBuilder? Для замены текста в C# есть несколько инструментов. И выбирать их лучше не по принципу «что быстрее», а по задаче. 🔜 string.Replace() — когда ищем конкретный текст: var result = text.Replace("cat", "dog"); 🔜 Regex.Replace() — когда нужен шаблон: var result = Regex.Replace( text, @"\d+", "#"); Например, заменить все числа на #. 🔜 StringBuilder.Replace() — когда последовательно изменяем большой текст: var sb = new StringBuilder(text); sb.Replace("cat", "dog"); sb.Replace("foo", "bar"); var result = sb.ToString(); 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view
Библиотека шарписта | C#, F#, .NET, ASP.NET
21.09.2026 13:05 · 👁 3.3K
⚙️ Настоящие атомарные операции Если Volatile решает проблему видимости, то Interlocked решает проблему атомарности. Операции реализованы на уровне процессора и выполняются как неделимые единицы — никакой другой поток не может вмешаться в середину ➡️ Самый частый сценарий это счётчик, который обновляют несколько потоков: private int _counter; public void Increment() { Interlocked.Increment(ref _counter); } Без Interlocked операция _counter++ на самом деле три шага: прочитать, прибавить, записать. Два потока могут выполнить их одновременно и затереть результат друг друга. Interlocked.Increment делает всё это за один неделимый шаг. ➡️ Lock-free генератор ID Interlocked подходит для генерации уникальных идентификаторов без блокировок: public int GetNextId() { return Interlocked.Increment(ref _id); } Каждый вызов гарантированно вернёт уникальное значение, даже если тысячи потоков вызывают метод одновременно. ➡️ CompareExchange: условное обновление Самая мощная операция в арсенале Interlocked: if (Interlocked.CompareExchange(ref _state, 1, 0) == 0) { // Успешно перешли из состояния 0 в 1 } Логика простая: если текущее значение равно 0, заменить на 1 и вернуть старое значение. Если кто-то уже изменил _state, операция ничего не сделает. Это паттерн, на котором строятся lock-free кэши, планировщики и конкурентные очереди. ➡️ Volatile и Interlocked — не одно и то же Их можно перепутать, но они решают разные задачи. Volatile гарантирует, что поток видит актуальное значение переменной. Interlocked гарантирует, что сама операция выполняется безопасно, без вмешательства других потоков. В реальных системах нередко нужны оба. Volatile чтобы читать свежие данные, Interlocked чтобы безопасно их менять. 📍 Навигация: Вакансии • Задачи • Собесы 🐸 Библиотека шарписта #sharp_view
Чат поддержки
Ответим здесь же, обычно быстро
Здравствуйте! Напишите ваш вопрос — оператор ответит в этом чате.