Team Foundation Server(이하, TFS)를 이용하면서, "Project Dependency"에 대해서 정리를 하게 되는군요. ^^
우선, TFS Build는 버전 컨트롤 시스템으로부터 소스를 전부 다 새롭게 가져와서 빌드를 하기 때문에 프로젝트 의존성이 맞지 않거나, 그 외에 빌드를 위해 필요한 구성요소가 없다면 정상적인 빌드가 이루어지지 않습니다.
한마디로, 개발자 컴퓨터에서만 빌드되는 것을 허락하지를 않습니다. 따라서, TFS Build를 정상적으로 구성할 수 있었다는 것은 곧, 누구나 TFS 버전 컨트롤에서 솔루션을 가져와서 그 자리에서 VS.NET IDE만 있다면 빌드를 할 수 있다고 볼 수 있습니다.
예를 들어, 신규 개발자가 한 명이 들어왔는데 바로 해당 프로젝트에 투입하고 싶은 경우, 이론적으로는 TFS 버전 제어와 연결만 시켜 주고 나면, 컴파일이 안 된다는 소리는 더 이상 듣지 않을 수 있다는 것입니다.
물론, TFS Build를 정상적으로 하기 위해서는 기존 프로젝트에 대한 내용을 다소 수정해야 합니다.
부분적으로 include, import 부분 등은 소스 수정을 해야 하고, 프로젝트 구조를 다른 식으로 정리해야 할 필요도 있습니다.
일단, 모든 것을 설명하기는 시간이 좀 그렇고, 여기서는 2가지 정도만 해결해 보도록 하겠습니다.
1. 첫 번째 문제 - #pragma comment로 포함시킨 static library 경로.
우선 문제가 되는 것은 프로젝트 간에 참조하게 되는 LIB의 경로 설정이었습니다.
현재 환경이 아래와 같다고 가정할 경우,
Debug 컴파일 경로 : ..\bin\debug
Release 컴파일 경로 : ..\bin\Release
#pragma 구문으로 LIB를 포함하는 경우에는 다음과 같은 식으로 되어야 합니다.
#if defined( _DEBUG )
#pragma comment( lib, "../bin/debug/ClassLib.lib" )
#else
#pragma comment( lib, "../bin/Release/ClassLib.lib" )
#endif
사실, 저 같은 경우 가능한 프로젝트 속성에다가 지정하는 것이 영 탐탁치 않았습니다.
만약, 해당 소스를 다른 프로젝트에 또 사용해야 하는 경우가 발생하면, 다시 일일이 새로운 프로젝트 속성창에서 경로를 지정해 주어야 하기 때문입니다.
그런데, TFS Build를 사용하기 위해서는 그런 편견을 버려야 할 것 같습니다. ^^;
왜냐하면, TFS 서버의 $(OutDir) 경로는 더 이상, 프로젝트 속성창에서 설정했던 그 경로가 아니기 때문입니다.
실제로 Team Build를 하게 되면 다음과 같은 경로에 빌드 결과물이 쌓이게 됩니다.
[TeamBuild 기준 경로]\Binaries\win32\release
이런 상황에서 #pragma comment로 지정했던 "../bin/debug/ClassLib.lib" 경로가 맞을리 없습니다. 따라서, ^^; 너무나 당연하다는 듯이 컴파일 오류를 내고 맙니다.
문제를 해결하기 위해서는, 위의 예에서 들었던 "Project Dependency" 방법을 사용해야만 합니다.
즉, 해당 Lib 파일을 #pragma로 직접 포함시켜서는 안되고, "Solution Explorer"에서 현재 프로젝트를 오른쪽 마우스 버튼으로 선택하고 나오는 메뉴에서 "Project Dependencies..."를 선택합니다.
이어서 나오는 대화창에서 "ClassLib" 프로젝트를 체크해 주면 명시적으로 프로젝트 의존성이 생기고, 빌드 순서를 "ClassLib" 프로젝트를 먼저 하게 됩니다.
한 가지 편리한 점이 있다면, 이렇게 프로젝트 의존성을 지정하게 되면 굳이 다른 프로젝트 설정이나 #pragma를 사용하지 않아도 됩니다. 왜냐하면, Link 시에 자동으로 의존성이 지정된 DLL에 대해서 다음과 같이 포함시켜 주기 때문입니다.
- Linker Command Line -
/OUT:"../bin/releaseInstance\DxFileViewer.dll" /INCREMENTAL:NO
/* 중간 생략 */
/MACHINE:X86 /ERRORREPORT:PROMPT ..\bin\releaseInstance\BaseClassLib.lib
자, 그럼 이걸로 LIB 포함하는 것에 대한 오류는 해결했습니다.
2. 두 번째 문제
TLB 또는 DLL을 직접 import한 경우에도 1번 문제와 같은 상황으로 인해 오류가 발생합니다. 예를 들어, 이것 역시 다음과 같이 소스 코드에 지정을 했을 텐데요.
#if defined( _DEBUG )
#import comment( lib, "../bin/debug/ClassLib.tlb 또는 확장자 dll" )
#else
#import comment( lib, "../bin/Release/ClassLib.tlb 또는 확장자 dll" )
#endif
아쉽게도, 이 문제는 "프로젝트 의존성"을 지정한다고 해서 해결되지는 않습니다. 왜냐하면, VS.NET이 대상 프로젝트가 Static Library가 아님을 알고, 이번에는 Linker 옵션에 LIB 경로를 포함시키지 않기 때문입니다.
뭐... 당연하겠지요. COM 개체이기 때문에 LIB 파일을 링크 시켜준다고 해서 별 도움이 되지는 않으니까요.
자,,, 그런데 #include도 아니고, #import입니다. 도대체 어떤 것을 수정해줘야 ^^ VS.NET IDE가 정상적으로 해당 파일을 찾아서 컴파일을 시켜 줄 수 있을까요?
^^ 저만 따라오십시오.
우선, 해당 구문을 다음과 같이 수정합니다.
#import comment( lib, "ClassLib.dll" )
이미 말씀드린 것처럼, TFS Build에서는 사용자가 지정한 Output 경로는 조금도 도움이 되지 않습니다. 따라서 그냥 기본 경로를 지정해 주고, 위와 같이 지정된 DLL 파일을 찾을 수 있도록 경로를 알려주는 것이 중요합니다.
경로 선정은, 다름 아닌 ^^; include 설정과 동일한 경로 검색이 이뤄집니다.
따라서, 프로젝트 속성창에서 아래 화면과 같이 "Additional Include Directories"에 "$(OutDir)"을 설정해 주어야 합니다. (보통 OutDir이 추가 Include 폴더에 포함되어 있지 않지요.)
그런 다음 빌드를 하면 정상적으로 컴파일이 되는 것을 확인할 수 있습니다. 물론, TFS Build에서도 동일하게 동작합니다.
