디버그 및 릴리스 빌드에 대해 다른 구성 파일이있는 .NET 응용 프로그램이 있습니다. 예를 들어 디버그 app.config 파일 은 디버깅이 활성화 된 개발 SQL Server 를 가리키고 릴리스 대상은 실제 SQL Server를 가리 킵니다. 디버그 / 릴리스에서 다른 설정도 있습니다.
현재 두 개의 개별 구성 파일 (debug.app.config 및 release.app.config)을 사용하고 있습니다. 프로젝트에 빌드 빌드 인 경우 빌드 빌드 인 경우 release.app.config를 app.config로 복사하고, 그렇지 않으면 debug.app.config를 app.config로 복사하십시오.
문제는 응용 프로그램이 settings.settings 파일에서 설정을 가져 오는 것처럼 보이므로 Visual Studio에서 settings.settings를 열어야 설정이 변경되었다는 메시지가 표시되어 변경 사항을 수락하고 설정을 저장하고 설정을 저장합니다. 올바른 설정을 사용하도록 다시 빌드하십시오.
비슷한 효과를 얻는 데 더 나은 / 권장 / 선호하는 방법이 있습니까? 또는 이와 똑같이 내가 완전히 잘못 접근했으며 더 나은 접근 방식이 있습니까?
답변
환경에 따라 다를 수있는 구성 은 응용 프로그램 수준이 아닌 시스템 수준 에서 저장해야합니다 . (구성 수준에 대한 자세한 정보)
다음은 일반적으로 컴퓨터 수준에서 저장하는 종류의 구성 요소입니다.
각 환경 (개발자, 통합, 테스트, 스테이지, 라이브)에 c : \ Windows \ Microsoft.NET \ Framework64 \ v2.0.50727 \ CONFIG 디렉토리에 고유 한 설정이있는 경우 환경없이 응용 프로그램 코드 를 승격시킬 수 있습니다. 빌드 후 수정.
그리고 머신 레벨 CONFIG 디렉토리의 내용은 앱의 다른 저장소 또는 다른 폴더 구조에서 버전 제어됩니다. configSource의 지능적인 사용을 통해 .config 파일을보다 소스 제어하기 쉽게 만들 수 있습니다 .
저는 25 개 이상의 회사에서 200 개가 넘는 ASP.NET 응용 프로그램에서 7 년 동안이 일을 해왔습니다. (진정하려고 하지 말고 ,이 방법 이 효과가없는 상황을 본 적이 없다는 것을 알려 드리고자 합니다.)
답변
이것은 Visual Studio (내 경우에는 Visual Studio 2008)의 Settings.settings 표에서 값을 편집하는 동안 Properties.settings 및 App.config : Properties 창에서 GenerateDefaultValueInCode 특성을 감시하는 일부 사람들에게 도움이 될 수 있습니다.
GenerateDefaultValueInCode를 True로 설정하면 (True가 여기에 기본값입니다!) 기본값은 EXE (또는 DLL)로 컴파일되며 일반 텍스트 편집기에서 파일을 열 때 파일에 포함 된 것을 찾을 수 있습니다.
콘솔 응용 프로그램을 작업 중이며 EXE로 기본값을 설정 한 경우 응용 프로그램은 항상 동일한 디렉토리에있는 구성 파일을 무시했습니다! 인터넷 전체에 악몽과 정보가 없습니다.
답변
관련 질문이 있습니다.
구성 파일에는 설정을 무시하는 방법이 있습니다.
<appSettings file="Local.config">
두 개의 파일 (또는 그 이상)을 체크인하는 대신 기본 구성 파일 만 체크인 한 다음 각 대상 머신에서 해당 특정 머신에 대한 재정의가있는 appSettings 섹션과 함께 Local.config를 배치합니다.
구성 섹션을 사용하는 경우 다음과 같습니다.
configSource="Local.config"
물론 다른 컴퓨터에서 모든 Local.config 파일의 백업 복사본을 만들어 실제 솔루션의 일부가 아닌 다른 곳에서 확인하는 것이 좋습니다. 각 개발자는 Local.config 파일에 “무시”를 적용하여 체크인되지 않으므로 다른 사람의 파일을 덮어 씁니다.
(실제로 “Local.config”라고 부르지 않아도됩니다. 이것이 바로 제가 사용하는 것입니다)
답변
내가 읽고있는 내용에서 빌드 프로세스에 Visual Studio를 사용하는 것처럼 들립니다. 대신 MSBuild와 Nant 를 사용하는 것에 대해 생각해 보셨습니까 ?
Nant의 xml 구문은 약간 이상하지만 일단 이해하면 언급 한 작업을 수행하는 것이 매우 간단합니다.
<target name="build">
<property name="config.type" value="Release" />
<msbuild project="${filename}" target="Build" verbose="true" failonerror="true">
<property name="Configuration" value="${config.type}" />
</msbuild>
<if test="${config.type == 'Debug'}">
<copy file=${debug.app.config}" tofile="${app.config}" />
</if>
<if test="${config.type == 'Release'}">
<copy file=${release.app.config}" tofile="${app.config}" />
</if>
</target>
답변
나에게 Visual Studio 2005 웹 배포 프로젝트 의 이점을 누릴 수있는 것 같습니다 .
이를 통해 빌드 구성에 따라 web.config 파일의 섹션을 업데이트 / 수정하도록 지시 할 수 있습니다.
Scott Gu의이 블로그 항목을 보고 빠른 개요 / 샘플을 확인하십시오.
답변
우리는 웹 배포 프로젝트를 사용했지만 이후 NAnt로 마이그레이션했습니다. 다른 설정 파일을 분기하고 복사하는 대신 현재 구성 값을 빌드 스크립트에 직접 포함시키고 xmlpoke 작업을 통해 구성 파일에 삽입합니다.
<xmlpoke
file="${stagingTarget}/web.config"
xpath="/configuration/system.web/compilation/@debug"
value="true"
/>
어느 경우 든 구성 파일은 원하는 개발자 값을 가질 수 있으며 프로덕션 시스템을 손상시키지 않고 개발자 환경에서 제대로 작동합니다. 우리는 개발자가 테스트 할 때 임의로 빌드 스크립트 변수를 변경할 가능성이 적다는 것을 발견했습니다. 따라서 실수로 잘못된 구성은 시도한 다른 기술보다 드물지만 프로세스의 초기에 각 var를 추가해야합니다. dev 값은 기본적으로 prod로 푸시되지 않습니다.
답변
현재 고용주는 machine.config 파일에 개발자 수준 (디버그, 스테이지, 라이브 등)을 먼저 배치하여이 문제를 해결했습니다. 그런 다음 코드를 작성하여 올바른 구성 파일을 사용했습니다. 앱이 배포 된 후 잘못된 연결 문자열 문제가 해결되었습니다.
그들은 최근에 machine.config 값의 값에서 올바른 연결 문자열을 다시 보내는 중앙 웹 서비스를 작성했습니다.
이것이 최선의 해결책입니까? 아마 그렇지는 않지만 그것들을 위해 작동합니다.