How can I extract the DalManager value from appsettings.json in a Core-project?

[pecen]

I'm working with a .Net Core-project that consists of a WebApi project, a Library project, a Dal project with the concrete dal-implementation in yet another project, and I am fairly new in using CSLA for this scenario. I'm used to CSLA for regular .Net Fx-projects (the old way), and I'm now wondering how I can pass the value for the DalManager to the DalFactory. Before we had the ConfigurationManager.AppSettings["YourDalManagerName"] to get the value in the GetManager() method from the app.config-file in the WebApi-project, but now when settings are stored in appsettings.json I realized I cannot use the ConfiguratrionManager anymore, or at least I haven't figured out a way to to do that. How should I go about to accomplish this?

Thx
/Peter

[rockfordlhotka]

.NET Core (and .NET 5) have a whole new configuration subsystem that is fully documented on https://docs.microsoft.com.

The trick with the new dotnetcore subsystem is that it needs to be configured. ASP.NET Core defaults to a set of configuration that includes reading (and overriding, in this order):

• config file
• environment variables
• command line
• values set explicitly in code

I think this is a reasonable tutorial.

CSLA how has a number of configuration options to choose from:

1. Use the Csla.Configuration.ConfigurationManager abstraction and manually load the appsettings collection
2. Use the ConfigureCsla extension to load CSLA settings from the new config subsystem
3. Use the fluent config API built for CSLA to load settings via code

The first option is probably the least ideal, but can act as a bridge from old-style config to the new world.

The second option is probably what you are looking for right now.

The third option is the one I use most, because it is most comparable to modern .NET Core style config that you'll find in ASP.NET Core Startup.cs files (for example).

In short, for option 2, your startup code looks like this:

      var config = new ConfigurationBuilder()
            .AddJsonFile("appsettings.dataportal.test.json")
            .Build()
            .ConfigureCsla();

This may vary a little in ASP.NET Core, because they already provide you an initialized config object, so you can just call ConfigureCsla on that existing object.

The config file looks something like this:

{
  "csla": {
    "propertyChangedMode": "Windows",
    "propertyInfoFactory": "test1,test2",
    "reader": "testReader",
    "serializationFormatter": "testSerializationFormatter",
    "mobileFactoryLoader": "csla.netcore.test.Configuration.TestMobileFactoryLoader, csla.netcore.test, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null",
    "PrincipalCacheSize": 10,
    "defaultTransactionIsolationLevel": "RepeatableRead",
    "mobileWriter": "csla.netcore.test.Configuration.TestCslaWriter, csla.netcore.test, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null",
    "defaultTransactionTimeoutInSeconds": 60,
    "CslaDbProvider": "testDbProvider",
    "dataPortal": {
      "authenticationType": "testAuthentication",
      "autoCloneOnUpdate": true,
      "activator": "csla.netcore.test.Configuration.TestActivator, csla.netcore.test, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null",
      "exceptionInspector": "testExceptionInspector",
      "proxy": "testProxy",
      "portalUrl": "testProxyUrl",
      "proxyFactory": "testProxyFactory",
      "returnObjectOnException": true,
      "objectFactoryLoader": "csla.netcore.test.Configuration.TestObjectFactoryLoader, csla.netcore.test, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null",
      "interceptor": "testInterceptor",
      "authorizationProvider": "testAuthorizationProvider"
    }
  }
}

You don't need to provide all values, only ones where you want to override the default, like normal.

For the latest set of name/value options see the CslaConfigurationOptions and CslaDataPortalConfigurationOptions classes, as they are exactly what is mapped from the file into memory.

[pecen]

Thanks for the information, and yes, option 2 seems like the one to go for in my scenario, but how would you go about to use option 3, which, if I interpret you correctly, you suggest as the best alternative?

[rockfordlhotka]

Option 3 is generally handled in the Startup.cs of an ASP.NET Core project. In the Configure method you call app.UseCsla();, but can do configuration along with that step.

Sort of along this line:

      app.UseCsla(c => c.Configure()
        .DataPortal()
          .DefaultProxy(typeof(HttpProxy), "https://server/api/dataportal")
        );

This allows you to pull the config values from the environment as you choose, like this:

      app.UseCsla(c => c.Configure()
        .DataPortal()
          .DefaultProxy(Configuration.GetValue<string>("dataPortalProxyType"), Configuration.GetValue<string>("serverUrl"))
        );

This relies on the standard .NET Core configuration subsystem to pull those values. That subsystem is rich and powerful and can pull the values from environment variables, the command line, secret stores, and other sources - all based on how you configure the subsystem.