Net10

[1eyewonder]

Proposed Changes

• Upgrade from net9.0 -> net10.0 in relevant areas.
• Turning on analyzers in the IDE from the recent switch from paket to nuget
• Some general versioning updates to keep health of the repo up to date

Types of changes

What types of changes does your code introduce to FsToolkit.ErrorHandling?
Put an x in the boxes that apply and remove ones that don't apply

• New feature (non-breaking change which adds functionality)

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• Build and tests pass locally
• I have added tests that prove my fix is effective or that my feature works (if appropriate)
• I have added necessary documentation (if appropriate)

Further comments

If this is a relatively large or complex change, kick off the discussion by explaining why you chose the solution you did and what alternatives you considered, etc...

[1eyewonder]

I don't think this is necessary but temporarily have it here

[1eyewonder]

I thought this felt odd that this was complaining about the incompatible IAsyncDisposable vs IAsyncDisposable | null here. I locked it into IDisposableNull to allow me to continue building and testing other things

[TheAngryByrd]

I appreciate the work but we shouldn't replace net9.0 -> net10.0.

Things we should not do:

• Replace net9.0 outright.
  • The 9 sdk is still under support until next year https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core
• We shouldn't replace tfm net9.0 -> net10.0 in libraries (things under src)
  • This would be a breaking change
  • The reason you choose a TFM in libraries is because it brings a set of APIs you need.
    • In the case of netstandard2.1, it's because it provides IAsyncEnumerable/IAsyncDisposable/ValueTask natively
    • In the case of net6.0, it's because it provides PooliingValueTask support
    • In the case of 9.0, it's because of the Nullable/Nullness support in F# 9.0. (This is technically not a TFM limitation but an FSharp.Core version limitation. I didn't want to start forcing people to use FSharp.Core 9 on older TFMs so I drew a line in the sand at TFM 9.0)
    • The only reason we would want to build against 10.0 is the RuntimeAsync work. However, there's an F# compiler limitation at the moment, so we can't ship with this until that's fixed.
  • In either case, it would be additive and not remove the build target of net9.0

Things we can do:

• Add (not replace) net10.0 to test projects if we want to see how they work against 10 runtime
• Add net10.0 to benchmarks
• Update the various infrastructure like docker/yml/global.json to support being able to run 10.