SF-3767 Upgrade to .NET 10.0

[pmachapman]

This PR updates the projects, devcontainers, dependencies, and docker containers to .NET 10.

---

---

This change is 

[github-advanced-security]

You are seeing this message because GitHub Code Scanning has recently been set up for this repository, or this pull request contains the workflow file for the Code Scanning tool.

What Enabling Code Scanning Means:

• The 'Security' tab will display more code scanning analysis results (e.g., for the default branch).
• Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results.
• You will be able to see the analysis results for the pull request's branch on this overview once the scans have completed and the checks have passed.

For more information about GitHub Code Scanning, check out the documentation.

[codecov]

Codecov Report

❌ Patch coverage is 14.10256% with 67 lines in your changes missing coverage. Please review.
✅ Project coverage is 81.34%. Comparing base (84fd3ce) to head (734b069).
✅ All tests successful. No failed tests found.

Files with missing lines	Patch %	Lines
src/SIL.XForge.Scripture/Program.cs	0.00%	41 Missing ⚠️
...ataAccess/DataAccessServiceCollectionExtensions.cs	16.66%	15 Missing ⚠️
...e.Scripture/Services/ApiDocumentationExtensions.cs	0.00%	4 Missing ⚠️
...ure/Services/MachineServiceCollectionExtensions.cs	25.00%	3 Missing ⚠️
...IL.XForge.Scripture/Services/ParatextSyncRunner.cs	0.00%	0 Missing and 3 partials ⚠️
src/SIL.XForge.Scripture/Startup.cs	66.66%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #3781      +/-   ##
==========================================
- Coverage   81.39%   81.34%   -0.05%     
==========================================
  Files         623      623              
  Lines       39473    39469       -4     
  Branches     6427     6407      -20     
==========================================
- Hits        32128    32106      -22     
- Misses       6357     6360       +3     
- Partials      988     1003      +15     

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

[marksvc]

@marksvc reviewed 53 files and all commit messages, and made 3 comments.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on pmachapman).

---

src/SIL.XForge.Scripture/Program.cs line 32 at r5 (raw file):

                    Environment.GetEnvironmentVariable("ASPNETCORE_ENVIRONMENT")
                    ?? Environment.GetEnvironmentVariable("DOTNET_ENVIRONMENT")
                    ?? "Production";

I've learned that it can be safer to fall back to the Development environment settings. Then we need to specifically request to use the Production ports, paths, remote URIs, DBs, etc. And if we don't specify, then we more safely write to the less important addresses. What do you think about that here?

---

src/SIL.XForge.Scripture/Program.cs line 44 at r5 (raw file):

                }

                config.AddEnvironmentVariables();

I think at least in Linux one would expect

• the config file settings to be overridden by
• the environment settings, which are overridden by
• the commandline arguments.

Is there a reason the order in the code above appears to be

• commandline, overridden by
• config files, overridden by
• environment variables.

?

I wouldn't want the arguments to dotnet run to be overridden by the config files.

Oh, I see that Devin discussed this some. Yeah, so if we put the config.AddCommandLine after config.AddEnvironmentVariables that may allow commandline arguments to override the others.

Hmm, Devin says it's rare to specify args, but I do on my workstation :). I specify some --node-options. (Though I think recently that has actually been overridden and not working. But ideally it would be working :)

---

src/SIL.XForge.Scripture/Startup.cs line 100 at r5 (raw file):

    private readonly HashSet<string> SpaPostRoutes = [];

    public Startup(IConfiguration configuration, IWebHostEnvironment env)

Devin pointed out that with Startup.cs changes, PackageReference Hangfire.Autofac can be removed from SIL.XForge.csproj.

[pmachapman]

@pmachapman made 3 comments.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on marksvc).

---

src/SIL.XForge.Scripture/Program.cs line 32 at r5 (raw file):

Previously, marksvc wrote…

I've learned that it can be safer to fall back to the Development environment settings. Then we need to specifically request to use the Production ports, paths, remote URIs, DBs, etc. And if we don't specify, then we more safely write to the less important addresses. What do you think about that here?

Done. Sounds good.

---

src/SIL.XForge.Scripture/Program.cs line 44 at r5 (raw file):

Is there a reason the order in the code above appears to be

• commandline, overridden by
• config files, overridden by
• environment variables.

The only reason is to keep the order used by SF currently on master.

I have moved command line arguments to the end. Does this work for you?

---

src/SIL.XForge.Scripture/Startup.cs line 100 at r5 (raw file):

Previously, marksvc wrote…

Devin pointed out that with Startup.cs changes, PackageReference Hangfire.Autofac can be removed from SIL.XForge.csproj.

That was an accidental omission. I have push ed a commit that should use this package again.

[marksvc]

@marksvc reviewed 4 files and all commit messages, made 1 comment, and resolved 3 discussions.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on pmachapman).

---

src/SIL.XForge.Scripture/Program.cs line 44 at r5 (raw file):

Previously, pmachapman (Peter Chapman) wrote…

Is there a reason the order in the code above appears to be

• commandline, overridden by
• config files, overridden by
• environment variables.

The only reason is to keep the order used by SF currently on master.

I have moved command line arguments to the end. Does this work for you?

Great; thank you.

BTW I just checked and see that the server service unit does not specify any commandline arguments.

[devin-ai-integration]

Devin Review found 2 potential issues.

View 6 additional findings in Devin Review.