我正在为我们团队的第一个.NET Core应用程序制定自动化构建流程。我们的流程是在构建服务器上生成一个工件包(包含所有不同类型的应用程序、数据库迁移脚本等),然后在单独的步骤中将该包部署到我们拥有的各种环境(开发、测试、演示、培训、生产等)。
在完整的.NET Framework应用程序中,我们使用Slow Cheetah对诸如Windows服务和控制台应用程序之类的内容进行配置转换,以便在安装应用程序时它具有正确的配置。
现在,针对.NET Core 2.0应用程序,我看到了两个问题:
1. 发布操作(据我所见,这是获取单个应用程序某种工件包的首选方式)不包含任何appsettings文件(除了ASP.NET Core应用程序)。
2. 如果我手动复制appsettings,那么部署版本如何知道使用哪个appsettings.json?
事实上,我宁愿不部署除目标环境的确切设置以外的任何内容。我认为部署所有环境的设置(或任何不同于目标环境的配置集)都是一场事故等待发生。(编辑:强调我不想在运行时合并不同来源的配置,因为如果出现问题,尝试确定实际应用哪个配置元素将会很混乱。)那么,我应该如何“合并”特定于环境的项与主要的appsettings.json文件?
在完整的.NET Framework应用程序中,我们使用Slow Cheetah对诸如Windows服务和控制台应用程序之类的内容进行配置转换,以便在安装应用程序时它具有正确的配置。
现在,针对.NET Core 2.0应用程序,我看到了两个问题:
1. 发布操作(据我所见,这是获取单个应用程序某种工件包的首选方式)不包含任何appsettings文件(除了ASP.NET Core应用程序)。
2. 如果我手动复制appsettings,那么部署版本如何知道使用哪个appsettings.json?
事实上,我宁愿不部署除目标环境的确切设置以外的任何内容。我认为部署所有环境的设置(或任何不同于目标环境的配置集)都是一场事故等待发生。(编辑:强调我不想在运行时合并不同来源的配置,因为如果出现问题,尝试确定实际应用哪个配置元素将会很混乱。)那么,我应该如何“合并”特定于环境的项与主要的appsettings.json文件?
appsettings.json
只是一个没有特殊意义的文件。如果您想在发布时包含它,您必须将其作为内容包含或复制到输出目录中。.NET Core 的配置可以从多个提供程序读取配置数据,而无需任何默认值或特殊处理。 - Panagiotis Kanavos