System.Configuration.ApplicationSettingsBase default/configuration in .NET Core 2 RRS feed

  • Question

  • When using ApplicationSettingsBase in a .NET Core 2 app, where does it read properties from by default?  Is it possible to change the default, and, if so, how?  I'd really like to use it to read from something like "AppSettings.json", but haven't figured out how.  I've been playing around with the "Providers" property a little, but with no success.  I must admit that I'd have thought this would be trivial, but I've been searching for several hours and have yet to find the answer.  Another thing that would be truly wonderful is to have a working example!

    (BTW, I realize this isn't strictly a C# question, but there doesn't appear to be a forum for ".NET Core".  If there's a better place for this question, feel free to instruct me. :-)

    Thanks a lot!

    Saturday, September 28, 2019 2:58 AM

All replies

  • Should be 

    C:\Users\YOUR_USER\AppData\Local\Microsoft\YOUR_APP with trailing characters

    Please remember to mark the replies as answers if they help and unmarked them if they provide no help, this will help others who are looking for solutions to the same or similar problem. Contact via my Twitter (Karen Payne) or Facebook (Karen Payne) via my MSDN profile but will not answer coding question on either.

    NuGet BaseConnectionLibrary for database connections.

    profile for Karen Payne on Stack Exchange

    Saturday, September 28, 2019 3:12 AM
  • Sadly this doesn't help much:

    • The app will eventually be hosted, so that folder is useless and/or needs to be configured
    • This still doesn't provide a file name nor formatting information (e.g. JSON, XML, …?)
    Saturday, September 28, 2019 3:39 AM
  • Hi Pletzky, 

    Thank you for posting here.

    For more information about reading "AppSettings.json", you can refer to the following reference.

    Getting value from appsettings.json in .net core

    Hope it can help you.

    Best Regards,

    Xingyu Zhao

    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, September 30, 2019 10:00 AM
  • ASP.NET Core can be discussed in the Core forum in ASP.NET forums.


    Monday, September 30, 2019 11:21 AM
  • ApplicationSettingsBase is a ConfigurationManager feature. .NET Core does not natively support this. You can add the ConfigurationManager NuGet package but I doubt it supports ApplicationSettingsBase. The correct approach in .NET COre is to simply use JSON like everybody else. Unlike a .NET Framework config file that is strongly defined by section handlers a JSON file in .NET Core is completely dynamic. You define what the structure is and how to read it. 

    To easily read structured data from a .NET Core appsettings file use the Options class as demonstrated here. That link talks about ASP.NET but it works in .NET Core irrelevant of the app. You can select which "Providers" you want at configuration time. For example you can pull settings from the file but override from environment variables or the command line.

    Michael Taylor http://www.michaeltaylorp3.net

    Monday, September 30, 2019 2:12 PM
  • I'm sorry but this doesn't address the question at all.
    Monday, September 30, 2019 7:32 PM
  • Thanks! Since I seem to get getting nowhere, I'll take a look there. :)

    Monday, September 30, 2019 7:33 PM
  • This confuses me. You can find the source for "ApplicationSettingsBase" at https://github.com/dotnet/corefx/blob/master/src/System.Configuration.ConfigurationManager/src/System/Configuration/ApplicationSettingsBase.cs.  It seems to me that very clearly makes it part of .NET Core.  Please explain.
    Monday, September 30, 2019 7:36 PM
  • Excellent question. In fact ApplicationSettingsBase appears to be 2.0 and above. However notice in the docs that the reference is for Winforms which isn't formally part of .NET Core until 3.0. Additionally this is just the base class from which the application settings infrastructure derives. Ultimately you're relying on LocalFileSettingsProvider which is what allows you to store your settings in a .config file. Once again this class was added to 2.0 but it is in the context of Winforms which didn't exist in Core. The settings infrastructure isn't tied to Winforms but that is where it is always used.

    Going to the impl in Core for this class reveals that it relies on the NuGet package containing the migration types for ConfigurationManager that I mentioned earlier. Therefore it is going to rely on the ported CM code which is really just a thunk to help get apps migrated.

    Your goal is to continue using the application settings infrastructure. Personally I would recommend that you switch to the far easier and more flexible IOptions approach. However I assume you have your reason for sticking with the legacy implementation. The easiest approach is to create your own provider derived from SettingsProvider which is exactly what LocalFileSettingsProvider does. You can then pull the data from whereever you want. However this will prevent you from using the (probably) only benefit that the older application settings infrastructure provides which is user config overrides. This is an option and so you might have to dig through the ConfigurationManager code to see if .NET Core even supports this feature.

    If you really want use the local file settings provider then in theory you could derive from it and override its methods again but it relies on a private client settings store instance that you cannot access or modify. So you'd have to go out of your way to get it to point to something other than the traditional config file.

    Michael Taylor http://www.michaeltaylorp3.net

    Monday, September 30, 2019 8:20 PM
  • Can you please elaborate on the "IOptions approach" you mention?  Whereas I was thinking I'd like to maintain compatibility, I've gotten to the point where that doesn't matter as much.  Also, I certainly have no interest in any kind of WinForms connection.

    At this point what I'd like to do is use the "correct" (if there is such a think) way that will the best practice going forward.


    P.S.  This will not be used in the context of ASP.NET.  It is a library we use in a variety of our projects, some of which are .NET Framework, and some are being ported to .NET Core to run as functions in Azure.

    • Edited by Pletzky Monday, September 30, 2019 8:59 PM
    Monday, September 30, 2019 8:52 PM
  • IOptions and how you might use it are documented here. There are also quite a few blog articles about it as well as folks figure out how to best integrate.

    Personally I would recommend that you encapsulate your "settings" into one or more types based upon the functionality. Then have those types injected into your service/classes by the DI container you are using. When setting up the DI container use the IOptions<T> interface to get the underlying "settings" instance and then have it injected directly into your service/classes. I'm not a fan of using IOptions<T> in lower level code because it brings in extra dependencies that I don't think should matter to lower level code.

    //Won't compile
    public class PaymentSettings
       public string AccountKey { get; set; }
       public string ProviderName { get; set; }
    //Class that requires the settings
    public class PaymentService
       //Settings injected by DI container
       public PaymentService ( PaymentSettings settings )
    //App configuration during startup
    // Register IOptions<PaymentSettings> just in case
    // Register the core settings type that low level will use

    Michael Taylor http://www.michaeltaylorp3.net

    Monday, September 30, 2019 9:11 PM