우리는 보통 이런 식으로 뭔가 보이는 미리 정의 된 ConfigurationBuilder
보고 시작할 수 있습니다 프로젝트 때로는,
var builder = new ConfigurationBuilder()
.SetBasePath(env.ContentRootPath)
.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
.AddJsonFile($"appsettings.{env.EnvironmentName}.json", optional: true)
.AddEnvironmentVariables();
Configuration = builder.Build();
당신은 당신이 처음에 그들을 원하지 않는 경우 AddJosnFile()
을 제거하도록 선택할 수 있습니다 이것을 요구하지 않을 수도있다.
appsettings.json
또는 이와 비슷한 것을 사용하려는 경우 은 추가되는 순서에 유의해야합니다.appsettings.{env}.json
은 이후에 이 추가 된 코드 스 니펫에서 확인할 수 있습니다.
이것은 파일 이름과 일치하는 파일 (예 : appsettings.Production.json
)이있는 경우 이 겹쳐진 구성을 대체 할 것이므로 이해해야하는 중요한 개념입니다. 단어의 사용이 대체
주, 및 이 중복 우선합니다.
프로젝트에 맞는 적절한 계층으로 자신의 계층을 구성하고 구성을 계층화 할 수 있습니다. env.EnviornmentName
중 하나를 사용하는 것이 제한되어 있지 않으므로 필요에 따라 모든 종류의 조건부 논리를 사용하여 디자인 할 수 있습니다.
이 맞춤형 디자인 경로를 계획중인 경우. WebHostBuilder
을 구축하기 전에 원하는대로 구성을 재구성하고 변경할 수 있습니다 (예 :.Build()
메서드가 호출되기 전에). 따라서 프로그래밍 방식으로 프로젝트를 구성하는 방법에있어 매우 독창적 일 수 있습니다.
이 설정을 올바로 사용하면 특정 환경 설정을 외부화해야합니다. 예를 들어 app이 5 개의 서버에 배포되고 다른 연결 문자열을 사용하는 경우이 구성은 appsettings.json 외부에 있어야합니다. 이렇게하면 모든 환경에 대해 앱 빌드가 하나만 있습니다. –
음, 예, 아니오. 여기서 실질적인 "규칙"은 없습니다. 단지 권장 사항입니다. 어쨌든 원하는대로 처리 할 수 있습니다. 예, 일반적으로 환경 별 설정을 외부화하는 것이 좋습니다. .NET Core를 사용하면 빌드가 빌드입니다. 내가 말했듯이 "릴리스"빌드, "스테이징"빌드 등은 없습니다. 환경 자체가 외부화되었습니다. –