programing

개발 및 프로덕션 환경에서 서로 다른 Web.config 사용

javajsp 2023. 5. 20. 00:12

개발 및 프로덕션 환경에서 서로 다른 Web.config 사용

ASP.NET 응용 프로그램이 실행되는 위치, 개발 환경 또는 실운영 환경에 따라 다른 데이터베이스 연결 문자열과 SMTP 서버 주소를 사용해야 합니다.

응용 프로그램은 WebConfig Manager를 통해 Web.config 파일에서 설정을 읽습니다.AppSettings 속성입니다.

빌드/게시 명령을 사용하여 FTP를 통해 운영 서버에 응용 프로그램을 배포한 다음 원격 Web.config를 올바른 것으로 수동으로 바꿉니다.

구축 프로세스를 어떻게든 간소화할 수 있습니까?감사합니다!

Visual Studio 2010 이상에서는 빌드 구성에 따라 web.config에 변환을 적용할 수 있습니다.

web.config를 생성할 때 솔루션 탐색기에서 파일을 확장할 수 있으며 다음과 같은 두 개의 파일이 표시됩니다.

  • 웹.디버그.구성
  • 웹. 릴리스.구성

여기에는 다음과 같은 용도로 사용할 수 있는 변환 코드가 포함되어 있습니다.

  • 연결 문자열 변경
  • 디버깅 추적 및 설정 제거
  • 오류 페이지 등록

자세한 내용은 MSDN의 웹 응용 프로그램 프로젝트 배포를 위한 Web.config 변환 구문을 참조하십시오.

공식적으로 웹 프로그램이 에도 동일한 수 .app.configmsbuild에 새 작업을 추가하기 위해 프로젝트 파일을 수정하는 방법에 대해서는 Phil Bolduc 블로그를 참조하십시오.

Visual Studio 사용자 음성에 대한 오래된 요청입니다.

Visual Studio 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는 사용하지 않습니다. btw.)

다양한 환경에 배포하기 위해 Nant Build Script를 사용합니다.XPath를 통해 구성 파일이 배포되는 위치에 따라 구성 파일을 수정하도록 한 다음 Beyond Compare를 사용하여 해당 환경에 자동으로 배치합니다.

설정하는 데 1~2분이 걸리지만 한 번만 설정하면 됩니다.그럼 제가 커피를 한 잔 더 가지러 가는 동안 일괄 처리 파일이 처리됩니다.:)

여기 제가 발견한 기사가 있습니다.

4개의 환경(개발, 테스트, 스테이징 및 프로덕션)을 보유한 한 프로젝트에서 애플리케이션이 배포된 시스템 이름을 기반으로 적절한 구성을 선택하는 시스템을 개발했습니다.

이는 다음과 같은 이점이 있습니다.

  • 관리자는 개발자를 참여시키지 않고(요구사항), (싫어하는) 구성 파일을 만지작거릴 필요 없이 애플리케이션을 배포할 수 있었습니다.
  • 규약을 준수하는 컴퓨터 이름입니다.정규식을 사용하여 이름을 일치시키고 환경의 여러 시스템에 배포했습니다.
  • 연결 문자열에 통합 보안을 사용했습니다.즉, 설계 시 암호를 노출하지 않고 구성 파일에 계정 이름을 저장할 수 있습니다.

이 경우에는 우리에게 잘 먹혔지만, 아마 모든 곳에서 작동하지는 않을 것입니다.

Enterprise Library 구성 편집기를 사용하여 이 작업을 수행할 수 있습니다.기본 구성 파일을 생성한 다음 각 환경에 대한 델타를 생성할 수 있습니다.그런 다음 기본 구성과 델타를 병합하여 환경별 web.config를 생성할 수 있습니다.저보다 더 잘 이해할 수 있는 정보를 보세요.

빌드 후 단계로 만들 수도 있습니다.디버그 및 릴리스 외에 "Deploy"라는 새 구성을 설정한 다음 올바른 web.config를 통해 빌드 후 단계를 복사합니다.

우리는 모든 프로젝트에 자동 빌드를 사용하며, 빌드 스크립트는 web.config 파일을 업데이트하여 올바른 위치를 가리킵니다.하지만 VS에서 모든 것을 하고 있다면 도움이 되지 않을 것입니다.

이는 machine.config를 사용할 때 얻을 수 있는 큰 이점 중 하나입니다.전 직장에서는 개발, 테스트 및 생산 환경이 있었습니다.연결 문자열(적절한 dev/test/prod SQL 시스템에)에 machine.config를 사용할 수 있습니다.

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

또한 "Configuration Transform" 확장자를 "SlowCheetah"와 동일하게 사용할 수 있습니다.

언급URL : https://stackoverflow.com/questions/305447/using-different-web-config-in-development-and-production-environment