🚀 .NET 10 Preview 3 уже доступен!
Новая версия приносит мощное обновление для C# — Extension Members:

💡 Теперь можно добавлять в static class расширения не только методов, но и:

▪ 🔹 Статические методы
▪ 🔹 Инстанс-свойства
▪ 🔹 Статические свойства

📦 Это значит, что вы можете "расширять" поведение типов не только логикой, но и дополнительными данными и даже стейтфул-логикой (через свойства).
И всё это — без изменения исходного класса.

🔗 Подробнее:
https://github.com/dotnet/core/blob/main/release-notes/10.0/preview/preview3/csharp.md#extension-members

#dotnet #csharp #dotnet10 #devtools #preview

@csharp_ci

🧹 Разделение классов на отдельные файлы в ReSharper — автоматически

Если вы работаете с большими C#‑файлами, где собрано по 3–5 классов в одном месте, ReSharper теперь позволяет разнести все классы по отдельным файлам в один клик.

🔧 Что умеет:
▪️ Автоматически определяет все вложенные классы, интерфейсы, enum’ы
▪️ Создаёт новые `.cs`‑файлы с соответствующими именами
▪️ Упрощает навигацию и соблюдение best practices

📌 Где искать:
Refactor This → Move to Separate Files
или
Context Action (Alt+Enter) → Move All Types to Separate Files

📎 Инструкция от JetBrains:
https://www.jetbrains.com/help/resharper/Move_classes_into_separate_files_in_one_go.html

💡 Подходит для чистки легаси-кода и ускорения навигации в больших проектах .NET.

#CSharp #ReSharper #Refactoring #JetBrains #DotNet #DevTools #CodeQuality

🕹️ NET-NES — эмулятор легендарной NES, написанный на C# и Raylib

После создания собственного эмулятора GameBoy (**CODE-DMG**), следующий шаг был очевиден — NES. Консоль, оставившая след не только в истории видеоигр, но и в электронике, вдохновила на создание нового проекта — NET-NES.

🎮 Что такое NET-NES?
Это NES-эмулятор, написанный на C# с использованием Raylib. Он уже способен запускать множество классических хитов от Nintendo.

📜 Немного истории:
• NES (Nintendo Entertainment System) — вышла в Японии как FamiCom в 1983 году
• В 1985 появилась в Северной Америке, где спасла индустрию после видеоигрового краха 1983 года
• Продавалась как "игрушка" — и изменила всё

🧠 Аппаратная часть NES:
• 8-битный CPU Ricoh 2A03 (~1.79 МГц), основанный на MOS 6502
• Встроенный APU (аудио)
• Видео: Ricoh 2C02 — вывод 256×240, палитра 64 цвета
• 2 КБ RAM + 2 КБ VRAM
• ROM‑картриджи с мапперами для расширения памяти и графики

🛠️ Почему C# и Raylib?
• Потому что C# — удобен, современен и любим
• Raylib — весёлый, минималистичный и идеально подходит для 2D-рендера
• А название NET-NES — от .NET и NES, звучит круто 😄


🔗 GitHub: github.com/Paulescu/NET-NES

#nes #dotnet #emulation #gamedev #csharp #retrogaming

@csharp_ci

⚙️ Background Jobs в ASP.NET Core — просто и эффективно

Хочешь запускать периодические задачи в фоне? В ASP.NET Core это можно реализовать с помощью BackgroundService и PeriodicTimer. Ни Hangfire, ни Quartz не нужны, если всё просто.

🧱 Основные шаги:

1. ✅ Включаем конкурентный запуск/остановку сервисов:

builder.Services.Configure<HostOptions>(o =>
{
    o.ServicesStartConcurrently = true;
    o.ServicesStopConcurrently = true;
});

2. 🌀 Реализуем фоновую задачу:

public class PeriodicBackgroundTask : BackgroundService
{
    private readonly TimeSpan _period = TimeSpan.FromSeconds(5);
    private readonly ILogger<PeriodicBackgroundTask> _logger;

    public PeriodicBackgroundTask(ILogger<PeriodicBackgroundTask> logger)
    {
        _logger = logger;
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        using PeriodicTimer timer = new PeriodicTimer(_period);
        while (!stoppingToken.IsCancellationRequested &&
               await timer.WaitForNextTickAsync(stoppingToken))
        {
            _logger.LogInformation("Executing PeriodicBackgroundTask");
        }
    }
}

📌 Особенности:
- BackgroundService — стандартный способ запускать фоновые задачи в ASP.NET Core
- PeriodicTimer — простой способ повторять с задержкой
- Встроенный контроль остановки через CancellationToken

💡 Подходит для:
• Регулярных проверок
• Очистки кэша
• Периодических sync-задач

#aspnetcore #dotnet #backgroundjobs #csharp #dev

📘 Обновлённый обзор C#: история версий и ключевые новшества

Microsoft опубликовала подробную хронологию C# — от версии 1.0 до последней, показывая эволюцию языка за 20+ лет:

🕰️ Обзор ключевых этапов:

• C# 1.0–2.0 — классика: базовые ООП, exception-обработка, типы значений, generics
• C# 3.0 — революция LINQ, lambda`-выражения, автоматические свойства, `var
• C# 4.0 — dynamic, улучшения COM и переговорчивость аннотации
• C# 5.0 — async/await — асинхронность для всех
• C# 6.0 — улучшения синтаксиса: string interpolation, expression-bodied members, null-условные выражения
• C# 7.x — tuples, pattern matching, ref locals, out variables
• C# 8.0 — nullable reference types, ranges/indices, асинхронные потоки
• C# 9.0 — record, init-only properties, top-level statements
• C# 10 — глобальные using, file-scoped namespace, улучшенные структуры
• C# 11 — raw string literals, generic math, pattern matching improvements
• C# 12 и далее — ожидаются расширенные метапрограммирование, списочные выражения, улучшения в безопасность и производительности

🔧 Почему это важно:

• Язык постоянно развивается, становясь выразительнее, безопаснее и удобнее
• Новые версии дают мощные инструменты — для асинхронного программирования, функционального стиля и более чистого кода
• Понимание изменений помогает быстрее адаптироваться к трендам и выбирать актуальный инструментальный стек

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

👉 Подробнее

@csharp_ci

#dotnet #csharp #programming #developer #language #whatsnew #technology

🚀 Микросервисная платформа для страхования

Yosef — это открытая микросервисная платформа для финансовой страховой отрасли, разработанная на .NET, Python, TypeScript и Golang. Она обеспечивает масштабируемость, гибкость и высокую наблюдаемость для современных страховых приложений.

🚀 Основные моменты:
- Микросервисная архитектура для легкости масштабирования
- Централизованное управление идентификацией и доступом
- Полный цикл страхования от оценки до создания полиса
- Высокая наблюдаемость с использованием Grafana и Prometheus
- Интеграция с современными инструментами безопасности

📌 GitHub: https://github.com/elyosemite/Yosef

#csharp

🛡️ Запуск программ с защитой PPL

CreateProcessAsPPL — инструмент для запуска приложений с включенной защитой PPL. Позволяет выбирать уровень защиты для повышения безопасности выполнения программ.

🚀 Основные моменты:
- Поддержка нескольких уровней защиты PPL.
- Удобный интерфейс командной строки.
- Полезен для разработчиков и исследователей безопасности.

📌 GitHub: https://github.com/2x7EQ13/CreateProcessAsPPL

#csharp

🔍 ZeroTrace: Утечка данных из браузеров и мониторинг клиентов

ZeroTrace — это мощный инструмент для сбора и анализа данных с удалённых клиентских машин. Он поддерживает извлечение паролей, куки и историю браузера, обеспечивая безопасность и эффективность работы.

🚀 Основные моменты:
- Извлечение паролей и куки из Chrome и других браузеров
- Реальное время мониторинга клиентов с анализом соединений
- Безопасная передача данных с шифрованием
- Поддержка различных операционных систем и браузеров

📌 GitHub: https://github.com/luis22d/ZeroTrace-Stealer-13-2026

#csharp

🛠️ Инструмент для дампа памяти защищённых процессов

WSASS использует старую программу WerfaultSecure.exe для создания дампов памяти процессов, защищённых PPL, таких как LSASS.EXE. Выходные данные сохраняются в формате MINIDUMP, с автоматической заменой заголовка на PNG для удобства.

🚀 Основные моменты:
- Дамп защищённых процессов с помощью WerfaultSecure.exe
- Выход в формате Windows MINIDUMP
- Автоматическая замена заголовка файла
- Полезен для анализа безопасности

📌 GitHub: https://github.com/TwoSevenOneT/WSASS

#csharp

⚙️ 3 способа определить Middleware в ASP.NET Core

Middleware - это компоненты, которые добавляют дополнительную логику до или после обработки HTTP-запроса.

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

🔧 В ASP.NET Core уже встроено множество middleware (Static Files, Routing, Authentication и др.),
но вы можете создавать и свои собственные.

Вот три основных способа это сделать:
- Request Delegates - определяете логику прямо в app.Use(...)
- Convention-based - создаёте класс с методом Invoke или InvokeAsync
- Factory-based - используете фабрику с внедрением зависимостей (DI)

🧠 Подробный разбор и примеры кода - в статье


#dotnet #aspnetcore #backend #middleware #csharp

🛡️ Новая обработка ошибок в .NET 10 - `IExceptionHandler`

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

В .NET 10 появился интерфейс IExceptionHandler, который реализует паттерн try- прямо внутри middleware.

### Как это работает?

✅ Ты сам указываешь, какие типы исключений хочешь перехватывать
✅ Если ты обработал ошибку — возвращаешь true, и цепочка остановится
✅ Можно выстроить несколько обработчиков подряд — они вызовутся по очереди, пока один не справится

📦 Это больше не про громоздкие try-catch или тонны if — теперь всё централизовано и масштабируемо.

🔧 Идеально для:
- Глобальной обработки ошибок
- Разделения логики по типам исключений
- Подключения к логгерам, метрикам, retry-логике

📚 Пример кода и объяснение:


Подходит всем, кто пишет на ASP.NET Core или строит APIЭ

#dotnet #aspnetcore #обработкаошибок #middleware #backend #csharp

🎮 Создайте игры с s&box!

s&box — это современный игровой движок на основе Source 2 от Valve и новейших технологий .NET. Он предлагает интуитивно понятный редактор для разработки игр и предоставляет возможность компилировать движок из исходников для тех, кто хочет внести свой вклад в его развитие.

🚀 Основные моменты:
- Современный игровой движок с мощным редактором.
- Основан на Source 2 и .NET технологиях.
- Поддержка разработки и компиляции из исходников.
- Полная документация и обучающие материалы доступны онлайн.

📌 GitHub: https://github.com/Facepunch/sbox-public

#csharp

🔍 Инструмент для перехвата сессий в C#

SessionHop — это утилита на C#, использующая COM-объект IHxHelpPaneServer для перехвата пользовательских сессий. С помощью создания "сессионного моникера" и интерфейса Execute можно запускать произвольные файлы в контексте другой сессии, что полезно для таких задач, как кейлоггинг или скриншоты.

🚀Основные моменты:
- Перехват сессий пользователей с помощью COM-объекта.
- Запуск файлов в контексте другой сессии.
- Альтернатива удаленному инжектированию процессов.
- Полезен для доступа к ресурсам как затронутый пользователь.

📌 GitHub: https://github.com/3lp4tr0n/SessionHop

#csharp

💡 Soft delete в EF Core без лишней логики в сервисах

Удалять данные физически — не всегда хорошая идея.
Логи, аудит, восстановление, аналитика — всё это требует soft delete.

Вот удобный способ реализовать его через EF Core interceptor.

Что делает перехватчик:

- Проверяет ChangeTracker на сущности с интерфейсом ISoftDeletable
- Если состояние сущности — Deleted
- Меняет его на Modified
- Устанавливает:
- IsDeleted = true
- DeletedOnUtc = DateTime.UtcNow

В итоге:

Вы вызываете обычный:

context.Remove(entity);

А в базе:

- запись не удаляется
- просто помечается как удалённая

Плюсы подхода:

- никакой логики soft delete в сервисах и репозиториях
- единая точка обработки
- чистый доменный код
- безопасное удаление по всему приложению

Важно:

Если у вас есть связанные сущности (navigation properties),
перехватчик нужно дополнительно расширить — каскадное soft-удаление EF Core не делает автоматически.

Soft delete через interceptor — это один из самых чистых production-подходов для EF Core.

#dotnet #EFCore #Backend #Architecture #CSharp

Разработчик показал, как использовать Ollama для извлечения данных из чеков прямо в .NET.

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

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

Обычный текстовый ответ мало помогает, когда нужны структурированные данные:

- позиции из чека
- количество
- цены
- итоговая сумма

Поэтому вместо обычного ответа модель начали просить возвращать JSON.

После этого результат можно сразу маппить в C#-объекты и использовать в приложении.

И именно здесь начинается самое интересное.

Большая часть работы — не код, а правильный prompt.

Если модель:

- округляла цену
- пропускала цифру
- или «придумывала» позицию

приходилось уточнять инструкции.

Это и есть главный сдвиг в таком подходе:

раньше разработчик писал парсеры и regex,
а теперь — настраивает поведение модели через prompt.

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

Разбор полной реализации:

https://milanjovanovic.tech/blog/how-to-extract-structured-data-from-images-using-ollama-in-dotnet

🚀 Max

#ai #ollama #dotnet #csharp

🐳 «Используй Testcontainers вместо in-memory» - это только половина правды

Все уже выучили: EF Core InMemory provider - не интеграционный тест.

Он не ловит:

- баги в LINQ-трансляции
- ограничения БД
- коллации
- реальные типы колонок
- поведение конкретного SQL-провайдера

Окей, заменили на реальный PostgreSQL через Testcontainers. Победа? Не совсем.

Вот что начинается дальше.

1. Вы получили «медленное враньё» вместо «быстрого»

Поднимать контейнер на каждый тест-класс - быстрый способ превратить CI из 30 секунд в 8 минут.

Нормальный вариант:

- один контейнер на всю тестовую сессию
- изоляция данных между тестами через Respawn
- без пересоздания базы и контейнера каждый раз

Respawn чистит таблицы с учётом графа foreign keys за миллисекунды.

2. Транзакционный откат ≠ реальный сценарий

Трюк «обернули тест в транзакцию и откатили» красиво выглядит, но ломается, когда в коде есть:

- свои транзакции
- несколько SaveChanges
- фоновые операции
- поведение, завязанное на commit

В итоге тестируется сценарий, которого в проде нет.

3. Самая коварная ловушка - общий DbContext

Если тест и код используют один экземпляр DbContext, EF может вернуть данные из change tracker, а не из базы.

Тест зелёный, но он врёт: реальный SQL-запрос мог вообще не выполниться.

Между Act и Assert стоит чистить трекер:

Db.ChangeTracker.Clear();

4. Бонус, который теряют 90% команд - тест миграций

Реальная БД позволяет прогнать EF-миграции на чистой схеме.

Если миграция падает или схема разъехалась с моделью, вы узнаёте об этом в CI, а не в проде в пятницу вечером.

Пример базового подхода:

public class IntegrationTestBase : IAsyncLifetime
{
    private static readonly PostgreSqlContainer _db =
        new PostgreSqlBuilder()
            .WithImage("postgres:16-alpine")
            .Build();

    private Respawner _respawner = null!;
    protected AppDbContext Db = null!;

    public async Task InitializeAsync()
    {
        await _db.StartAsync();

        var options = new DbContextOptionsBuilder<AppDbContext>()
            .UseNpgsql(_db.GetConnectionString())
            .Options;

        Db = new AppDbContext(options);

        // Реальные миграции - заодно проверяем, что они накатываются
        await Db.Database.MigrateAsync();

        await using var conn = new NpgsqlConnection(_db.GetConnectionString());
        await conn.OpenAsync();

        _respawner = await Respawner.CreateAsync(conn, new RespawnerOptions
        {
            DbAdapter = DbAdapter.Postgres,
            SchemasToInclude = ["public"]
        });
    }

    // Сброс данных перед каждым тестом - без пересоздания контейнера
    protected async Task ResetAsync()
    {
        await using var conn = new NpgsqlConnection(_db.GetConnectionString());
        await conn.OpenAsync();

        await _respawner.ResetAsync(conn);

        // Иначе тест может читать из кеша, а не из БД
        Db.ChangeTracker.Clear();
    }

    public Task DisposeAsync() => Task.CompletedTask;
}

Testcontainers - это не галочка «best practice», а смена философии.

Без нормальной изоляции данных вы просто пересели с быстрого вранья на медленное.

А как вы изолируете состояние БД между интеграционными тестами - Respawn, транзакции или пересоздание контейнера?

#dotnet #csharp #testing #efcore

⚡️ Почему Repository поверх EF Core часто превращается в лишний слой

Многие .NET-проекты начинают с отдельных репозиториев:

GetPostsByUser(...)
GetPopularPosts(...)
GetPostsByCategory(...)
GetRecentViralPosts(...)

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

Проблема в том, что DbContext уже предоставляет возможности, близкие к Repository и Unit of Work. Дополнительный слой часто усложняет запросы, скрывает возможности EF Core и создаёт абстракцию поверх абстракции.

Один из вариантов решения — Specification Pattern.

Каждая спецификация описывает отдельное условие выборки:

var specification =
    new ViralPostSpecification(minLikesCount: 150);

var posts = await dbContext.Posts
    .ApplySpecification(specification)
    .Select(post => post.ToDto())
    .ToListAsync(cancellationToken);

Спецификации можно переиспользовать и комбинировать:

var combinedSpec =
    recentSpec.And(highEngagementSpec);

Что это даёт:

- фильтры не размножаются по репозиториям
- запросы остаются рядом с бизнес-правилами
- спецификации проще тестировать
- условия можно комбинировать
- IQueryable продолжает переводиться в SQL

Repository Pattern полезен, когда действительно изолирует сложную инфраструктуру или несколько источников данных. Но создавать отдельный репозиторий для каждой сущности только ради шаблона часто означает лишнее усложнение архитектуры.

#dotnet #csharp #efcore #architecture

💡 C#: заставьте архитектуру ломать CI, если кто-то нарушил правила

Компилятор C# отлично проверяет типы, но ему всё равно, что Application внезапно начал зависеть от Infrastructure.

Code Review тоже не гарантирует, что такое заметят.

Для этого можно использовать Architecture Tests — тесты, которые проверяют не бизнес-логику, а структуру проекта.

Например, через NetArchTest.Rules:

[Fact]
public void Application_Should_Not_Depend_On_Infrastructure()
{
    var result = Types
        .InAssembly(ApplicationAssembly)
        .ShouldNot()
        .HaveDependencyOn("MyApp.Infrastructure")
        .GetResult();

    Assert.True(result.IsSuccessful);
}

Теперь случайный:

Application → Infrastructure

сломает CI так же, как обычный упавший unit-тест.

Можно зафиксировать и naming convention:

[Fact]
public void Handlers_Should_End_With_Handler()
{
    var result = Types
        .InAssembly(ApplicationAssembly)
        .That()
        .ImplementInterface(typeof(ICommandHandler<>))
        .Should()
        .HaveNameEndingWith("Handler")
        .GetResult();

    Assert.True(result.IsSuccessful);
}

Или заставить сервисы быть sealed:

Types
    .InAssembly(ApplicationAssembly)
    .That()
    .HaveNameEndingWith("Service")
    .Should()
    .BeSealed();

Особенно полезно это становится в больших Clean Architecture / DDD / Modular Monolith проектах.

Вместо документа:

❌ «Application не должен зависеть от Infrastructure»

получаем исполняемое правило:

✅ нарушил архитектуру → тест упал → PR не прошёл

По сути, архитектура превращается из договорённости команды в часть автоматической проверки проекта.

#CSharp #DotNet #Architecture #Testing