C# 1001 notes

In-memory кэш в .NET: плюсы и минусы

✅ Плюсы:
• Очень быстрый
• Легко реализуется
• Не требует внешних зависимостей

⚠️ Минусы:
• Данные теряются при перезапуске
• Работает только в пределах одного инстанса
• Нет шаринга между приложениями

📌 Нужно больше — переходите на распределённый кэш.

Redis — топовый выбор, и в .NET есть два стабильных клиента:
• StackExchange.Redis
• Microsoft.Extensions.Caching.StackExchangeRedis

📘 Хотите понять, когда и как использовать оба подхода?
Вот полный гайд:
https://milanjovanovic.tech/blog/caching-in-aspnetcore-improving-application-performance

2.07K viewsedited 08:02

C# 1001 notes

🖥

Задача «Перехват исключений и потеря контекста» (C# 12)

Дан код:


using System;
using System.Runtime.ExceptionServices;

class Program
{
    static void Main()
    {
        try
        {
            Console.WriteLine(Foo());
        }
        catch (Exception ex)
        {
            Console.WriteLine($"Catch: {ex.Message}");
        }
    }

    static int Foo()
    {
        try
        {
            return Bar();
        }
        finally
        {
            throw new Exception("finally in Foo");
        }
    }

    static int Bar()
    {
        try
        {
            throw new Exception("error in Bar");
        }
        finally
        {
            Console.WriteLine("Bar finally executed");
        }
    }
}

Вопросы:
• Что напечатает программа и почему?
• В каком порядке выполняются блоки try / finally?
• Какая из двух ошибок дойдёт до catch, а какая потеряется?
• Как изменить код, чтобы не терять информацию о первой ошибке?

Разбор:
• Bar бросает Exception("error in Bar"). Прежде чем исключение покинет метод, выполняется его finally, выводя Bar finally executed.
• Управление переходит в Foo. Там срабатывает finally, который бросает новое исключение ("finally in Foo").
• По правилам CLR новое исключение из finally заменяет текущее. Первая ошибка пропадает.
• В Main перехватывается только «finally in Foo».

Консольный вывод:

Bar finally executed
Catch: finally in Foo

Как сохранить обе ошибки

Обернуть второе исключение так, чтобы первая причина не потерялась, например:


finally
{
    var pending = new Exception("finally in Foo");
    throw new AggregateException("Foo failed", pending);
}

или переслать исходное исключение через ExceptionDispatchInfo:

Exception pending = null;

static int Foo()
{
try
{
return Bar();
}
catch (Exception ex)
{
pending = ex; // сохраняем первую причину
throw;
}
finally
{
if (pending != null)
ExceptionDispatchInfo.Capture(pending).Throw();
}
}```

Так ни одна ошибка не будет потеряна, а отладка станет нагляднее.

Please open Telegram to view this post

VIEW IN TELEGRAM

2.12K views16:01

C# 1001 notes

🖥

Быстрая сортировка (QuickSort) с использованием рекурсии

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

Решение: Автор в книге Algorithms and Data Structures for OOP With C# демонстрирует реализацию QuickSort — одного из самых эффективных алгоритмов сортировки на практике, с рекурсивным разбиением массива.

Пример кода:


public class QuickSortExample
{
    public void QuickSort(int[] arr, int low, int high)
    {
        if (low < high)
        {
            int pi = Partition(arr, low, high);

            QuickSort(arr, low, pi - 1);
            QuickSort(arr, pi + 1, high);
        }
    }

    private int Partition(int[] arr, int low, int high)
    {
        int pivot = arr[high];
        int i = (low - 1);

        for (int j = low; j < high; j++)
        {
            if (arr[j] < pivot)
            {
                i++;
                (arr[i], arr[j]) = (arr[j], arr[i]);
            }
        }

        (arr[i + 1], arr[high]) = (arr[high], arr[i + 1]);
        return i + 1;
    }
}

Преимущества:
— Быстрая сортировка даже больших наборов данных
— Средняя сложность O(n log n)
— Эффективное использование памяти за счет рекурсии

Please open Telegram to view this post

VIEW IN TELEGRAM

2.7K views08:40

C# 1001 notes

Трюк: добавление элементов в словарь со списками через `??=`


var dict = new Dictionary<string, List<int>>();
string key = "numbers";
int item = 42;

// Обычный способ:
if (!dict.TryGetValue(key, out var list))
{
    list = new List<int>();
    dict[key] = list;
}
list.Add(item);

// Короткий трюк:
(dict[key] ??= new List<int>()).Add(item);

Разбор:

- При обращении к dict[key] отсутствующий ключ вернёт default(List<int>), то есть null.

- Оператор ??= проверяет левую часть на null и, если она null, присваивает справа новое значение.

- В нашем случае, если dict[key] был null, создаётся новый List<int> и сразу сохраняется в словаре.

- После этого метод .Add(item) вызывается уже на существующем списке.

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

2.35K views08:58

C# 1001 notes

🎯 Using .NET Aspire With the Docker Publisher — практическое руководство от Milan Jovanović

.NET Aspire — это современный фреймворк от Microsoft для создания облачных микросервисов. В статье показано, как автоматически интегрировать Docker Compose в .NET‑приложение с помощью нового инструмента — Aspire Docker Publisher.

✅ Что вы узнаете:

1. Как описать окружение прямо в C#:


builder.AddDockerComposeEnvironment("aspire-docker-demo");

var postgres = builder.AddPostgres("database").WithDataVolume();
var redis = builder.AddRedis("cache");

var webApi = builder.AddProject<Projects.Web_Api>("web-api")
    .WithReference(postgres).WaitFor(postgres)
    .WithReference(redis).WaitFor(redis);

builder.Build().Run();

2. Как опубликовать проект:


dotnet tool install --global aspire.cli --prerelease
aspire publish -o docker-compose-artifacts

После чего автоматически создаётся docker-compose.yml и .env.

3. Что входит в результат:
- Готовый docker-compose.yml со всеми зависимостями
- Поддержка портов, переменных среды, volume и сетей
- Полная инфраструктура, которую можно деплоить хоть на VPS

4. Как это работает на проде:
- Всё, что нужно: скопировать артефакты → docker compose up -d
- Можно легко обернуть через Nginx или Traefik, подключить SSL

🧠 Почему это удобно:
- Не нужно вручную писать YAML — всё в коде
- Повышается воспроизводимость и читаемость инфраструктуры
- Упрощает переход от локальной разработки к боевому деплою

🔗 Статья: www.milanjovanovic.tech/blog/using-dotnet-aspire-with-the-docker-publisher

1.92K views08:16

C# 1001 notes

🧠 .NET-задача для продвинутых: потокобезопасная очередь с приоритетами и отменой задач

Задача:

Реализуйте асинхронный планировщик задач с приоритетами и возможностью отмены. Требования:

1. Есть очередь задач (`Func<CancellationToken, Task>`), каждая с целочисленным приоритетом (0 — самый высокий).
2. Задачи выполняются параллельно, но не более N одновременно.
3. Если приходит задача с более высоким приоритетом, и нет свободных слотов, она может вытеснить задачу с самым низким приоритетом.
4. Вытеснённая задача должна быть отменена (через `CancellationToken`), и её ресурсы — корректно освобождены.
5. Код должен быть потокобезопасным и устойчивым к гонкам.

Дополнительно:

- Используйте PriorityQueue, SemaphoreSlim, CancellationTokenSource
- Не допускайте deadlock’ов
- Обеспечьте корректное завершение планировщика по команде StopAsync()

Пример API:


public class PriorityTaskScheduler
{
    public PriorityTaskScheduler(int maxParallelism);

    public Task EnqueueAsync(Func<CancellationToken, Task> task, int priority);

    public Task StopAsync();
}

@csharp_1001_notes

2.06K views09:55

C# 1001 notes

⚠️ Как вы обрабатываете ошибки в C#?

Многие используют исключения для управления потоком и быстрого фейла. Но в C# метод не сообщает, какие именно исключения он может выбросить — это не видно в сигнатуре.

🔍 Мой подход:
Исключения — только для исключительных ситуаций.

Если метод может ожидаемо провалиться, пусть это будет явно.

✅ Используйте Result-паттерн:

— Метод возвращает Result<T> вместо выбрасывания исключения
— Caller обязан проверить IsSuccess и обработать ошибку
— Код становится предсказуемее и легче тестируется
— Дополнительно: пропускная способность может быть выше, чем при throw/catch

Пример:


Result<User> result = userService.FindById(id);
if (!result.IsSuccess)
    return Error(result.Error);

Подробнее

1.92K views14:00

C# 1001 notes

🖥

Топ-10 ошибок .NET‑разработчиков

Если ты пишешь на .NET — возможно, ты хотя бы раз совершал одну из этих архитектурных (или просто утомительных) ошибок. Вот список анти-паттернов.

1. Blazor вместо React
Переизобретать веб на C# ради UI? Ты не Google. Если нужен зрелый фронт, бери то, что уже доказало свою масштабируемость.

2. Serverless Azure Functions на одном App Service Plan
"О, это же серверлесс!" — пока не замечаешь, что всё сидит на одном сервисе. Масштабируемость мнимая, расходы настоящие.

3. Самодельный MVC поверх Minimal APIs
Зачем ты пишешь свою обвязку маршрутов, контроллеров и зависимостей, если MVC уже всё это умеет?

4. Хранимки для CRUD
Хранимки — не антипаттерн, но когда их 200 штук для банального Insert/Update/Delete — это просто ORM с человеческим лицом, только сложнее.

5. "Юнит-тесты", которым нужен деплой БД
Это не юнит-тесты. Это интеграционные, а если быть честным — "fragile-тесты".

6. AutoMapper
В теории красиво, в проде — «а почему здесь null?». Иногда проще написать руками и понять, что происходит.

7. Игнор Microsoft Orleans
Если делаешь real-time, pub/sub, воркеры — Orleans стоит хотя бы попробовать. Он закрывает много боли, которую ты иначе сам будешь собирать по кускам.

8. Начинать с "микросервисов"
Монолит — не зло. Зло — это 12 проектов в solution, которые общаются через HTTP и собираются 10 минут.

9. gRPC для фронта
Если у тебя браузер → JS → gRPC → base64 → JSON — просто остановись. Возьми REST или GraphQL и живи спокойно.

10. Razor Pages вместо MVC
Да, они проще на старте. Но когда проект растёт, ты захочешь нормальное разделение по слоям, маршрутам и структуре.

🧠 Вывод: не все возможности .NET надо использовать. Иногда сила — в простоте.

C чем согласны ? Что добавили бы ?

#dotnet #csharp #webdev #архитектура #программирование

Please open Telegram to view this post

VIEW IN TELEGRAM

1.79K views11:32

C# 1001 notes

🔐 Блог DevelopersVoice выпустил отличный гайд по **10 главным уязвимостям веб‑приложений с примерами на .NET.

Что внутри:
• Инъекции и XSS
• Ошибки аутентификации
• Уязвимые зависимости
• SSRF и плохая конфигурация
• Проблемы с логированием и безопасным дизайном

📌 Всё с практическими советами: как обнаружить, как исправить, как не допустить.

Полный гайд тут: https://developersvoice.com/blog/secure-coding/owasp-top-ten

#OWASP #SecureCoding #DotNet #WebSecurity #DevTips

1.85K views06:58

C# 1001 notes

📌 PolySharp — удобный способ использовать новые фичи C# на старых версиях .NET. Этот NuGet-пакет работает как source-генератор, автоматически подбирая нужные полифиллы в зависимости от целевой платформы. Для работы достаточно добавить ссылку на PolySharp, установить последнюю версию C# и можно писать современный код даже для .NET Framework или UWP.

Инструмент обладает умной генерацией только необходимых типов. Например, если компилятору C# 13 нужен [IsExternalInit] для init-only свойств, PolySharp создаст его за кулисами. При этом он не трогает фичи, требующие поддержки рантайма, но покрывает огромный пласт синтаксических улучшений — от nullable-аннотаций до интерполированных строковых обработчиков.

🤖 GitHub

@csharp_ci

2.02K views07:46

C# 1001 notes

Какое исключение выдается, если протокол, поддерживаемый префиксом URI, недействителен?

Anonymous Quiz

10%

URLNotFound

29%

NotSupportedException

318 voters2.02K views09:30

C# 1001 notes

🔥 .NET Aspire: как упростить Service Discovery в микросервисах

Вместо ручной настройки адресов и портов, фреймворк .NET Aspire позволяет упростить обнаружение сервисов с помощью декларативного подхода.

🔹 Конфигурация через .AddProject() и .WithReference()
🔹 Сервисы автоматически "обнаруживаются" и подключаются
🔹 Поддержка локальной разработки, контейнеров и облака
🔹 Логи, метрики, health checks — встроены

📌 Aspire — это не просто упрощение разработки, это фундамент для масштабируемых .NET-приложений.

🧠 Полный разбор — в блоге:
[how-dotnet-aspire-simplifies-service-discovery](https://www.milanjovanovic.tech/blog/how-dotnet-aspire-simplifies-service-discovery)

Подпишись, чтобы не пропускать важные новинки .NET и облачной разработки.

1.62K views14:18

C# 1001 notes

😈 Хитрая задачка на C# — замыкания и ловушка в цикле

Что выведет этот код?


var actions = new List<Action>();

for (int i = 0; i < 5; i++)
{
    actions.Add(() => Console.WriteLine(i));
}

foreach (var action in actions)
{
    action();
}

На первый взгляд кажется, что будет:

Но на самом деле вывод:

💡 Почему?
Все лямбды замкнулись на одну и ту же переменную i, и когда они выполняются — i уже стало 5.

✅ Как исправить:


for (int i = 0; i < 5; i++)
{
    int copy = i;
    actions.Add(() => Console.WriteLine(copy));
}

Теперь всё работает как ожидается.

🧠 Замыкания в C# захватывают переменные, а не их значения! Аккуратнее с циклами и лямбдами.

1.58K views09:00

C# 1001 notes

Почти каждый разработчик допускал эту ошибку.

Что не так с этим кодом?

На первый взгляд всё кажется логичным:

🔸API-эндпоинт регистрации пользователя вызывает UserService

🔸

UserService сохраняет пользователя в базу и вызывает EmailService
🔸EmailService через SmtpClient отправляет письмо

Но если присмотреться, метод SendWelcomeEmail объявлен как async void.

В чём проблема с async void?

Вот суть:

❌

async void делает невозможным отлов исключений.

Если внутри SendEmailAsync() произойдёт исключение — catch его не перехватит.
Вместо этого приложение может тихо упасть или начать вести себя непредсказуемо.

Почему так происходит?

Методы async void не возвращают Task, поэтому вызывающий код не может их await-ить и обрабатывать ошибки.
Исключения из async void проходят мимо стандартных механизмов обработки.

Правильный подход:

✅Всегда возвращай Task

Запомни: async void допустим только для обработчиков событий, где возвращаемый void обязателен.

Please open Telegram to view this post

VIEW IN TELEGRAM

1.75K views10:03

C# 1001 notes

Правильный способ построения асинхронных API в .NET

Большинство API работают по простому шаблону:

🔸Клиент отправляет запрос
🔸Сервер выполняет работу
🔸Сервер возвращает ответ

Такой подход отлично работает для быстрых операций — например, получения данных или простых обновлений.

А что насчёт длительных операций?

Речь о задачах вроде:

> обработки больших файлов
> генерации отчётов
> конвертации видео

Такие процессы могут занимать от нескольких минут до часов.

Вот как можно правильно строить асинхронные API: читать

Как сообщить клиенту, что его запрос обработан?

Есть два подхода:

🔸PULL — клиент опрашивает API, чтобы узнать статус

🔸PUSH — сервер сам уведомляет клиента (через WebSocket, email и т.д.)

Please open Telegram to view this post

VIEW IN TELEGRAM

1.13K views12:00

C# 1001 notes

🧠 Задача: "Сколько раз выполнится блок Console.WriteLine?"


public class Program
{
    public static void Main()
    {
        var obj = new Counter();
        for (int i = 0; i < 3; i++)
        {
            Console.WriteLine(obj++);
        }
    }
}

public class Counter
{
    private int _value = 0;

    public static Counter operator ++(Counter c)
    {
        c._value++;
        return c;
    }

    public static implicit operator int(Counter c)
    {
        return c._value;
    }
}

❓Вопрос:
Что выведет программа?

🔍 Разбор:

На первый взгляд кажется, что программа выведет:

1
2
3

📎 Но на самом деле она выведет:

0
1
2

Почему?
Оператор obj++ — это постфиксный инкремент. Он:

сначала вызывает implicit operator int для текущего значения,

а затем вызывает operator ++.

То есть порядок такой:

Console.WriteLine(obj++) вызывает implicit int до инкремента

только потом ++ увеличивает значение.

✅ Что это проверяет:

Знание порядка вызова операторов (++ и implicit)

Понимание поведения постфиксных операций в .NET

Умение читать и анализировать перегрузки операторов

@csharp_1001_notes

1.02K views09:20

C# 1001 notes

862 views13:04

C# 1001 notes

🧼 Как элегантно работать с конфигами в .NET?

Раньше я просто тянул значения напрямую из IConfiguration.
Это быстро надоедает: много повторений, легко ошибиться, сложно валидировать.

Сейчас всегда использую Options pattern — и вот почему:

✅ Привязываешь конфигурацию к строго типизированным классам
✅ Добавляешь валидацию через аннотации
✅ Чисто внедряешь настройки через DI (`IOptions<T>` или `IOptionsSnapshot<T>`)

Отлично работает для:
- appsettings.json
- фичефлагов
- конфигов внешних сервисов

Если хочешь чистый и масштабируемый код — лучше подхода пока нет.

661 views08:03

About

Blog

Apps

Platform