Question about .NET Single File applications and CSX

[jogibear9988]

dotnet sopports in the new version single file applications, wich means you can run a .cs file directly. It also has support for some directives to include nugets, etc...

But I see there is also dotnet-script. It seems to be an extra github repository, but also some support for .csx files seems to be in roslyn (see https://learn.microsoft.com/en-us/dotnet/api/microsoft.codeanalysis.sourcecodekind?view=roslyn-dotnet-4.13.0)

I need a replacment for my T4 templates, and wanted to use csx (as single file cs has not yet all the features I need), but I don't get it. Is csx directly supported by microsoft? why is there a dotnet-script repository? Is it needed (if roslyn has direct support for csx)?
What is the future of csx? Will it still be supported or are the single file applications the way to go? (Or are the usecases so different).
In wich UI is csx supported (in vscode with C# & C# dev kit it seems not to).

[jjonescz]

as single file cs has not yet all the features I need

What features that you need do file-based apps not support?

Is csx directly supported by microsoft?

Csx is a scripting C# format that exists for a long time, it is an official Microsoft product, but it's also a dialect of C#, and hence not very widely used. File-based apps are a modern alternative that are just being introduced in .NET 10.

why is there a dotnet-script repository?

That is a third party repository.

Is it needed (if roslyn has direct support for csx)?

Roslyn supports csx, but there is no dotnet run command for it, that's why the third-party tool exists. You can however run csx files via C# Interactive window in Visual Studio and the corresponding csi tool which ships with Visual Studio.

What is the future of csx? Will it still be supported or are the single file applications the way to go?

Depends on what you mean by "supported". Bugs are probably going to be fixed, but new tooling investment seems unlikely to me.

Or are the usecases so different

Use-cases are a bit different. Csx supports interactive editing (REPL). File-based apps support converting to full projects later (thanks to not being a different C# dialect) and should be more performant and better integrated into .NET SDK tooling.

In wich UI is csx supported

In Visual Studio as I described above. Or you can use third-party tools like dotnet-script that you found.

Visual Studio Code and DevKit support the new file-based apps on the other hand (including debugging).

[jogibear9988]

And also we have some paid libs, wich we get as a DLL and not as nuget

[jogibear9988]

And what if there is no internet access to nuget where you want to run the cs file

[jjonescz]

Thanks for the motivating scenarios for referencing DLLs directly - cc @DamianEdwards

[DamianEdwards]

Referencing an assembly directly is something we scoped out for .NET 10 and in general as part of our desire to keep file-based apps highly focused on the scenarios we're targeting. We may revisit this decision in the future based on feedback and/or expansion of our target scenarios. That said, there are ways to work around the lack of direct support for referencing an assembly, namely via a Directory.Builds.targets file that's in a location the file-based app will load implicitly. Within that file you can reference an assembly as usual via the <Reference /> item.

[jogibear9988]

I'll get that. But if I need to do use Directory.Build.targets, then I could use directly a csproj.
As you already create virtual csproj files, to include a project reference nearly is the same as a nuget, and there is already a patch for it: dotnet/sdk#49216