Файловые приложения .NET 10 получили скрипты из нескольких файлов: на подходе `#:include`

История “файловых приложений” в .NET 10 продолжает становиться всё практичнее. Новый pull request в SDK добавляет поддержку #:include, а это значит, что dotnet run foo.cs больше не обязан быть “один файл или ничего”.

В SDK это отслеживается как “File-based apps: add support for #:include” и призвано решить очевидный сценарий скриптинга: разделить код на основной скрипт и вспомогательные модули, не создавая полноценный проект.

Почему многофайловость важна для dotnet run file.cs

Боль проста. Если ваш скрипт выходит за рамки одного файла, у вас два варианта:

• Скопировать/вставить вспомогательный код в тот же файл (быстро становится нечитаемым), или
• Сдаться и создать полноценный проект (убивает рабочий поток “быстрый скрипт”).

Желаемое поведение прямо описано в issue SDK: dotnet run file.cs должен уметь использовать код из соседнего util.cs без дополнительных церемоний.

Что меняет #:include

С #:include основной файл может подтягивать другие .cs файлы, чтобы компилятор видел единую единицу компиляции при запуске. Это недостающий мост между “ощущением скрипта” и “реальной организацией кода”.

Это не возможность языка C#; это возможность .NET SDK для файловых приложений. Это важно, потому что она может быстро развиваться в превью .NET 10, не дожидаясь новой версии языка.

Крошечный многофайловый скрипт, который реально запускается

Каталог:

app\
  file.cs
  util.cs

file.cs:

#:include "util.cs"

Console.WriteLine(Util.GetMessage());

util.cs:

static class Util
{
    public static string GetMessage() => ".NET 10 file-based apps can include files now.";
}

Запустите его с превью SDK .NET 10:

dotnet run app/file.cs

Две детали из реальной жизни, на которые стоит смотреть

Кеширование может скрывать изменения

Файловые приложения опираются на кеширование, чтобы запуски внутреннего цикла оставались быстрыми. Если подозреваете, что видите устаревший вывод, перезапустите с --no-cache, чтобы принудительно пересобрать.

Элементы не .cs могут осложнить “быстрый путь”

Если вы делаете файловые приложения с частями Web SDK (например .razor или .cshtml), есть открытый issue про инвалидцию кеша при изменении дефолтных элементов, отличных от .cs. Учитывайте это, прежде чем рассматривать файловые приложения как замену настоящего проекта приложения.

Если хотите отслеживать конкретный выкат, начните здесь:

• PR: https://github.com/dotnet/sdk/pull/52347
• Issue со сценарием множественных файлов: https://github.com/dotnet/sdk/issues/48174