Microsoft MVP성태의 닷넷 이야기
Team Foundation Server: 27. TeamBuild + VDPROJ 셋업 프로젝트 [링크 복사], [링크+제목 복사],
조회: 23461
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

TeamBuild + VDPROJ 셋업 프로젝트


혹시, Team Build에 vdproj 셋업 프로젝트를 엮어 보셨나요?
오늘 문득, 테스트 프로젝트를 만들다가 거기까지 가버려서 ^^; 저도 오늘 처음 해본 것이었습니다.

셋업 프로젝트를 팀 빌드에 연계하는 것은 이미 다음의 문서에 설명이 되어 있습니다.

Visual Studio Team System
Walkthrough: Configuring Team Build to Build a Visual Studio Setup Project
; http://msdn.microsoft.com/en-us/library/ms404859.aspx

아쉽게도, 아직 vdproj는 MSBuild에서 지원되지 않기 때문에 devenv.exe를 이용해서 빌드해야 합니다. Visual C++ 프로젝트는 VS.NET 2010에서 MSBuild가 지원된다고 하는데, 아무래도 vdproj는 그럴 것 같지는 않습니다. 왜냐하면, WiX(Windows Installer XML) toolset을 지원하기로 했다고 합니다. (물론, 정책이야 바뀔지도 모르지만.)

아무튼, 그래서 실제로 위의 문서대로 빌드를 해보면 "정상적인" vdproj는 빌드 시 오류가 발생합니다. 다음과 같이!

Task "Exec"
  Command:
  "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe" "C:\TeamBuild\TestSetup.vdproj" /Build "Release"
  
  Microsoft (R) Visual Studio Version 9.0.21022.8.
  Copyright (C) Microsoft Corp. All rights reserved.
  ------ Starting pre-build validation for project 'TestSetup' ------ 
EXEC : error : Cannot find outputs of project output group '(unable to determine name)'.  Either the group, its configuration, or its project may have been removed from the solution.
EXEC : error : Cannot find outputs of project output group '(unable to determine name)'.  Either the group, its configuration, or its project may have been removed from the solution.
  ------ Pre-build validation for project 'TestSetup' completed ------
  ------ Build started: Project: TestSetup, Configuration: Release ------
  ========== Build: 0 succeeded or up-to-date, 1 failed, 0 skipped ==========
  

보시는 것처럼, "EXEC : error : Cannot find outputs of project output group"과 같은 오류 메시지가 출력이 됩니다. 아쉽군요. ^^;

원인은 간단합니다. vdproj 파일은 대개 설정이 아래의 그림과 같이 다른 프로젝트의 "Output"을 받도록 하는 경우가 많습니다.

[그림 1: 출력 결과를 받도록 지정된 셋업 프로젝트]
vdproj_teambuild_after_drop_1.PNG

그런데, 문제는 이러한 Output이 솔루션 문맥 안에서 빌드될 때 유효하다는 것입니다. 일례로, 시험삼아 솔루션 프로젝트를 하나 만들어서 그 안에 vdproj 솔루션을 추가해 보면 그 이유를 쉽게 알 수 있습니다. 아래의 그림에 보면, "Error List" 창에 출력된 설명이 위의 빌드 오류에서 만난 것과 동일하지요.

[그림 2: 출력 결과를 알 수 없는 셋업 프로젝트]
vdproj_teambuild_after_drop_2.PNG

이런 이유 때문에, vdproj는 솔루션 파일이 같이 지정되어 빌드되어야 합니다. 이에 대해서는 아래의 아티클에서 간단하게 설명되어지고 있습니다.

MS Team Foundation Server / Team Build (Part 2) 
; http://myramserialize.blogspot.com/2008/04/ms-team-foundation-server-team-build_08.html

일단, 위의 방법으로 문제는 해결되지만... 문제 아닌 문제가 발생합니다. 바로 팀 빌드시에 빌드가 2번 된다는 것입니다. 원래의 Team Build로 인해 빌드가 한번 되고, vdproj를 빌드하기 위해 *.sln 파일을 지정하는 것 때문에 한 번 더 빌드가 됩니다. 음... 별로 마음에 들지 않지요? ^^;

그래서, 저 같은 경우에는 이렇게 결론을 맺었습니다.

셋업 프로젝트 빌드를 위해 별도의 빌드 옵션을 만들고, 그 옵션에서는 셋업 프로젝트를 제외한 다른 모든 빌드를 해제한다. 그리고, 팀 빌드의 vdproj 빌드에서 바로 그 빌드 옵션을 사용한다.


예를 들어, 아래의 그림에서 보는 것처럼 별도로 "BuildSetup"이라는 옵션을 추가하고 "ProcessControllerServiceSetup" / "ProcessControllerServiceSetup64" 2개의 vdproj를 제외하고는 빌드 옵션을 해제해 버렸습니다.

[그림 3: "BuildSetup" 옵션 추가]
vdproj_teambuild_after_drop_3.PNG

아래의 팀 빌드는, 바로 그렇게 추가된 "BuildSetup"을 지정하도록 변경된 것입니다.

<Target Name="AfterDropBuild">
    <!-- 32bit MSI setup -->
    <Exec Command="devenv &quot;$(SolutionRoot)\PublicTools.sln&quot; 
    /Build &quot;BuildSetup&quot; 
    /Project &quot;$(SolutionRoot)\ProcessControllerServiceSetup\ProcessControllerServiceSetup.vdproj&quot; 
    /ProjectConfig &quot;Release&quot;"/>

    <Copy SourceFiles="$(SolutionRoot)\ProcessControllerServiceSetup\Release\ProcessControllerServiceSetup.msi;" DestinationFolder="$(OutDir)" />
</Target>

새롭게 BuildSetup 설정이 추가된 것은 별로 마음에 들지 않지만, 그래도 빌드 2번 하는 것보다야 나으니까. ^^



[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]







[최초 등록일: ]
[최종 수정일: 6/27/2021]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 



2015-01-08 01시18분
"Wax keeps your candle burning" (You'll get that if you know WiX)
; http://coolthingoftheday.blogspot.com/2015/01/keeps-your-candle-burning-you-get-that.html
정성태

... 61  62  63  64  65  66  67  68  69  70  71  72  73  [74]  75  ...
NoWriterDateCnt.TitleFile(s)
12086정성태12/20/201920978디버깅 기술: 144. windbg - Marshal.FreeHGlobal에서 발생한 덤프 분석 사례
12085정성태12/20/201918974오류 유형: 586. iisreset - The data is invalid. (2147942413, 8007000d) 오류 발생 - 두 번째 이야기 [1]
12084정성태12/19/201919401디버깅 기술: 143. windbg/sos - Hashtable의 buckets 배열 내용을 모두 덤프하는 방법 (do_hashtable.py) [1]
12083정성태12/17/201922359Linux: 27. linux - lldb를 이용한 .NET Core 응용 프로그램의 메모리 덤프 분석 방법 [2]
12082정성태12/17/201920582오류 유형: 585. lsof: WARNING: can't stat() fuse.gvfsd-fuse file system
12081정성태12/16/201922438개발 환경 구성: 465. 로컬 PC에서 개발 중인 ASP.NET Core 웹 응용 프로그램을 다른 PC에서도 접근하는 방법 [5]
12080정성태12/16/201919605.NET Framework: 870. C# - 프로세스의 모든 핸들을 열람
12079정성태12/13/201921492오류 유형: 584. 원격 데스크톱(rdp) 환경에서 다중 또는 고용량 파일 복사 시 "Unspecified error" 오류 발생
12078정성태12/13/201921290Linux: 26. .NET Core 응용 프로그램을 위한 메모리 덤프 방법 [3]
12077정성태12/13/201920388Linux: 25. 자주 실행할 명령어 또는 초기 환경을 "~/.bashrc" 파일에 등록
12076정성태12/12/201918921디버깅 기술: 142. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅 - 배포 방법에 따른 차이
12075정성태12/11/201919724디버깅 기술: 141. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅
12074정성태12/10/201919412디버깅 기술: 140. windbg/Visual Studio - 값이 변경된 경우를 위한 정지점(BP) 설정(Data Breakpoint)
12073정성태12/10/201920918Linux: 24. Linux/C# - 실행 파일이 아닌 스크립트 형식의 명령어를 Process.Start로 실행하는 방법
12072정성태12/9/201917692오류 유형: 583. iisreset 수행 시 "No such interface supported" 오류
12071정성태12/9/201921222오류 유형: 582. 리눅스 디스크 공간 부족 및 safemode 부팅 방법
12070정성태12/9/201923143오류 유형: 581. resize2fs: Bad magic number in super-block while trying to open /dev/.../root
12069정성태12/2/201919529디버깅 기술: 139. windbg - x64 덤프 분석 시 메서드의 인자 또는 로컬 변수의 값을 확인하는 방법
12068정성태11/28/201928205디버깅 기술: 138. windbg와 Win32 API로 알아보는 Windows Heap 정보 분석 [3]파일 다운로드2
12067정성태11/27/201919609디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명 [1]파일 다운로드1
12066정성태11/27/201919268디버깅 기술: 136. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석 - OracleCommand.ExecuteReader에서 OpsSql.Prepare2 PInvoke 호출 분석
12065정성태11/25/201917572디버깅 기술: 135. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석파일 다운로드1
12064정성태11/25/201920503오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
12063정성태11/21/201919430디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
12062정성태11/21/201918913디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
12061정성태11/20/201919363Windows: 167. CoTaskMemAlloc/CoTaskMemFree과 윈도우 Heap의 관계
... 61  62  63  64  65  66  67  68  69  70  71  72  73  [74]  75  ...