원문 글 링크 : http://blogs.msdn.com/b/vcblog/archive/2010/03/02/visual-studio-2010-c-project-upgrade-guide.aspx
업그레이드 하는 동안 경고들
변환하는 동안 여러분이 겪을 수 있는 공통적인 경고들이 몇 개 있습니다.
1. 링커 출력 디렉토리
여러분이 어플리케이션을 업그레이드할 때 볼 경고중에 하나는 MSB8012: $(TargetPath) and Linker's OutputFile property value does not match: 입니다
- MSB8012: $(TargetExt) ('.dll') does not match the Linker's OutputFile property value 'C:\foo\Debug\MFCActiveX.ocx' ('.ocx') in project configuration 'Debug|Win32'. This may cause your project to build incorrectly. To correct this, please make sure that $(TargetExt) property value matches the value specified in %(Link.OutputFile).
- MSB8012: $(TargetPath) ('C:\foo\Debug\MFCActiveX.dll') does not match the Linker's OutputFile property value 'C:\foo\Debug\MFCActiveX.ocx' ('C:\foo\Debug\MFCActiveX.ocx') in project configuration 'Debug|Win32'. This may cause your project to build incorrectly. To correct this, please make sure that $(TargetPath) property value matches the value specified in %(Link.OutputFile)..
Link.OutputFile 은 등록정보의 링커 -> 일반 -> 출력 파일 에 선언된 값 입니다. 기본값으로 이 값은 $(TargetPath) 와 같은 $(OutDir)$(TargetName)$(TargetExt) 입니다. 그러나 이전버전에서 어플리케이션을 변환할 때 다른 고객들은 다른 방법으로 형식화된 값들을 가지고 있을 수 있기때문에 변환을 위해 $(TargetName) 과 $(TargetExt) 가 가르키는 정확한 값을 밝힐 수 있도록 Link.OutputFile 을 분석할 수 있는 쉬운 방법이 없습니다.
이 문제를 해결하기위해 우리는 변환을 하는동안 Linker.OutputFile 값을 보존하기로 결정했습니다. 변환후에 $(TargetName) 은 기본값으로 $(ProjectName) 으로 됩니다. $(TargetExt) 는 각 어플리케이션 형식에 맞는 기본값을 가질 것 입니다 : 동적 라이브러리 - .dll, 정적 라이브러리 - .lib, 어플리케이션 - .exe. Link.OutputFile 값은 그대로 보존될 것입니다. Link.OutputFile 과 $(TargetPath) 가 같지 않으면 변환 로그에 경고 MSB8012 가 발생할 것입니다. 여러분은 어플리케이션을 빌드할 때 같은 경고를 받게될 것 입니다.
$(OutDir), $(TargetName) 과 $(TargetExt) 는 "일반" 등록정보 페이지에서 "출력 디렉토리", "대상 이름", "대상 확장자" 로 확인할 수 있습니다.
여러분은 경고를 없애기위해 이 값들을 직접 수정할 수 있습니다.
- 만약 여러분의 프로젝트가 가져오기 라이브러리(Import Library) (Linker-> Advanced -> Import Library) 를 생성한다면, 링커 출력 디렉토리가 기본 출력 디렉토리가 아니면 변환후에 마찬가지로 가져오기 라이브러리의 출력 폴더를 변경해야합니다.
- 변환 후에 Debugging.Command 는 $(TargetPath) 로 설정됩니다. 여러분은 F5(Debugging) 또는 Ctrl + F5(Start Without debugging) 를 눌렀을 때 올바르게 실행되도록 변경해야할 수 있습니다.
2. 속성 시트 정렬
여러분의 어플리케이션이 속성 시트를 가지고 있다면 변환 후에 아래와 같은 문제점들이 발견할 수도 있습니다. :
- 사용자 매크로 선언전에 매크로들이 사용되는 구성 'Debug|Win32' 밑에서 발견되는 모든 사용자 매크로들은 의도치 않은 빌드 결과를 가져올 수 있습니다. 이번 배포버전에서 이러한 기능은 지원되지 않습니다. 이 문제는 사용자 매크로를 선언하는 속성 시트 다음에 매크로를 사용하는 속성 시트가 오도록 포함 순서를 변경함으로써 해결할 수 있습니다.
- MSB4211: C:\foo\PropertySheet\foo.props; The property "MyIncludePath" is being set to a value for the first time, but it was already consumed at "C:\foo\PropertySheet\bar.props".
이 경고는 MSBuild 가 속성을 평가하는 방식때문입니다. MSBuild 는 순차적인 순서로 속성을 평가합니다. 상속받은 속성 시트에서 선언된 속성들은 속성들이 부모 속성 시트에서 사용됐다면 빈 값으로 평가됩니다. 그러나, VCBuild 는 속성들이 상속된 속성시트에서 선언되었더라도 부모 속성 시트의 속성들의 사용이 가능해지도록 지연평가를 합니다. 이 문제를 해결하려면, 경고메시지를 따라서 속성 시트의 포함 순서가 속성이 사용되기 이전에 선언되도록 변경합니다.
업그레이드 후 변경된 행동
우리는 기반 빌드 시스템의 변경에도 불구하고 고객들이 VS 2010으로 이전하면서 같은 경험을 갖도록 유지하기 위해 노력했습니다. 다른 한편으로, 몇 가지 빌드 경험 향상시키거나 또는 MSBuild 만의 요구사항에 적응하도록 하기 위해 변경을 가했습니다. 그 결과로, 여러분은 VS2010 으로 이전하면서 몇몇 달라진 동작들을 알아두어야 합니다.
1. 솔루션 의존성 -> 프로젝트간 참조
이전 버전의 Visual Studio 에서 C++ 어플리케이션을 VS2010 으로 변환하면 솔루션 단계에서 선언한 프로젝트 의존성이 프로젝트간의 참조로 변환됩니다. 이러한 변경으로 인해 C++ 프로젝트 의존성을 프로젝트 파일에서 확인할 수 있습니다. 아래 사진은 프로젝트 파일에서 프로젝트간의 참조가 어떻게 나타나는지 보여줍니다 :
프로젝트 파일에 의존성 정보를 갖도록 하는 것은 여러 가지 장점이 있습니다. 먼저, 사용자는 솔루션 없이도 프로젝트를 빌드 할 수 있으며, 독립 프로젝트는 자동으로 빌드 될 수 있습니다. 둘째, . 추가로, 많은 고객들은 다양한 솔루션 파일들은 가지고 있으며, 각 파일들은 다양한 프로젝트들의 하위모임입니다. 이러한 변경은 고객들이 각각의 솔루션 파일들에 대해 프로젝트 의존성 설정을 해야 하는 일에서 해방시켜줍니다. 또 다른 중요한 사실은, 프로젝트간 참조를 통해서 설정되었을 때 빌드 의존성이 좀 더 안정적일 수 있습니다. 특히, 다중 코어를 사용해서 빌드 할 때 그렇습니다. 이러한 일은 이전 버전의 Visual Studio 에서 발생했던 일입니다.
- 여러분이 C++ 어플리케이션에 의존하는 C# 어플리케이션을 가지고 있고 이러한 의존성이 솔루션 의존성을 통해서만 표현된다면, 현재 변환 작업은 솔루션 의존성을 프로젝트간 참조로 변경하지 않습니다. 아마도 특히, MSBuild 를 명령 행 에서 직접 빌드 할 때 잘못된 빌드 순서로 인해 빌드 오류를 경험할 수 있습니다. 이 문제점을 수정하려면, 직접 C# 과 C++ 어플리케이션들에 대해 프로젝트간의 참조를 적절히 설정해야합니다.
- 일반적으로 VS2010 에서 빌드 의존성을 설정할 때 솔루션 의존성 대신 프로젝트간 참조를 사용하세요.
2. 프로젝트간 참조 속성 변경
변환 후에, CopyLocalDependencies 와 UseDependeciesInBuild 속성은 삭제됩니다. "Use in Build" 속성은 속성의 기능을 더욱 드러내도록 "Refernce Assembly Output" 으로 변경됩니다. 두 개의 속성 : "Link Library Dependencies" 와 "Use Library Dependency Inputs" 속성이 참조되는 프로젝트가 프로젝트의 출력을 참조하는 프로젝트에 넘길지 아닐지 제어할 수 있도록 하기위해 참조되는 프로젝트에 추가되었습니다. 아래 사진은 VS2008 과 VS2010 의 프로젝트간 참조 속성들의 비교사진입니다. 
- 설정 "Reference Assembly Output" 를 "false" 로 하면, 프로젝트간 참조의 부분이 된 프로젝트가 참조하는 프로젝트의 CL 에게 프로젝트의 출력을 넘기지 않아도 빌드 의존성이 설정될 수 있도록 합니다. 이 속성은 관리되는 어플리케이션에서 사용됩니다.
- "Link Library Dependencies" 를 "false" 로 하면, 프로젝트간 참조의 부분이 된 프로젝트가 참조하는 프로젝트의 링커 에게 프로젝트의 출력을 넘기지 않아도 빌드 의존성이 설정될 수 있도록 합니다.
3. VC++ 디렉토리 변경
VC++ 디렉토리는 더이상 도구 -> 옵션 페이지를 통해서 지원되지 않습니다. 대신, VS2010 은 전역 검색 경로를 포함하여 전역 설정을 제어하기 위해 사용자 설정 파일(Microsoft.cpp.<Platform>.users.props) 을 사용합니다. 이 파일들은 $(USERPROFILE)\appdata\local\microsoft\msbuild\v4.0 디렉토리에 있습니다. VS2010 으로 이전할 때 VS2005 또는 VS2008 의 VC++ 디렉토리의 사용자 설정들은 이 사용자 파일로 이전됩니다. 이 전역 설정파일등른 모든 변환되는 프로젝트와 새로 생성되는 프로젝트에 사용됩니다.
UI 를 통해서 설정을 변경하는 절차는 아래와 같습니다 :
- View.Property.Manager 를 클릭하여 속성 관리자를 엽니다.
- 프로젝트 항목을 확장해서 Configuration|Platform 선택하면 "Microsoft.cpp.<Platform>.users" 라는 파일을 각 Configuration|Platform 마다 확인할 수 있습니다. 이 파일들이 이전의 Tools/Options/VC++ 디렉토리와 유사하게 전역 설정을 담고 있습니다.
- "Microsoft.cpp<Platform>.users" 를 여러 개 선택하여 오른쪽 버튼을 누르고 등록정보 페이지를 엽니다.
- 등록정보 페이지 창에 왼쪽 페인 에서 "VC++ Directories" (예를 들어) 를 눌러서 "Include Directories" 와 같은 곳에 세미콜론으로 구분하여 새로운 경로를 추가합니다.
- Visual Studio 를 종료하기 전에 설정을 저장합니다.
- Visual Studio 를 새로 시작하면 새로운 설정이 적용됩니다.
알림 : 만약 어떤 프로젝트에 대한 설정만 변경하고 싶다면, 프로젝트에서 오른쪽 버튼을 눌러 속성 페이지를 불러올 수 있습니다. "VC++ Directories" 설정을 변경하면 이 설정들이 프로젝트 파일에 적용됩니다.
4. 사용자 빌드 규칙 변경
VS2008 에서 사용자 빌드 규칙은 .rules 파일에 선언되었습니다. 변환 작업은 .rules 파일들을 3 개의 분리된 파일로 변환합니다 : .targets, .xml, .props 파일입니다. 여러분은 변환 후에 rules 파일들이 있던 디렉토리에서 이 파일들을 찾을 수 있습니다. 새로운 사용자 빌드 규칙을 추가할 수 있는 이용 가능한 UI 는 없습니다.
5. 업데이트 점검 변경
여러분이 F5 를 누르면 아마도 방금 재빌드를 한 직후에도 언제나 점검 대화상자가 나타나는 상황을 겪었을 수도 있습니다. 이 문제를 해결 하기 위해 이 블로그를 참조할 수 있습니다. 어찌되었든, 이러한 문제가 나타난 원인은 프로젝트 파일의 일부분으로 되어있는 몇몇 파일들이 디스크에는 없었기 때문입니다. 왜냐하면, 이들 파일들은 프로젝트 파일들의 일부분이고 업데이트 점검 작동방식은 해당 파일들의 존재여부를 점검할 것 이기 떄문 입니다. 만약 이 파일들이 디스크에 없으면 업데이트 점검은 새 빌드가 필요하다고 가정합니다. 해결방법은 만약 디스크에 파일들이 없으면 프로젝트 파일들에서 이 파일들을 삭제하는 것입니다.
우리가 VS2010 에서 가진 한가지 제한은 관리되는 증분 빌드를 지원하지 않는다는 것입니다. 우리는 미래의 배포버전에서 이 기능을 다시 가져오기위해 연구하고 있습니다.
최근 덧글