I have a legacy ESRI ArcGIS Server Object (SOE) extension written against ESRI's old 32-bit ArcObjects framework (.NET Framework 4.7.1). My group is looking to upgrade this to ESRI's new ArcGIS Enterprise 11.1 framework/SDK (.NET Core 6.0). The new SDK was intentionally designed by ESRI to map very easily 1:1 to the old ArcObjects version, so from a raw coding standpoint it looks pretty straightforward. The SOE is designed to be paired to an existing ESRI REST map service and exposes a number of endpoints that can be queried directly.
In the legacy tools, I made liberal use of the .NET Framework Settings.Configuration "Settings" files to codify a lot of the string-handling that's necessary within the tool. In an ideal world I understand it would be better to inject the whole mess via dependency-injection. However, it's all pretty static stuff. Also, it is inherited code and we have limited resources, so I had to be judicious about how and against what content to apply our integration testing. It was all I could do to wrangle all the hard-coded strings in the original code into these settings files to begin with.
I'm interested in suggestions for what the best approach would be to building in support for configuration to the new .NET Core-based solution. Unfortunately, in an SOE I don't have easy access to the Microsoft.AspNetCore library or the WebApplication object so I've been unsuccessful in creating and accessing configuration objects so far. I'm open to setting the configuration up in a separate project and injecting it in in the interest of supporting better testing practice. However, in that context the problem remains for where to start, whether a .NET Core IConfiguration approach could be adapted somehow (help!), or whether some other tactic would be better. I'd like a solution which I can most easily adapt and maintain the abstraction advantages of the old strongly-typed .NET Framework settings files. And if it turns out the existing .NET Core Configuration API / Options approach is recommended, I'd be very grateful for some indication of how I might best adapt those to my project (since it's unclear to me at the moment).
I've done some research into the .NET Core Configuration and Options patterns for .NET Core web applications. However, these seem to take advantage of the availability of the IConfiguration / Microsoft.AspNetCore.Builder middleware and carry assumptions about how the configuration would be initialized as part of web application startup procedure (which doesn't exist for an SOE). References to those libraries also aren't immediately available in the boilerplate project when initiating an ArcGIS Enterprise 11.1 ESRI SOE project within Visual Studio. So the examples provided don't give me a full understanding of whether that approach is appropriate for my project.