Comment by oneplane
4 days ago
It's still stuck in weird formats and monoliths. A lot of GUI-only stuff has been ported to the mega CLI, but it's still the weird Visual Studio format plus XML files that you cannot replace with a simple Makefile. You still can't just compile a bit of C# as-is, it must have the Solution, Project, Assembly etc. chain, the run-as-script feature is nice (lots of cheers when that was presented! even on the live stream), but it's specifically not designed to allow you to assemble a toolchain that works for what you need. There is only one and it has everything, no options.
The question, of course, becomes: when does that matter? For a lot of people who are in to .NET, they see that as a benefit. Look at Go through this lens, and it's similar; the go CLI is the compiler, linker, package manager etc. I suppose the biggest difference is that it doesn't prescribe solutions and projects and file formats to go with them, which enables you to put this in any existing CI, make or other system.
> it's still the weird Visual Studio format
.NET 9 (and VS2022) added support for the SLNX replacement format to replace the old weird solution format:
https://devblogs.microsoft.com/visualstudio/new-simpler-solu...
Yep, but you still can't say "compile and link everything in this tree". Technically, the language can, but the framework assumes specific compiler, linker and layouts on the filesystem so at that point you can't. It really wants that editor-related stuff to be part of the framework, and everything else has to bend for it.
A Project file today can just be a full tree glob. New projects start out in that form. The `dotnet` CLI is still going to assume some default output paths as it builds object files and executable assets, but those are all easily flag configurable today. (I've done some wild CI things.)
You don't have to use a Solution at all with the CLI, you can do everything in a single Project and one full tree glob. (Technically you haven't need a Solution with Visual Studio for a long while either, if you don't mind it sometimes auto-creating them at compile time, and even then you can just .gitignore .sln and not care. But even that random auto-.sln file thing has disappeared in recent years and Visual Studio has learned more auto-workspace tricks from VS Code.)
I have started projects that just did that, started with a simple glob-only project and no prescribed file layout.
Yeah, dotnet doesn't let you micro-manage the linker specifically, but few languages since C++ do and arguably the C/C++ linker sometimes seems as much a bug of C/C++ as a feature in modern times.