오늘은 Visual Stuido 2003 부터 제공이 되어왔던 빌드 이벤트(Build Event) 에 대해서 알아보자. 종종 굉장히 편리하게 사용되는 기능이니 한번쯤 알아놓는 것도 도움이 될 것 같다.
여기에서 사용하는 툴은 Visual Studio 2005 Team Suite 기준이다.
빌드 이벤트
빌드 이벤트는 이름에서 알 수 있듯이 빌드(소스코드 컴파일) 작업을 할 때 발생하는 VS.NET IDE 에서 발생하는 이벤트이다.
빌드 이벤트는 다음의 두가지 단계에 거쳐 이벤트를 줄 수 있다.
l 빌드 전 이벤트
l 빌드 후 이벤트
빌드 전 이벤트는 개발자가 빌드를 수행하기 전에 발생하는 이벤트이다.
빌드 후 이벤트는
다시 빌드 후 이벤트는 총 3가지 옵션을 선택할 수 있다.
l 항상 허용
l 빌드가 성공한 경우
l 빌드에서 프로젝트 폴더를 업데이트한 경우
대체적으로 가장 많이 사용하게 될 옵션은 “빌드 후 이벤트”가 될 것 같다. 또한, 빌드 후 이벤트에서 “빌드가 성공한 경우” 가 가장 효율적인 옵션이 될 것이다.
빌드 이벤트는 프로젝트 이름에서 마우스 오른쪽 버튼을 눌러, “속성” 을 클릭하면 “빌트 이벤트” 탭에서 쉽게 찾을 수 있다.
[그림1] 프로젝트 속성의 빌드 이벤트 ( 클릭하면 확대 됩니다 )
빌드 이벤트의 매크로
VS.NET 의 매크로 기능으로 좀더 쉽게 빌드 이벤트 명령줄을 작성할 수 있다.
[그림2] 빌드 이벤트의 매크로
다음은 빌드 이벤트의 매크로로, 다음과 같은 값을 반환한다. (MSDN 참조)
|
매크로 |
설명 |
|
$(ConfigurationName) |
현재 프로젝트 구성의 이름입니다. 예: "Debug|Any CPU" |
|
$(OutDir) |
출력 파일 디렉터리의 경로로서 프로젝트 디렉터리에 대해 상대적인 경로입니다. 이 경로는 출력 디렉터리 속성의 값이 됩니다. 뒤에는 백슬래시('\')가 붙습니다. |
|
$(DevEnvDir) |
드라이브와 경로로 정의되는 Visual Studio 2005의 설치 디렉터리로, 뒤에는 백슬래시(\)가 붙습니다. |
|
$(PlatformName) |
현재 대상 플랫폼의 이름입니다. 예: "AnyCPU". |
|
$(ProjectDir) |
드라이브와 경로로 정의되는 프로젝트의 디렉터리로, 뒤에는 백슬래시(\)가 붙습니다. |
|
$(ProjectPath) |
드라이브, 경로, 기본 이름 및 파일 확장명으로 정의되는 프로젝트의 절대 경로 이름입니다. |
|
$(ProjectName) |
프로젝트의 기본 이름입니다. |
|
$(ProjectFileName) |
기본 이름과 파일 확장명으로 정의되는 프로젝트의 파일 이름입니다. |
|
$(ProjectExt) |
프로젝트의 파일 확장명입니다. 파일 확장명 앞에는 '.'이 붙습니다. |
|
$(SolutionDir) |
드라이브와 경로로 정의되는 솔루션의 디렉터리로, 뒤에는 백슬래시(\)가 붙습니다. |
|
$(SolutionPath) |
드라이브, 경로, 기본 이름 및 파일 확장명으로 정의되는 솔루션의 절대 경로 이름입니다. |
|
$(SolutionName) |
솔루션의 기본 이름입니다. |
|
$(SolutionFileName) |
기본 이름과 파일 확장명으로 정의되는 솔루션의 파일 이름입니다. |
|
$(SolutionExt) |
솔루션의 파일 확장명입니다. 파일 확장명 앞에는 '.'이 붙습니다. |
|
$(TargetDir) |
드라이브와 경로로 정의되는 빌드용 기본 출력 파일의 디렉터리입니다. 뒤에는 백슬래시('\')가 붙습니다. |
|
$(TargetPath) |
드라이브, 경로, 기본 이름 및 파일 확장명으로 정의되는 빌드용 기본 출력 파일의 절대 경로 이름입니다. |
|
$(TargetName) |
빌드용 기본 출력 파일의 기본 이름입니다. |
|
$(TargetFileName) |
기본 이름과 파일 확장명으로 정의되는 빌드용 기본 출력 파일의 파일 이름입니다. |
|
$(TargetExt) |
빌드용 기본 출력 파일의 파일 확장명입니다. 파일 확장명 앞에는 '.'이 붙습니다. |
Visual Studio 2005 에서 빌드 이벤트의 문제
만약 Visual Studio 2003 과 Visual Studio 2005 가 설치되어 있는 PC 라면 한가지 문제가 발생하는 부분이 생긴다. VS.NET 2005 에서 제공하는 SDK 유틸리티들이 VS.NET 2003 버전이 실행된다는 것이다. 이 문제를 해결하기 위해 빌드 이벤트 명령줄에 SDK 유틸리티의 전체경로(Full Path) 를 적어주면 해결된다.
아래의 주소에 이 문제에 대한 해결방법이 자세히 나와있다.
( MSDN Forum 에 가면 상당히 좋은 정보의 질의응답이 많답니다 )
그럼 이제 실무 프로젝트에서도 사용 가능한 예제를 중심으로 가상의 상황을 만들어 빌드 이벤트를 활용해 보도록 하자.
1. 실전 빌드 이벤트 ( GAC 자동 등록하기 )
팀 프로젝트에서 프로젝트의 공통된 부분을 소위 “프레임웍”으로 구축하여 개발하는 곳이 많다. 이런 팀 프로젝트에서 “개발 표준”을 정의하여 개발자 마다 같은 똑같은 폴더에 프로젝트를 만들어서 개발하면 큰 문제가 발생하지 않지만, 그렇지 않을 경우 대부분이 프로젝트의 참조가 깨지는 문제가 발생한다.
이런 문제를 해결하기 위해, 프로젝트의 공통 부분은 GAC 에 등록하여 GAC 을 참조하는 형태로 개발하면 이런 참조가 깨지는 오류를 방지할 수 있다. 이럴 경우, 프로젝트 공통 부분을 개발하면서 매번 소스가 수정된 후, GAC 에 어셈블리를 등록하기 위해 Visual Studio 의 명령 프롬프트의 Gacutil.EXE 를 사용하여 GAC 에 등록하기에 무척 번거롭다.
그럼, 다음과 같이 빌드 이벤트를 작성하여 프로젝트의 소스가 변경되어 컴파일 될 때 자동으로 GAC 에 등록하는 빌드 이벤트를 작성한다.
|
"D:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /u "$(TargetName)"
"D:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /i "$(TargetPath)" |
위 빌드 이벤트의 매크로에서 반드시
“$(TargetPath)”
양쪽 따옴표를 삽입하자. 만약 그렇지 않으면 Documents and Settings 폴더명이 제대로 인식이 되지 않는 현상이 발생하여, 빌드 이벤트가 실패 하는 현상이 발생하게 된다.
출력창을 통해서 빌드 이벤트가 어떻게 실행되었는지 살펴보면 다음과 같다.
|
"D:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /u "BuildTest"
"D:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\gacutil.exe" /i "D:\Documents and Settings\Administrator\My Documents\Visual Studio 2005\Projects\TestSolution 2005\BuildTest\bin\Debug\BuildTest.dll" |
$(TargetName) 과 $(TargetPath) 등의 매크로가 자동으로 폴더명이나 프로젝트 이름으로 리턴되는 것을 알 수 있다.
빌드 결과 다음과 같이 BuildTest 프로젝트의 BuildTest.DLL 이 GAC 에 등록됨을 알 수 있다.
[그림3] GAC 에 BuildTest 어셈블리가 등록됨
마지막으로 GAC 에 등록된 어셈블리를 참조 추가 대화상자에 등록하기 위해 두가지의 레지스트리 중 하나에 등록을 해야 한다.
1. [HKEY_CURRENT_USER\SOFTWARE\Microsoft\.NETFramework\<version>\AssemblyFoldersEx\MyAssemblies]@="<AssemblyLocation>"
2. [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\<version>\AssemblyFoldersEx\MyAssemblies]@="<AssemblyLocation>"
만약 현재 시스템에 로그인한 사용자에게만 보이도록 하고 싶다면 HKEY_CURRENT_USER 에 추가하고, 현재 시스템의 모든 유저에게 보이도록 하고 싶다면 HKEY_LOCAL_MACHINE 에 추가하면 된다.
[그림4] 레지스트리 등록을 통한 참조 대화 상자에 어셈블리 등록 ( 클릭하면 확대 됩니다 )
위와 같이 레지스트리에 등록하게 되면 다음과 같이 참조를 추가하여 사용할 수 있다.
[그림5] 참조 추가 대화상자에 추가된 BuildTest 어셈블리
2. 실전 빌드 이벤트 ( Release 빌드시 자동 배포 )
위의 1번 예제를 눈여겨 본 독자라면 쉽게 이번 예로 쉽게 따라할 수 있을 것이라 생각한다.
우선 우리가 자동배포 하도록 다음고 같은 작업을 진행할 것이다.
1. 배포 폴더가 존재하지 않을 경우 배포 폴더 생성
2. 배포 폴더에 파일이 존재할 경우 무조건 삭제
3. 빌드 된 파일을 배포 폴더로 복사
약간의 DOS 명령 구문을 사용할 줄 안다면 그리 어려운 작업은 아닐 것이다.
그럼 작성된 빌드 이벤트를 보도록 하자.
|
IF NOT EXIST D:\Publish MD D:\Publish
DEL D:\Publish /Q
IF $(ConfigurationName)==Release XCOPY "$(TargetDir)*" "D:\Publish\" |
위에 사용된 매크로 중
$(ConfigurationName)
는 현재 빌드된 프로젝트가 Debug 인지 Release 인지의 값을 반환한다. 그래서 프로젝트의 빌드 모드를 Release 로 변경하고 빌드를 하게 되면 다음과 같이 자동으로 배포 폴더에 빌드 작업 후 생성된 파일이 자동으로 복사된다.
[그림6] 빌드 후 자동으로 Publish 가 생성되고 빌드된 파일이 복사된다.
3. 실전 빌드 이벤트 ( 자동 압축을 통한 소스 백업 )
아마 프로그램을 작성하다 보면 잘못된 구성으로 코딩되어 어제 코딩했던 소스가 필요하다거나, 어제 작성했던 EXE/DLL 이 갑자기 필요할 경우 형상 관리 툴을 사용한다고 하더라도 약간의 복잡한 절차를 거쳐야 할 것이다. 하지만 여기서 빌드 이벤트를 사용하여 자동 압축 또는 빌드된 파일을 자동으로 압축하는 기능도 구현할 수 가 있다.
이미 1,2 번 예제를 잘 이해하고 따라해 본 독자라면 조금만 신경쓰면 3번 실전 예제도 금방 따라할 수 있을 것이다.
여기에서는 ALZIP(알집) 을 사용하여 빌드시 마다 자동으로 소스 코드를 압축하는 빌드 이벤트 명령줄이다.
|
IF NOT EXIST D:\Source_Backup MD D:\Source_Backup
alzip -a "*.*" "D:\Source_Backup\" |
정말 간단하다. ALZIP(알집)의 –a 옵션을 통해 압축을 수행하는 명령줄을 볼 수 있다.
[그림7] 빌드시 마다 자동으로 소스코드를 압축하여 백업해 둔다.
이상 이번 아티클을 통해 간단하지만 많은 내용을 다룬 것 같다. 실제 팀 프로젝트에서 적절하게 사용한다면 많은 귀찮은 작업을 최소화 할 수 있을 것이다.
[출처] 실버라이트 네이버 카페
