在古老的日子
在web.config文件中,设置可以放在appSettings部分中,如下所示:
<appSettings>
<add key="mysetting" value="123"/>
</appSettings>
即使我的web.config文件在我的web项目中,该项目中使用的任何程序集/库都可以使用以下命令访问设置:
ConfigurationManager.AppSettings["mysetting"]
今天(和问题)
我开始使用.NET核心,就像以前一样,我的程序集/库本身不是Web项目,需要访问各种配置设置。
Microsoft的配置文档(https://docs.microsoft.com/en-us/aspnet/core/fundamentals/configuration)以及我可以找到的所有其他示例,配置类由控制器使用,并且不提供有关如何制作的任何指导它适用于另一个不是控制器的程序集/库中的类。
举一个例子,如果我有一个自定义属性,我可以用另一个库(而不是在Web项目中)定义一个自定义属性,并且需要访问配置设置,我该怎么做今天?在这种情况下,我无法将任何内容传递给构造函数。
答案 0 :(得分:1)
我将假设您正在谈论ASPNET核心项目,因为您特别提到了web.config。
这是你需要做的。
IOptions<FooSettingsClass>
通常在应用程序启动时配置,这意味着它在运行时可用,代码看起来像这样。
// Adds services required for using options.
services.AddOptions();
services.Configure<AppSettings>(Configuration.GetSection("FooAppSettings"));
最简单的方法是让框架通过构造函数注入它。通常你会看到它(如你所提到的)被注入控制器,如下所示:
class FooController : Controller {
public FooController(IOptions<FooSettingsClass> settings) { .
//..
}
}
如果你需要访问这个配置就是服务,那么你只需要一个构造函数在另一个程序集中,它接受这些选项。所以:
public class SomeServiceInAnotherAssembly {
public SomeServiceInAnotherAssembly(IOptions<FooSettingsClass> settings) {
//..
}
}
这显然意味着你的FooSettingsClass
类需要在你的ASPNET核心项目之外(以避免循环依赖),但这是一种传播你的配置而不编写任何代码的方法,这就是我所说的见过其他开发者。对我来说,编写代码是一种必然存在错误的箍跳解决方案。
不要忘记您的课程(在此例程中SomeServiceInAnotherAssembly
)需要在启动时注册,即services.AddScoped<SomeServiceInAnotherAssembly>();
这种方法的好处在于它使你的类可以测试。
答案 1 :(得分:-1)
2017年8月8日,Microsoft推出了System.Configuration
for .NET CORE v4.4。 Currently v4.5和v4.6预览。
安装此nuget软件包。将指令添加到代码文件
using System.Configuration;
现在,您可以完成
var val = ConfigurationManager.AppSettings["mysetting"];
尽管有一个网站窍门-您不再将web.config
用于应用程序设置和配置部分。您使用app.config
以及其他类型的项目。但是,如果您在ISS中进行部署,则可能需要同时使用两者。在web.config
中,您提供了与ISS相关的条目。您的应用特定条目进入app.config