| 1 | ## .NET runtimes and targets — fundamentals |
| 2 | |
| 3 | **Назначение:** дать опорную картину того, что такое .NET Framework vs .NET (Core), какие есть рантаймы, TFMs и базовые модели приложений, чтобы дальше обсуждать практики и playbook’и на общей базе. |
| 4 | |
| 5 | --- |
| 6 | |
| 7 | ### 1. Линии .NET: Framework vs .NET (Core/5+) |
| 8 | |
| 9 | - **Fact:** .NET Framework — исходная Windows‑ориентированная линия (1.0–4.8.1) с фиксированным жизненным циклом и тесной интеграцией с Win32/COM/WinForms/WPF/ASP.NET; .NET (Core/5+) — кроссплатформенная линия с собственным рантаймом, SDK и modern lifecycle (STS/LTS). |
| 10 | - **Heuristic:** при любой архитектурной дискуссии сначала явно называть линию (`.NET Framework 4.8` vs `.NET 8/10`), не смешивать их под общим «.NET»; все новые проекты по умолчанию должны целиться в современный `.NET` (8/10), а не во Framework. |
| 11 | - **First adoption task:** для всех активных проектов составить таблицу: название → линия (`Framework`/`NET`) → целевой TFM → поддержка (LTS/STS/EOL) → OS‑scope. |
| 12 | - **Success criterion:** нет проектов с «размытым» понятием целевого рантайма; любое обсуждение начинается с явного указания линии и версии. |
| 13 | - **Confidence:** high |
| 14 | |
| 15 | --- |
| 16 | |
| 17 | ### 2. TFMs и multi‑targeting |
| 18 | |
| 19 | - **Fact:** целевая платформа в .NET задаётся Target Framework Moniker (TFM), например: `net48`, `net8.0`, `net10.0`, `netstandard2.0`; мульти‑таргетинг (`<TargetFrameworks>`) позволяет одной библиотеке собирать несколько вариантов для разных рантаймов. |
| 20 | - **Heuristic:** для библиотек, которые должны жить долго и использоваться из разных приложений, разумно иметь «минимальный» TFM (часто `netstandard2.0` или `net6.0`) плюс «современный» (`net8.0/net10.0`) для доступа к новым возможностям; для приложений достаточно одного «правильного» TFM. |
| 21 | - **First adoption task:** выбрать и зафиксировать стандартизированный набор TFMs для: (1) общих библиотек, (2) внутренних микросервисов, (3) desktop‑клиентов. |
| 22 | - **Success criterion:** меньше случайных TFM’ов в новых проектах; выбор оправдан архитектурно, а не дефолтом шаблона. |
| 23 | - **Confidence:** medium |
| 24 | |
| 25 | --- |
| 26 | |
| 27 | ### 3. Базовые модели приложений в .NET |
| 28 | |
| 29 | - **Fact:** основные типы приложений в современном .NET: консольные утилиты/демоны, ASP.NET Core (Web/API/SignalR), worker‑службы (фоновые задачи/шины), desktop (WPF/WinForms/Maui), плюс библиотеки (class libraries, analyzers, source generators). |
| 30 | - **Heuristic:** при старте проекта выбирать модель приложения из списка «канонических» и не городить свой собственный bootstrap/хост, пока нет жёсткой причины; это упрощает диагностику, деплой и сопровождение. |
| 31 | - **First adoption task:** для каждого нового сервиса/утилиты явно указать в README: тип приложения, используемый hosting‑модель/шаблон и предполагаемый способ деплоя. |
| 32 | - **Success criterion:** новый разработчик по одному взгляду на README/`Program.cs` понимает, к какому стандартному шаблону относится приложение и как оно живёт. |
| 33 | - **Confidence:** medium |
| 34 | |
| 35 | --- |
| 36 | |
| 37 | ### 4. SDK, CLI и layout проекта |
| 38 | |
| 39 | - **Fact:** `dotnet` CLI и SDK задают единую модель: restore → build → test → publish, с поддержкой `global.json` для фиксации версии SDK и общих `Directory.Build.props/targets` для политики сборки. |
| 40 | - **Heuristic:** воспринимать SDK+CLI как «источник правды» по сборке/запуску; все IDE/CI‑конфигурации должны быть тонкими оболочками поверх `dotnet`‑команд, а не альтернативными путями. |
| 41 | - **First adoption task:** для ключевых репозиториев описать в документации «канонический» набор команд (`dotnet restore/build/test/publish`) и добавить пример `global.json`. |
| 42 | - **Success criterion:** разработчики и CI используют одни и те же команды, нет расхождений между «как собирает IDE» и «как собирает пайплайн». |
| 43 | - **Confidence:** high |
| 44 | |
| 45 | --- |
| 46 | |
| 47 | ### 5. Управляемый мир vs нативный мир |
| 48 | |
| 49 | - **Fact:** код .NET работает на CLR/ CoreCLR с JIT или AOT, управляемой памятью и богатой BCL; выход в нативный мир (P/Invoke, COM, C++/CLI, ICU, CUDA и др.) происходит через чётко определённые межъязыковые «швы». |
| 50 | - **Heuristic:** относиться к границам между .NET и нативным кодом как к высокорисковым местам: минимизировать поверхность, фиксировать контракт (ABI, версии), иметь отдельные тесты/диагностику на этих швах. |
| 51 | - **First adoption task:** для любого нового проекта с нативной интеграцией нарисовать схему: какие модули остаются полностью в .NET, какие в C/C++/CUDA, и где именно проходят границы и marshaling. |
| 52 | - **Success criterion:** проблемы на стыке .NET↔native локализуются быстро, без необходимости разбирать сразу всю систему. |
| 53 | - **Confidence:** medium |
| 54 | |
| 55 | |
| 56 | |