기본 제공되는 Visual Studio 빌드를 이용해서도 큰 무리는 없지만 파일 배포나 경로 변경 또는 상황적인 파일의 필터링 등을 활용하기 위해서는 MSBUILD 또는 NAnt 와 같은 3rd 빌드 툴을 이용해야 한다. 관련해서 이런 저런 정보를 검색하던 중에 마이크로소프트웨어(마소)에 연재된 MSBUILD 관련 글을 읽어 보고 나름대로 정리를 해 놓도록 한다.
MSBUILD 개념
우선 반드시 알고 넘어가야 하는 것은 *.csproj 파일의 정체다. 대 부분은 프로젝트 파일이라고 알고 있지만 정확하게는 MSBUILD 파일이다. 여기에 구성된 파일과 빌드에 필요한 정보를 가지고 있는 XML 파일인 것이다.
기본적인 구성
빌드 스크립트는 아래의 구성과 같이 기본적인 구성이 존재한다. 이 구성을 기준으로 필요한 부분들을 추가하고 조정해 나가면 되는 것이다. 아래의 파일은 build.xml 이라고 생성해 놓는다)
위의 코드는 말 그대로 뼈대만 존재하는 것이다. 어떤 스크립트를 구성하든 위의 뼈대를 기준으로 추가하면 된다. 위의 스크립트에는 “Target” 이 3 개 존재한다. 각각 “Clean”, “Build”, “Rebuild” 로 지정되어 있다. 말 그대로 처리하는 것을 의미하는 것으로 다음과 같은 처리가 진행된다.
- Clean - 기존 대상을 정리하는 것으로 보통은 bin, obj 폴더를 지우는 역할을 담당한다.
- Build - 대상 소스 코드를 빌드하는 역할을 담당한다.
- Rebuild - 다시 빌드로 "Clean", "Build"를 순차적으로 처리한다.
"Target" 이라는 것은 MSDN에서는 작업이라고 지칭한다. MSBuild 구성 요소는 "Item", "Property", "Target" 으로 구성되며 "Item" 과 "Property" 가 어떤 값을 나타낸다면 "Target"은 행동을 나타낸다. MSDN을 보면 이런 작업에는 "Copy", "Delete", "Exec", "ReadLinesFromFile", "VCBuild" 등이 제공되고 있다. 대략 30여개의 작업들이 존재하고 프로그래밍을 통해서 이들을 확장할 수 있다. 대표적인 사례로 "MSBuildCommunityTask" 라는 오픈소스도 이런 확장 기능을 사용한 것이다.
Execute MSBuild script
빌드 스크립트가 만들어졌다면 실행을 해 봐야 하는데 MSBuild.exe 는 "C:\Windows\Microsoft.NET\Framework\v2.0.50727\msbuild.exe" 와 같이 특정 프레임워크 버전 경로 밑에 존재한다. 따라서 실행을 위해서는 환경에 따라서 아래의 코드와 같이 batch 파일을 만들어서 운영하는 것이 정신 건강에 좋다. (아래의 배치 파일은 msbuild_vs2013_x86.bat 이라고 가정한다)
그리고 %VS80COMNTOOLS% 는 Visual Studio 의 공통 도구 경로를 지정하는데 Visual Studio 의 버전별로 다르다. Visual Studio 2008인 경우는 VS90 이고 Visual Studio 2013 은 VS120 이다.
그리고 MSBuild의 경로는 .NET Framework 버전에 따라서 변경이 되어야 한다. 여기서 중요한 부분이 가장 마지막에 있는 "%*" 기호로 이 기호의 의미는 배치 파일에 넘긴 모든 인자를 나타내는 것이다. 아래의 코드처럼 배치 파일을 실행했다고 하면 모든 인자가 전달되어 처리되는 것이다.
첫 번째로 "Clean"을 실행해 보도록 하자. 그럼 아래의 그림과 같이 수행된 것을 확인할 수 있다.
예상했던 것과 같이 지정한 Clean 작업만 수행된 것을 확인할 수 있다. "Build" 는 현재는 "Clean" 과 다른 것이 없으므로 "Rebuild" 를 실행해 보도록 하자.
위의 그림에서 확인할 수 있는 것과 같이 "DependsOnTargets" 에 명시된 "Clean", "Build" 가 순차적으로 실행된 것을 볼 수 있다.
그럼 Target 을 명시하지 않으면 어떻게 될까? 실행해 보면 알지만 첫 번째 "Target" 인 Clean 이 수행된다. 하지만 위의 Build.xml 에서 Project 요소에 "DefaultTargets" 를 지정했기 때문에 샘플에서는 Build 가 수행된다. 이름에서도 알 수 있는 것과 같이 "DefaultTarget" 이 아닌 복수형 "s" 가 붙었기 때문에 Rebuild 와 같이 여러 개의 Target 들을 지정할 수 있다.
여기서 빌드 스크립트 파일 (build.xml) 을 주지 않으면 어떻게 될까? 결론부터 이야기를 하면 해당 실행 경로 상에 존재하는 솔루션 파일을 찾는다. 그럼 솔루션 파일도 없으면 어떻게 될까? 기본 설정된 이름인 "msbuild.xml" 파일을 찾는다. 그 파일 마저도 없다면 당연히 오류가 난다.
@echo off
SETLOCAL
call "%VS80COMNTOOLS%\..\..\VC\vcvarsall.bat" x86
"C:\WINDOWS\Microsoft.NET\Framework64\v3.5\msbuild.exe" %*
ENDLOCAL
SET ERR_LEVEL=%errorlevel%
exit /b %ERR_LEVEL%
위의 배치 화일을 검토해 보면 SETLOCAL 과 ENDLOCAL 이 있는 것을 볼 수 있다. 담당하는 역할은 vcvarsall.bat 이 환경 설정의 PATH 값을 변경하기 때문에 SETLOCAL 로 임시 저장을 했다가 처리가 완료된 후에 ENDLOCAL 로 다시 복원시키는 역할이다.그리고 %VS80COMNTOOLS% 는 Visual Studio 의 공통 도구 경로를 지정하는데 Visual Studio 의 버전별로 다르다. Visual Studio 2008인 경우는 VS90 이고 Visual Studio 2013 은 VS120 이다.
그리고 MSBuild의 경로는 .NET Framework 버전에 따라서 변경이 되어야 한다. 여기서 중요한 부분이 가장 마지막에 있는 "%*" 기호로 이 기호의 의미는 배치 파일에 넘긴 모든 인자를 나타내는 것이다. 아래의 코드처럼 배치 파일을 실행했다고 하면 모든 인자가 전달되어 처리되는 것이다.
[ 배치 파일 실행 구문 ]
Msbuild_win32.bat msbuild.xml /t:build
[ 전달된 MSBuild 실행 구문 ]
“C:\WINDOWS\Microsoft.NET\Framework\v3.5\msbuild.exe” msbuild.xml /t:build
그리고 MSBuild의 경로는 .NET Framework 버전에 따라서 변경이 되어야 한다. 여기서 중요한 부분이 가장 마지막에 있는 “%*” 기호로 이 기호의 의미는 배치 파일에 넘긴 모든 인자를 나타내는 것이다. 아래의 코드처럼 배치 파일을 실행했다고 하면 모든 인자가 전달되어 처리되는 것이다.첫 번째로 "Clean"을 실행해 보도록 하자. 그럼 아래의 그림과 같이 수행된 것을 확인할 수 있다.
예상했던 것과 같이 지정한 Clean 작업만 수행된 것을 확인할 수 있다. "Build" 는 현재는 "Clean" 과 다른 것이 없으므로 "Rebuild" 를 실행해 보도록 하자.
위의 그림에서 확인할 수 있는 것과 같이 "DependsOnTargets" 에 명시된 "Clean", "Build" 가 순차적으로 실행된 것을 볼 수 있다.
그럼 Target 을 명시하지 않으면 어떻게 될까? 실행해 보면 알지만 첫 번째 "Target" 인 Clean 이 수행된다. 하지만 위의 Build.xml 에서 Project 요소에 "DefaultTargets" 를 지정했기 때문에 샘플에서는 Build 가 수행된다. 이름에서도 알 수 있는 것과 같이 "DefaultTarget" 이 아닌 복수형 "s" 가 붙었기 때문에 Rebuild 와 같이 여러 개의 Target 들을 지정할 수 있다.
여기서 빌드 스크립트 파일 (build.xml) 을 주지 않으면 어떻게 될까? 결론부터 이야기를 하면 해당 실행 경로 상에 존재하는 솔루션 파일을 찾는다. 그럼 솔루션 파일도 없으면 어떻게 될까? 기본 설정된 이름인 "msbuild.xml" 파일을 찾는다. 그 파일 마저도 없다면 당연히 오류가 난다.
Solution Build
제대로된 빌드 설정을 확인해 보기 위해서 간단하게 콘솔 어플리케이션을 하나 만들고 생성된 프로젝트 파일 (*.csproj) 을 에디터에 열어서 확인해 보면 아래와 같은 설정들을 확인할 수 있다.
위의 내용을 대략적으로 확인해 보면 우선 다음과 같은 항목들이 추가된 것을 볼 수 있다.
위에서 간단한 콘솔 프로젝트를 생성하라고 했기 때문에 (여기서는 C:\Temp\ConsoleAppliction1.csproj) 생성했다고 가정하고 빌드 스크립트를 설정해 보도록 한다.
PropertyGroup 을 통해서 MSBuild 가 동작하는데 필요한 Property 들을 구성해 준 것을 확인할 수 있다. Property 값들은 빌드 스크립트에 설정을 해서 처리를 해도 되지만 배치 파일에 대해서 인자 값으로 넘길 수도 있다.
Debug Property 값이 Debug 에서 Release 로 변경된다.
이제 실제 구성한 빌드 스크립트가 제대로 동작하는지 아래와 같이 수행하여 결과를 확인해 보도록 한다. 만일 오류가 발생한다면 뭔가 제대로 설정이 되지 않아서일 것이다.
위의 내용을 대략적으로 확인해 보면 우선 다음과 같은 항목들이 추가된 것을 볼 수 있다.
- Import - 또 다른 설정이 존재하는 빌드 스크립트 파일을 가져오는데 사용한다. 주로 공통 Property 값들을 모아 놓은 것이나 작업(Target) 들을 모아 놓은 것들이다.
- PropertyGroup - MSBuild 에 Property를 통해서 값을 전달할 수 있으며, 이런 Property 들을 묶어주는 역할을 담당하고 조건에 따라서 적용할 수 있도록 하는데 사용한다. 쉽게 변수라고 생각하면 된다.
- ItemGroup - MSBuild 가 처리해야 하는 항목들을 전달하고, 항목들을 묶어주는 역할을 담당한다. 쉽게 항목 배열이라고 생각하면 된다.
위에서 간단한 콘솔 프로젝트를 생성하라고 했기 때문에 (여기서는 C:\Temp\ConsoleAppliction1.csproj) 생성했다고 가정하고 빌드 스크립트를 설정해 보도록 한다.
Debug
Any CPU
$(Configuration)|$(Platform)
C:\Temp\ConsoleApplication1.sln ">
$(Configuration)
$(Platform)
PropertyGroup 을 통해서 MSBuild 가 동작하는데 필요한 Property 들을 구성해 준 것을 확인할 수 있다. Property 값들은 빌드 스크립트에 설정을 해서 처리를 해도 되지만 배치 파일에 대해서 인자 값으로 넘길 수도 있다.
msbuild_vs2013_x86 build.xml /p:Configuration=Release
위와 같이 인자 처리를 하게되면 위에서 구성한 Build.xml 스크립트에 존재하는 이제 실제 구성한 빌드 스크립트가 제대로 동작하는지 아래와 같이 수행하여 결과를 확인해 보도록 한다. 만일 오류가 발생한다면 뭔가 제대로 설정이 되지 않아서일 것이다.
msbuild_vs2013_x86 build.xml /t:Build
이제 실제 구성한 빌드 스크립트가 제대로 동작하는지 아래와 같이 수행하여 결과를 확인해 보도록 한다. 만일 오류가 발생한다면 뭔가 제대로 설정이 되지 않아서일 것이다. 정상적으로 잘 설정이 되었다면 아래의 그림과 같이 빌드가 처리되어야 한다.
이제 실제 구성한 빌드 스크립트가 제대로 동작하는지 아래와 같이 수행하여 결과를 확인해 보도록 한다. 만일 오류가 발생한다면 뭔가 제대로 설정이 되지 않아서일 것이다.
Solution Clean
실제 솔루션을 연결하였으므로 Clean 을 했을 때 정말 Clean 이 동작하는지 확인해 보도록 하자. 당연하겠지만 프로젝트나 솔루션 파일에는 Clean 이 이미 구성되어 있다. 따라서 실행을 하면 당연히 되어야 한다. 우선 아래와 같이 build.xml 의 Clean Target을 구성하도록 한다.
설정의 다시 한번 확인을 해 보면 다음과 같은 의미들이 존재한다.
- MSBuild - Clean Target 처리에서 대상 Project에 대한 MSBuild 처리를 호출하도록 정보를 설정한다.
- @(...) - 빌드 스크립트 내부에 정의된 Property 나 ItemGroup 을 참조할 때 사용한다.
- %(...) - 빌드 스크립트 내부에 정의된 Property에 의해서 참조된 내부 Property의 값을 참조할 때 사용한다.
이제 실행을 해 보자.
Target 도 정상적으로 Clean 으로 되었고, 연결한 솔루션에 대해서 파일들이 삭제되는 것을 위의 그림과 같이 확인할 수 있다. 그러나 실제 해당 경로에 가보면 완전히 삭제되지 않고 남아있는 파일들이 존재한다. *.vshost.* 파일은 Visual Studio 가 디버깅할 때 자동으로 만들 파일이라서 제외가 된다. 그렇다면 완전하게 Clean 하려면 결국 bin 폴더를 통째로 삭제하는 것이다. 이를 위해서는 아래와 같이 설정을 변경해 주어야 한다.
- MSBuild - Clean Target 처리에서 대상 Project에 대한 MSBuild 처리를 호출하도록 정보를 설정한다.
- @(...) - 빌드 스크립트 내부에 정의된 Property 나 ItemGroup 을 참조할 때 사용한다.
- %(...) - 빌드 스크립트 내부에 정의된 Property에 의해서 참조된 내부 Property의 값을 참조할 때 사용한다.
이제 실행을 해 보자.
위의 그림과 같이 삭제할 대상을 ItemGroup 으로 설정해 놓고, Clean Target에서 "RemoveDir" 을 이용해서 디렉터리를 삭제하도록 지정한 것을 확인할 수 있다.
다시 실행을 해 보면 제대로 삭제된 것을 확인할 수 있다. 다만 이런 경우에 솔루션 내에 프로젝트가 많고, Configuration 설정에 따라서 지워야 한다면 "BinDirs" 와 "ObjDirs" 를 지정하고, 변경될 때마다 관리를 해 주어야 한다는 것이다. 그러나 이를 위해서 Wildcard 의 사용이 Item 에 대해서 적용 가능하므로 아래와 같이 변경해 주면 된다.
위의 그림과 같이 디렉터리인 경우는 "*" 를 이용해서 Wildcard 처리를 해 주면 된다. 그러나 절대 경로인 경우는 지정을 할 수 없으므로 실행되고 있는 경로를 기준으로 항상 상대 경로 처리로 진행을 해 주어야 한다.
How to debugging
아직은 스크립트 상태이므로 간략하게 디버깅이라기 보다는 디버깅을 위한 옵션이 어떻게 존재하는지를 알아보도록 하자.
msbuild_vs2013_x86 /?
위와 같이 실행하면 여러 가지 옵션 정보들이 보인다. 그 옵션들 중에서 디버깅 용도로 사용할 수 있는 옵션은 /verbosity: 로 약식으로는 /v: 로 지정하면 된다. 같이 설정하게 되는 Level 은 다음과 같은 의미를 가진다.
- q[uiet] - 로거에 빌드 요약만 처리한다.
- m[inimal] - 로거에 빌드 요약과 오류, 경고 등과 같은 중요 메시지만 처리한다.
- n[ormal] - 로거에 빌드 요약과 오류, 경고 등과 같은 중요 메시지 및 이벤트 상태 정보를 처리한다.
- d[etail] - 로거에 빌드 요약과 오류, 경고 등과 같은 중요 및 일반 메시지와 이벤트 상태 정보를 처리한다.
- diag[nostic] - 로거에 빌드 용약과 모든 메시지, 이벤트 등을 전부 처리한다.
디버깅을 위한 경우라면 당연히 /v:diag 를 사용하면 된다.
위의 그림과 같이 디렉터리인 경우는 "*" 를 이용해서 Wildcard 처리를 해 주면 된다. 그러나 절대 경로인 경우는 지정을 할 수 없으므로 실행되고 있는 경로를 기준으로 항상 상대 경로 처리로 진행을 해 주어야 한다.
아직은 스크립트 상태이므로 간략하게 디버깅이라기 보다는 디버깅을 위한 옵션이 어떻게 존재하는지를 알아보도록 하자.
msbuild_vs2013_x86 /?
위와 같이 실행하면 여러 가지 옵션 정보들이 보인다. 그 옵션들 중에서 디버깅 용도로 사용할 수 있는 옵션은 /verbosity: 로 약식으로는 /v: 로 지정하면 된다. 같이 설정하게 되는 Level 은 다음과 같은 의미를 가진다.
- q[uiet] - 로거에 빌드 요약만 처리한다.
- m[inimal] - 로거에 빌드 요약과 오류, 경고 등과 같은 중요 메시지만 처리한다.
- n[ormal] - 로거에 빌드 요약과 오류, 경고 등과 같은 중요 메시지 및 이벤트 상태 정보를 처리한다.
- d[etail] - 로거에 빌드 요약과 오류, 경고 등과 같은 중요 및 일반 메시지와 이벤트 상태 정보를 처리한다.
- diag[nostic] - 로거에 빌드 용약과 모든 메시지, 이벤트 등을 전부 처리한다.
디버깅을 위한 경우라면 당연히 /v:diag 를 사용하면 된다.
댓글
댓글 쓰기