Back when I last used C#, which admittedly is over 10 years ago, .csproj files were written in XML so they were annoying to edit. It was difficult to understand the structure of them, and I'm not sure if they were documented very well.
Just compare a .csproj to something modern like a Cargo.toml and you'll see why someone might think .csproj is awful. It is immediately obvious what each section of a Cargo.toml does, and intuitive how you might edit or extend them.
Also, just talk to a C# developer, I bet over half of them have never even edited a .csproj and only use visual studio as a GUI to configure their projects.
Very outdated view. Csproj files got hugely simplified with dotnet core, and thanks God they kept the XML format instead of the JSON they tried at first.
"SDK-Style csproj" has been around since .NET 5. They are pretty great and not bad to hand edit. Starts as just:
(It's named "SDK-style" because that Sdk="Sdk.Name" attribute on the Project tag does a ton of heavy lifting and sets a lot of smart defaults.)In the "SDK-Style", files are included by default by wildcards, you no longer need to include every file in the csproj. Adding NuGet references by hand is now just as easy as under an <ItemGroup> add a <PackageReference Include"Package.Name" Version="1.0.0" />. (For a while NuGet references were in their own file, but there would also be a dance of "assembly binding redirects" NuGet used to also need to sometimes include in a csproj. All of that is gone today and much simplified to a single easy to write by hand tag.) Other previously "advanced" things you'd only trust the UI to do are more easily done by hand now, too.
> Also, just talk to a C# developer, I bet over half of them have never even edited a .csproj and only use visual studio as a GUI to configure their projects.
Depends on the era, but in the worst days of the csproj verbosity where every file had to be mentioned (included as an Item) in the csproj I didn't know a single C# developer that hadn't needed to do some XML surgery in a csproj file at some point, though most of that was to fix merge conflicts because back then it was a common source of merge conflicts. Fixing merge conflicts in a csproj used to be a rite of passage for any reasonably sized team. (I do not miss those days and am very happy with the "SDK-Style csproj" today.)
The immediately obvious Cargo.toml is