Why dumb? Sure there is 1-2 syntax warts left, but the files are very expressive nowadays.
Half of the properties are XML attributes <tag ID=5> while the other half are child tags <tag><hello>5</hello></tag>
It's okay to read, but basically impossible to write by hand.
The tooling support is nothing like a JSON with JSON schema that gives you full intellisense with property autocomplete plus attribute description. (Imagine VSCode settings)
Is it, though? The guidelines seem to be pretty straight forward: unless you want to target a new language feature, you can just target netstandard or whatever target framework your code requires at the moment. This barely registers as a concern.
https://learn.microsoft.com/en-us/dotnet/standard/net-standa...
> It's okay to read, but basically impossible to write by hand.
Are you sure about that? I mean, what's the best example you can come up with?
This complain is even more baffling considering a) the amount of XML editor helpers out there, b) the fact that most mainstream build systems out there are already XML-based.
Targeting a specific .NET version will break in a year? LTS versions specifically have two years of support. But also .NET has very rarely broken backward compat and you can still easily load libraries built targeting .NET 5 in .NET 9 today. You don't necessarily have to "keep up with the treadmill". It's a good idea: see "free performance boosts when you do". But it isn't required and .NET 5 is still a better target from today's perspective than .NET Standard 2.0. (The biggest instance I know of a backwards compatibility break in .NET was the rescoping between .NET [Framework] 3.5.x and .NET [Framework] 4.0 on what was BCL and what was out/no longer supported and that was still nothing like Python 2 versus 3. I know a lot of people would also count the .NET Framework 4.x and .NET Core 1.0 split, too, which is the reason for the whole mess of things like .NET Standard, but also .NET Standard was the backward compatibility guarantee and .NET Standard 2.0 was its completion point, even though yes there are versions > 2.0, which are even less something anyone needs to worry about today.)
For instance, GraphQL was built targeting both .NET 5 and .NET Standard 2.0, as you can see towards the top of the NuGet page: https://www.nuget.org/packages/GraphQL
.NET 9 will use the .NET 5 build, not .NET Standard 2.0. (.NET Framework 4.8.x would use .NET Standard 2.0.) Because .NET 5 > .NET Standard 2.0.
Or Automapper 14 targets only .NET 8: https://www.nuget.org/packages/AutoMapper
It runs on .NET 9 and .NET 10.
Just to pick two examples at mostly random from the top packages on NuGet.
I don't think there are any good project definition files. At least csproj is standardised XML, so your IDE can tell if you're allowed to do something or not before you try to hit build.
As for targeting frameworks and versions, I think that's only a problem on Windows (where you have the built in one and the one(s) you download to run applications) and even then you can just target the latest version of whatever framework you need and compile to a standard executable if you don't want to deal with framework stuff. The frameworks themselves don't have an equivalent in most languages, but that's a feature, not a bug. It's not even C# exclusive, I've had to download specific JREs to run Java code because the standard JRE was missing a few DLLs for instance.
Except this is also worse because this is the same Microsoft commitment to backwards compatibility of "dead languages" that leads to things like the VB6 runtime still being included in Windows 11 despite the real security support for the language itself and writing new applications in it having ended entirely in the Windows XP era. (Or the approximately millions of side-by-side "Visual C++ Redistributables" in every Windows install. Or keeping the Windows Scripting Host and support for terribly old dialects of VBScript and JScript around all these decades later, even after being known mostly as a security vulnerability and malware vector for most of those same decades.)
What do you think happens when you try to use Python 3.9 to run a script that depends on features added in 3.10? This is inherent to anything that requires an interpreter or runtime. Most scripting tools just default "your stuff breaks if you get it wrong" whereas .Net requires you to explicitly define the dependency.
It's gotten real simple in the last few years, and is basically the exact same flowchart as Node.JS:
Do you need LTS support? --> Yes --> target the most recent even number (.NET 8.0 today)
^--> No --> target the most recent version (.NET 9.0 today)
Everything else can be forgotten. It's no longer needed. It's no longer a thing. It's a dead version for people that need deep legacy support in dark brownfields and nothing more than that.