개발 및 프로덕션 환경에서 다른 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에 새 작업을 추가하기 위해 프로젝트 파일을 수정하는 방법에 대해서는
참조하십시오 .이것은
대한 오래 견딘 요청입니다 .
위, "
"어떤 설정 파일 변환을 만드는 돌봐 사용할 수 있습니다. Visual Studio 2017.3부터
되었으며 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를 통해 구성 파일을 수정 한 다음
사용하여 자동으로 해당 환경에 배치합니다 .설정하는 데 1 ~ 2 분이 걸리지 만 한 번만 수행하면됩니다. 그런 다음 커피 한 잔 더 마시면서 배치 파일이 이어집니다. :)
내가 찾은 기사가 있습니다.
4 가지 환경 (개발, 테스트, 스테이징 및 프로덕션)이있는 하나의 프로젝트에서 애플리케이션이 배치 된 머신 이름에 따라 적절한 구성을 선택하는 시스템을 개발했습니다.이것은 다음과 같은 이유로 우리에게 효과적이었습니다.
- 관리자는 개발자를 필요로하지 않고 (필요한) 구성 파일을 싫어하지 않고도 응용 프로그램을 배포 할 수 있습니다.
- 기계 이름은 규칙을 준수했습니다. 정규식을 사용하여 이름을 일치시키고 환경의 여러 시스템에 배포했습니다. 과
- 우리는 연결 문자열에 통합 보안을 사용했습니다. 즉, 디자인 타임에 비밀번호를 공개하지 않고 구성 파일에 계정 이름을 유지할 수 있습니다.
이 경우에는 우리에게 잘 작동했지만 아마도 모든 곳에서 작동하지 않을 것입니다.
엔터프라이즈 라이브러리 구성 편집기가이를 도와줍니다. 기본 구성 파일을 작성한 다음 각 환경에 대한 델타를 작성할 수 있습니다. 그런 다음 기본 구성과 델타를 병합하여 환경 별 web.config를 만들 수 있습니다. 내가 할 수있는 것보다 더 나은 정보를 제공하는
의 정보를 살펴보십시오 .
빌드 후 단계로 만들 수도 있습니다. 디버그 및 릴리스 외에 "배치"인 새 구성을 설정 한 후 빌드 후 단계에서 올바른 web.config를 복사하십시오.우리는 모든 프로젝트에 자동화 된 빌드를 사용하며, 빌드 스크립트는 올바른 위치를 가리 키도록 web.config 파일을 업데이트합니다. 그러나 VS에서 모든 것을하고 있다면 도움이되지 않습니다.
이것은 machine.config 사용의 큰 장점 중 하나입니다. 마지막 직장에서 우리는 개발, 테스트 및 프로덕션 환경을 가졌습니다. 연결 문자열 (적절한 dev / test / prod SQL 컴퓨터에)과 같은 것에 machine.config를 사용할 수 있습니다.실제 프로덕션 시스템에 액세스 할 수없는 경우 (예 : 공유 호스트에서 호스팅 회사를 사용하는 경우)이 방법이 적합하지 않을 수 있습니다.
'programing' 카테고리의 다른 글
| SQL Server 동적 PIVOT 쿼리? (0) | 2020.05.14 |
|---|---|
| 이클립스 안드로이드와 gitignore (0) | 2020.05.14 |
| .NET에서 '클로저'란 무엇입니까? (0) | 2020.05.14 |
| C ++, 생성자 뒤의 콜론은 무엇을 의미합니까? (0) | 2020.05.14 |
| Android의 Java 7 언어 기능 (0) | 2020.05.14 |