[asp.net] 개발 및 프로덕션 환경에서 다른 Web.config 사용
개발 또는 프로덕션 환경에서 실행되는 ASP.NET 응용 프로그램에서 다른 데이터베이스 연결 문자열과 SMTP 서버 주소를 사용해야합니다.
응용 프로그램은 WebConfigurationManager.AppSettings 속성을 통해 Web.config 파일에서 설정을 읽습니다 .
Build / Publish 명령을 사용하여 FTP를 통해 응용 프로그램을 프로덕션 서버에 배포 한 다음 원격 Web.config를 올바른 것으로 수동으로 바꿉니다.
어떻게 든 배포 프로세스를 단순화 할 수 있습니까? 감사!
답변
Visual Studio 2010 이상에서는 빌드 구성에 따라 web.config에 변환을 적용 할 수 있습니다.
web.config를 작성할 때 솔루션 탐색기에서 파일을 펼치면 두 개의 파일이 표시됩니다.
- Web.Debug.Config
- Web.Release.Config
여기에는 사용할 수있는 변환 코드가 포함되어 있습니다.
- 연결 문자열 변경
- 디버깅 추적 및 설정 제거
- 오류 페이지 등록
자세한 내용 은 MSDN의 웹 응용 프로그램 프로젝트 배포 를 위한 Web.config 변환 구문 을 참조하십시오.
공식적으로 지원되지는 않지만 동일한 유형의 변환을 웹 이외의 응용 프로그램 app.config파일에 적용 할 수도 있습니다. msbuild에 새 작업을 추가하기 위해 프로젝트 파일을 수정하는 방법에 대해서는 Phil Bolduc 블로그를 참조하십시오 .
이것은 Visual Studio Uservoice에 대한 오래 견딘 요청입니다 .
비주얼 스튜디오 2010 연장 위, ” SlowCheetah는 “어떤 설정 파일 변환을 만드는 돌봐 사용할 수 있습니다. Visual Studio 2017.3부터 SlowCheetah가 IDE에 통합 되었으며 Microsoft에서 코드베이스를 관리하고 있습니다. 이 새 버전은 JSON 변환도 지원합니다.
답변
<appSettings>web.config 의 태그는 자체 키 / 값 세트로 외부 구성을로드하는 파일 속성을 지원합니다. 이것들은 web.config에있는 모든 설정을 무시하거나 추가합니다.
설치시 사이트가 설치되는 환경과 일치하는 파일 속성으로 web.config를 수정하여이를 활용합니다. 설치 프로그램의 스위치를 사용하여이 작업을 수행합니다.
예를 들어;
<appSettings file=".\EnvironmentSpecificConfigurations\dev.config">
<appSettings file=".\EnvironmentSpecificConfigurations\qa.config">
<appSettings file=".\EnvironmentSpecificConfigurations\production.config">노트 :
- 속성으로 지정된 .config를 변경해도 asp.net 작업자 프로세스가 다시 시작되지 않습니다.
답변
웹 배포 프로젝트를 살펴 보셨습니까?
2008 년이 아닌 경우 VS2005 버전도 있습니다.
답변
나도 알고 싶다. 이것은 나를 위해 문제를 격리하는 데 도움이됩니다.
<connectionStrings configSource = "connectionStrings.config"/>
그런 다음 connectionStrings.config 및 “{host} connectionStrings.config”를 유지합니다. 여전히 문제이지만 두 환경에서 다른 섹션에 대해이 작업을 수행하면 동일한 web.config를 배포하고 버전을 지정할 수 있습니다.
(그리고 나는 VS를 사용하지 않는다.)
답변
NAnt Build Script를 사용하여 다른 환경에 배포합니다. 배포 위치에 따라 XPath를 통해 구성 파일을 수정 한 다음 Beyond Compare을 사용하여 자동으로 해당 환경에 배치합니다 .
설정하는 데 1 ~ 2 분이 걸리지 만 한 번만 수행하면됩니다. 그런 다음 커피 한 잔 더 마시면서 배치 파일이 이어집니다. 🙂
여기 내가 찾은 기사가 있습니다.
답변
4 가지 환경 (개발, 테스트, 스테이징 및 프로덕션)이있는 하나의 프로젝트에서 애플리케이션이 배치 된 머신 이름에 따라 적절한 구성을 선택하는 시스템을 개발했습니다.
이것은 다음과 같은 이유로 우리에게 효과적이었습니다.
- 관리자는 개발자를 필요로하지 않고 (필요한) 구성 파일을 싫어하지 않고도 응용 프로그램을 배포 할 수 있습니다.
- 기계 이름은 규칙을 준수했습니다. 정규식을 사용하여 이름을 일치시키고 환경의 여러 시스템에 배포했습니다. 과
- 우리는 연결 문자열에 통합 보안을 사용했습니다. 즉, 디자인 타임에 비밀번호를 공개하지 않고 구성 파일에 계정 이름을 유지할 수 있습니다.
이 경우에는 우리에게 잘 작동했지만 아마도 모든 곳에서 작동하지 않을 것입니다.
답변
엔터프라이즈 라이브러리 구성 편집기가이를 도와줍니다. 기본 구성 파일을 작성한 다음 각 환경에 대한 델타를 작성할 수 있습니다. 그런 다음 기본 구성과 델타를 병합하여 환경 별 web.config를 작성할 수 있습니다. 내가 할 수있는 것보다 더 나은 정보를 제공하는 여기 의 정보를 살펴보십시오 .
