Add support for JsonStringEnumMemberName and X509CertificateLoader for .net10

[vpetrusevici]

Summary
Adds compatibility updates for .NET 10+, including conditional attributes, improved type handling, and support for JsonStringEnumMemberName.

Details

• Introduced conditional attributes to ensure compatibility with .NET 10+
• Improved type handling to align with updated framework behavior
• Added support for JsonStringEnumMemberName (related to Problem with [EnumMember] when using JsonStringEnumConverter #645)

Notes
To enable this support and prevent runtime issues, usage of X509CertificateLoader was also introduced.
Some minor changes in tests too.

[vpetrusevici]

@dotnet-policy-service agree company="maib"

[abergs]

I think this is in the right direction, however we don't solve for the COSE serialisation as mentioned in this comment: #645 (comment)

But that doesn't necessarily need to block this PR and could be done in a follow up PR. Not sure if everyone impacted by this problem is also impacted by that problem.

[vpetrusevici]

In our case the only problem was enum string value, so i hope it will fix at least this one

[abergs]

Thanks for working on this, much appreciated. Left some comments and pushed a small cleanup.

[abergs]

@iamcarbon You know your way around jsonmember serialisation better than I do. Any other comments here?

I'm thinking we only drop .net8 in november, so this would be a nice stop gap solution for people already on .net 10.

[vpetrusevici]

Hmm, did i broke something in tests?
Looks like i found where

[iamcarbon]

Consider using an internal Polyfill for JsonStringEnumMemberName to avoid churn (which we can delete when removing the .NET9 target). If we only use this in Models, we could also just delete EnumMember then.

[iamcarbon]

Consider also dedupping the logic for certification loading into a helper.

[iamcarbon]

The unrelated changes in Tpm should also be proposed in a separate PR, so this remains scoped to supporting .NET10

[vpetrusevici]

looks like all comments are resolved

[vpetrusevici]

fixed last tests. i hope

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 78.61%. Comparing base (40b302c) to head (7b9b1b2).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #651      +/-   ##
==========================================
- Coverage   78.62%   78.61%   -0.01%     
==========================================
  Files          98       98              
  Lines        2545     2544       -1     
  Branches      423      425       +2     
==========================================
- Hits         2001     2000       -1     
  Misses        434      434              
  Partials      110      110              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[abergs]

@vpetrusevici Seems MacOS tests are still failing.

[vpetrusevici]

Sorry. I don't see anything in the changes yet that could affect this. It's probably some kind of incompatibility with .NET 10. Could you help me please? @abergs

[abergs]

@vpetrusevici Alright so I've done some analysis and I can see what's going wrong.

In your PR, you change how the apple tests load certificates in Apple.cs. You change from using a constructor to using the helper function. The helper function catches exceptions and doesn't rethrow the original, instead wraps everything in an new Exception, which is why the expected type of the exception is now different.

I think perhaps we should remove the try/catch from the wrapper as it doesn't add much value? I think (I haven't verified) that all callers are internal. We would maybe in some situation expose the CryptographicException to callers, but I don't think that is necessarily bad.

edit:

If we want to be a bit more surgical (but it adds complexity) we catch and rethrow CryptographicException. Not sure if there are any other exceptions that could be thrown though.

[vpetrusevici]

Thanks! I also think that we should see the real exception for such cases
+1 to remove the catch

[vpetrusevici]

Removed try catch. fixed one test for this exception

[abergs]

@vpetrusevici Unfortunately tests still seem to be failing on both mac and linux.

[vpetrusevici]

Ok, i see. I added unnecessary assert, it has different exception on each platform...

[vpetrusevici]

@abergs try again please

[abergs]

All checks look good, let's merge this :) Thank you for all the follow up.

[abergs]

I've released 5.0.0-preview.1 from main with this fix.