Add .NET 10 support #2642
Add .NET 10 support #2642
Conversation
| /// <summary> | ||
| /// .NET 10.0 | ||
| /// </summary> | ||
| Net100, |
There was a problem hiding this comment.
Should we start adding _ here?
| Net100, | |
| Net10_0, |
There was a problem hiding this comment.
I think we should really consider moving away from these strong type names. This is too much ceremony to issue a nice message. If the underlying SDK doesn't support the TFM, it issues a very reasonable, comprehensive and googleable error message. For the other use-case, consider string parameter [SupportedFramework("netX.Y")] rather than these unscalable abstractions which we can't get rid of even after the TFM is rendered unsupported by rest of the ecosystem.
There was a problem hiding this comment.
Added underscore. However, the way SDK (and other parts of ecosystem) is handling these validations is they rely on common implementation in the SDK. If the underlying SDK doesn't support the TFM, it will report the error. Then there is the new concept of "torn SDK" in .NET 9, which makes the tooling download the required SDK. For NativeAOT, LLVMAOT, Mono runtime etc. there are flags like --aot available on command line (e.g. dotnet new console --aot).
BDN has gone in other direction with these dedicated monikers, nativeaot9.0 etc., which IMHO is an unnecessary maintenance headache, one we can easily avoid by using stringly arguments.
am11
force-pushed
the
update-templates
branch
from
64dc9bb
to
da35b1c
Compare
am11
force-pushed
the
update-templates
branch
from
da35b1c
to
3357418
Compare
|
I've tested this PR against a local build from dotnet/runtime#106599 and it fails because it seems that the .NET 10 SDK doesn't actually allow to target .NET 10, rather it only allows targetting .NET 9. To get things to work we do need to make changes to the SDK validator to allow backwards compatibility. However, this change will still be useful to have in once we do have .NET 10 targeting supported |
|
Yup, it's a chicken-egg situation atm, and we will soon be on alpha1 in runtime repo (based on how it was done last year, around this time). I think we can pass --corerun option in local builds that points to built corerun under |
This strongly-typed enums based implementation is not scaling very well; but for now, lets add 10.0 and soon after lets see if we can make it less verbose to ease up future updates a bit: dotnet/runtime#106599 (comment)
cc @adamsitnik, @lewing