.NET Core equivalent of ConfigurationManager.AppSettings for DalFactory

[michaelcsikos]

What is the recommended .NET Core equivalent to this line from the DalFactory?

var dalTypeName = ConfigurationManager.AppSettings["DalManagerType"];

[rockfordlhotka]

As I understand it, the .NET Core config subsystem is pluggable, and people have created various packages to load config settings from different locations (environment variables, files, etc.).

Starting in 4.7.100 (?) CSLA provides its own Csla.Configuration namespace. Issue https://github.com/MarimerLLC/csla/issues/525 is where the work was done.

When running in full .NET the Csla.Configuration namespace just delegates to System.Configuration.

The netstandard version of CSLA has a different implementation of Csla.Configuration that requires that you provide it with a name/value list of config values (from whatever config plugin you chose to use).

Csla.ConfigurationManager.AppSettings = myListOfSettings;
Csla.ConfigurationManager.ConnectionStrings = myListOfConnectionSettings;

You do this as your app is initialized (Program.cs, Startup.cs, etc.) and then those values are available via Csla.Configuration throughout your code.

By using Csla.Configuration your exact same code will run on full .NET or in netstandard/.NET Core.

[ajj7060]

This is perfect! For Xamarin we already created our own lightweight version of appSettings and code to read the file. Sounds like we'll be able to easily incorporate the Csla configuration in.

[tfreitasleal]

@rockfordlhotka Are you planning to include appSettings files for Xamarin and ASP.NET Core projects?

[rockfordlhotka]

In what way? The way those platforms load config values is outside the scope of CSLA I think.

[tfreitasleal]

Good. You figured out it was an hint 😄

In plain .NET, this is outside the scope of CSLA. In .NET Core this is also outside the scope of Csla-Core but maybe it should find a place in another assembly. After all Csla-Windows or Csla-WPF are UI libraries out of CSLA scope.

I don't know details about .NET Core. Is this the only area that needs concrete implementations? Maybe we can group all these utility methods in a Csla-NetCore assembly.

[rockfordlhotka]

I don’t think we need to solve it at all. Other people have build config solutions for these platforms.

CSLA has a dependency on some config values and needs a consistent way to access them, which is what I’ve done with Csla.Configuration.