New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't Change ApplicationContext Properties via Configuration in .NET Core #800

Closed
JasonBock opened this Issue Nov 29, 2017 · 3 comments

Comments

Projects
None yet
3 participants
@JasonBock
Contributor

JasonBock commented Nov 29, 2017

I can't figure out a way to change properties like AutoCloneOnUpdate. Typically, in the .NET Framework, I set these values in app.config, but in .NET Core, that doesn't work. It also looks like the property doesn't even try to read anything from configuration in .NET Core, .NET Standard, etc.:

https://github.com/MarimerLLC/csla/blob/master/Source/Csla.Shared/ApplicationContext.cs#L464

There's also no public setter on this property so I can't change it in code.

I'm guessing other properties like IsInRoleProvider have the same issue. Some, like PropertyChangedMode, have a setter so at least that can be configured in code.

My suggestions would be:

I may also just be missing how to set up configuration files in .NET Core to make this all work - if I am, please let me know :). Even in that case, I feel that all of the properties on ApplicationContext should still be configurable in code.

@JohnWigger

This comment has been minimized.

Show comment
Hide comment
@JohnWigger

JohnWigger Nov 30, 2017

I agree with your assessment on both points. I have spent some time working with CSLA for ASP.NET Core 2. In addition to my own project, I am working on taking my lessons learned and putting them into to a version of the existing CslaMvc sample for ASP.NET Core 2. The .NET Core configuration is a very fleshed out API but I focus on what I expect to happen in most scenarios. That is, in a lowest common denominator approach, an application simply has one config and it is of the default json type. One approach to dealing with this is to abstract access to AppSettings in a Config class that conditionally supports .NET Standard or the Full Framework approach. For example:
public static class Configurator
{
#if NETSTANDARD || NETSTANDARD2_0
private static Microsoft.Extensions.Configuration.IConfiguration configuration;
public static void InitForCore(Microsoft.Extensions.Configuration.IConfiguration config)
{
configuration = config;
}
#endif
#if NETSTANDARD || NETSTANDARD2_0
public static string GetAppSettings(string keyName)
{
var jsonKeyName = "AppSettings:" + keyName;
string keyValue = configuration[jsonKeyName];
return keyValue;
}
#endif
#if !NETSTANDARD && !NETSTANDARD2_0
public static string GetAppSettings(string keyName)
{
var keyValue = ConfigurationManager.AppSettings[keyName];
return keyValue;
}
}
#endif

}

JohnWigger commented Nov 30, 2017

I agree with your assessment on both points. I have spent some time working with CSLA for ASP.NET Core 2. In addition to my own project, I am working on taking my lessons learned and putting them into to a version of the existing CslaMvc sample for ASP.NET Core 2. The .NET Core configuration is a very fleshed out API but I focus on what I expect to happen in most scenarios. That is, in a lowest common denominator approach, an application simply has one config and it is of the default json type. One approach to dealing with this is to abstract access to AppSettings in a Config class that conditionally supports .NET Standard or the Full Framework approach. For example:
public static class Configurator
{
#if NETSTANDARD || NETSTANDARD2_0
private static Microsoft.Extensions.Configuration.IConfiguration configuration;
public static void InitForCore(Microsoft.Extensions.Configuration.IConfiguration config)
{
configuration = config;
}
#endif
#if NETSTANDARD || NETSTANDARD2_0
public static string GetAppSettings(string keyName)
{
var jsonKeyName = "AppSettings:" + keyName;
string keyValue = configuration[jsonKeyName];
return keyValue;
}
#endif
#if !NETSTANDARD && !NETSTANDARD2_0
public static string GetAppSettings(string keyName)
{
var keyValue = ConfigurationManager.AppSettings[keyName];
return keyValue;
}
}
#endif

}
@JasonBock

This comment has been minimized.

Show comment
Hide comment
@JasonBock

JasonBock Dec 1, 2017

Contributor

@JohnWigger having an abstraction like this for configuration is a good idea. I also think that all of the properties on ApplicationContext should be settable from code as well. Maybe in the static ctor ApplicationContext reads from configuration and sets all the values, and then after that the properties just get and set from private static fields. A developer can choose to set them after this initial configuration is done.

Ultimately @rockfordlhotka will decide :)

Contributor

JasonBock commented Dec 1, 2017

@JohnWigger having an abstraction like this for configuration is a good idea. I also think that all of the properties on ApplicationContext should be settable from code as well. Maybe in the static ctor ApplicationContext reads from configuration and sets all the values, and then after that the properties just get and set from private static fields. A developer can choose to set them after this initial configuration is done.

Ultimately @rockfordlhotka will decide :)

@rockfordlhotka

This comment has been minimized.

Show comment
Hide comment
@rockfordlhotka

rockfordlhotka Dec 7, 2017

Member

This is actually a duplicate of #525 - or at least they are the same basic issue/problem.

Member

rockfordlhotka commented Dec 7, 2017

This is actually a duplicate of #525 - or at least they are the same basic issue/problem.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment