개발 및 프로덕션 환경에서 다른 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 작업자 프로세스가 다시 시작되지 않습니다.

웹 배포 프로젝트를 살펴 보셨습니까?

http://www.microsoft.com/downloads/details.aspx?FamilyId=0AA30AE8-C73B-4BDD-BB1B-FE697256C459&displaylang=en

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를 작성할 수 있습니다. 내가 할 수있는 것보다 더 나은 정보를 제공하는 여기 의 정보를 살펴보십시오 .

빌드 후 단계로 만들 수도 있습니다. 디버그 및 릴리스 외에 "배치"인 새 구성을 설정 한 후 빌드 후 단계에서 올바른 web.config를 복사하십시오.

우리는 모든 프로젝트에 자동화 된 빌드를 사용하며, 빌드 스크립트는 올바른 위치를 가리 키도록 web.config 파일을 업데이트합니다. 그러나 VS에서 모든 것을하고 있다면 도움이되지 않습니다.

이것은 machine.config 사용의 큰 이점 중 하나입니다. 마지막 직장에서 우리는 개발, 테스트 및 프로덕션 환경을 가졌습니다. 연결 문자열 (적절한 dev / test / prod SQL 머신에)과 같은 것에 machine.config를 사용할 수 있습니다.

실제 프로덕션 시스템에 액세스 할 수없는 경우 (예 : 공유 호스트에서 호스팅 회사를 사용하는 경우)이 방법이 적합하지 않을 수 있습니다.

확장 "Configuration Transform"을 사용하면 "SlowCheetah"와 동일하게 작동합니다.