IT/모바일
저자: Mike Gunderloy, 역 한동훈
원문 URL: http://www.ondotnet.com/pub/a/dotnet/2004/04/19/wix.html
마이크로소프트에서 소스 코드를 제공하는 오픈 소스 커뮤니티로 유명한 소스포지(SourceForge)(http://sourceforge.net)에 오픈 소스 라이선스로 응용 프로그램을 발표하여 많은 사람들을 놀래켰다. 마이크로소프트가 오픈 소스 코드로 내놓은 것은 이번이 처음은 아니지만, WiX(Windows Installer XML)(http://sourceforge.net/projects/wix) 프로젝트는 발표 이후로 다양한 논란이 있지만 기술적인 면에서는 어떠한가? 손쉽게 편집할 수 있는 XML 파일을 이용하여 설치 프로그램을 개발 과정에 통합하기를 원하는 개발자들에게는 다양한 매력적인 것들을 제공하는 것을 알 수 있다. 따라서, 여기서는 정치적 논쟁은 제쳐놓고, WiX를 사용하여 실제로 무엇을 할 수 있는가만 알아보기로 하자.
기본 개념
분명히 하기위해, WiX는 XML 파일을 이용하는 도구들의 모음이며, 이 XML 파일들을 MSI 파일로 변경하는 것이다. 물론, MSI 파일은 새로운 소프트웨어를 설치하기 위해 윈도우 설치 서비스(Windows Installer Service)에서 사용하는 소스 파일이다. 설치를 위해서 윈도우 설치 서비스를 사용하면 프로그램 추가/삭제에서 설치 과정 중에 문제가 발생할 경우 시스템을 손상시키지 않고 자동으로 원상복구하는 기능을 제공한다.
마이크로소프트 같은 대기업에서 설치 프로그램을 작성하는 사람들은 아무것도 안하는 것이 아니라 설치 프로그램을 작성하는 일을 한다. 그럼에도 불구하고 대부분의 개발자들에게 설치 프로그램을 작성하는 것은 개발에 들이는 노력에 비하면 부수적인 것에 불과하다. 윈도우 설치 도구를 사용하기 전에 먼저 설치 프로그램에 대한 4가지 기본 개념을 이해하는 것이 필요하다.
위 네 가지 개념은 윈도우 설치 서비스의 복잡한 부분을 간단하게 설명한 것이지만, WiX를 사용하는 데에는 충분하다. 이 주제에 대해서 깊이 알고 싶다면, 인스톨러가 사용하는 데이터베이스에 대한 레퍼런스를 보기 바란다. InstallSite.Org에 이에 대한 도서 목록을 제공하고 있으므로 이를 참고하거나 MSDN 라이브러리에서 윈도우 설치 문서를 찾아볼 수 있다.
설치 파일 빌드하기
몇 가지 명령줄 도구와 기본 에디터인 Orca는 Windows Installer SDK에서 제공된다. 이러한 도구들을 사용하여 윈도우 설치 서비스의 모든 기능을 사용하는 패키지를 만들 수 있다. 그렇다면 왜 이 SDK를 깊이 살펴보지 않는가?라고 질문할 수 있다. 그렇지만, 이들 도구는 특별히 강력한 기능을 제공하지도 않고, 사용하기 쉬운 것도 아니다.
다행히도 SDK가 유일한 제품이 아니다. Wise(wise.com)나 InstallShield(installshield.com)과 같은 많은 회사들이 설치 패키지 작성을 위한 도구들을 작성하고 있다. 이들 도구들은 초보자 뿐만 아니라 설치 서비스의 모든 기능을 사용하려는 숙련된 개발자들에게 도움을 준다. 이러한 도구들은 사용자 인터페이스 편집기, 자동으로 의존성을 검사하는 도구들, 마법사를 비롯한 강력한 도구들을 제공한다. 마이크로소프트도 Visual Studio .Net의 설치 프로젝트에서 설치 패키지를 작성할 수 있다.
그러나 이러한 개발자를 위한 도구들은 자동화된 빌드 프로세스에 적합하지 않다. 최근의 체크인, 변경된 파일 이름과 같은 다양한 변경사항에 따라 설치 파일에 어떤 것들을 포함시킬지를 결정하는 것과 같은 작업에 적합하지 않다. 그러한 이유로 WiX가 개발된 것이다. WiX는 XML 파일을 사용하여 윈도우 설치 패키지의 구조를 정의할 수 있으므로, XML 파일이 제공하는 일반적인 장점들을 사용할 수 있다. 다양한 도구를 사용한 쉬운 편집, 잘 알려진 기술을 사용한 파일을 편집하는 기능, 소스 코드 컨트롤로 소스 파일을 관리할 수 있는 기능등을 사용할 수 있다. WiX 도구는 명령줄 도구이므로 대부분의 빌드 프로세스에 적합하다.
WiX 소스 파일
WiX 소스 파일은 어떤가? 다음에서 볼 수 있는 것처럼 간단하다.
이 파일을 WiX로 빌드하면 하나의 실행파일과 README 파일로 구성된 “Hello World” 응용 프로그램을 설치하고, 시작->프로그램 메뉴에서 응용 프로그램을 실행할 수 있는 단축 아이콘을 추가한다. 이러한 빌드 과정을 보여주기 전에 파일의 각 부분을 먼저 살펴보도록 하자.
표준 XML 헤더 다음에 모든 WiX 소스 파일은 WiX 스키마를 참고하는 Wix 루트 요소를 정의해야 한다.
설명할 필요없이 Product 요소는 인스톨러가 설치할 제품을 정의한다. 각 요소 이름은 윈도우 설치 데이터베이스의 테이블에 해당하며, 속성은 열에 해당한다. 이러한 관계가 WiX에서 사용하는 일반적인 패턴이다.
그러나, 이러한 관계가 정확하게 일치하는 것은 아니다. 예를 들어, 설치 데이터베이스는 다양한 테이블의 관계를 정의하기 위해 외래키(foreign key)를 사용하지만, WiX 소스 파일은 이러한 관계를 포함하기 위해 중첩을 사용한다. WiX 도구를 사용할 때는 정확한 외래키 값을 사용하도록 주의해야 한다.
Product 요소안에 WiX 파일에 대한 패키지를 정의하는 Package 요소가 있다.
Media 요소는 MSI 파일과 관련된 CAB 파일에 저장되어 있는 배포용 미디어를 정의한다. 이런 경우에 EmdebCab 속성을 yes로 정의하여 MSI 파일에 CAB 파일을 포함시킬 수 있다. 이렇게 작성된 패키지는 하나의 파일로 구성된다. 패키지 하나에 여러 개의 Media 요소를 사용할 수 있다. 이 기능은 다양한 디스켓에 나누어 소프트웨어를 배포할 때에 비하면 덜 중요한 기능이 되었다.
Directory 요소는 설치 서비스가 이 소프트웨어를 사용할 디렉터리 계층을 정의하기 위해 사용한다. Id 속성은 임의로 정의한 것이 아니라 윈도우 인스톨러에서 정의한 특별한 디렉터리를 의미한다. 프로그램 파일 폴더를 나타낸 ProgramFilesFolder 속성과 ProgramMenuFolder 속성은 특별한 디렉터리이다.
Component 요소와 하위 요소는 설치될 소프트웨어를 정의하는 부분이다. 여기서 첫번째 컴포넌트는 하나의 파일로 되어 있으며, 두번째 컴포넌트는 파일과 파일에 대한 단축아이콘을 포함하고 있다. WiX는 XML 파일에 정의된 파일들을 검색한다. 따라서 가장 좋은 방법은 소스 파일과 XML 파일을 같은 폴더에 두고, WiX 도구는 실행 경로 설정에 포함시키는 것이다.
마지막으로(여기서는), Feacture 요소는 패키지에 한 가지 기능과 기능과 컴포넌트 사이의 관계를 모두 정의한다. 여기서, 기능은 두 가지 컴포넌트를 모두 포함한다.
물론, MSI 파일은 매우 복잡한 작업을 수행할 수 있으며, 그에 해당하는 WiX 소스 파일도 여기에 소개한 것보다 훨씬 복잡해진다. 복잡한 파일을 개발함에 따라 윈도우 인스톨러 SDK와 WiX 문서를 책상 가까이에 두게 될 것이다.
빌드와 테스트
WiX 소스 파일로 MSI로 변환하는 것은 2단계 과정을 거친다. 두 가지 과정 모두 명령줄 도구를 사용하여 수행된다. 첫번째는 컴파일러 candle이며, 사용법은 다음과 같다.
잘못된 것이 없다면 WiX 도구의 출력결과는 매우 간단하다. Candle은 단순히 입력 파일의 이름을 출력한다. 원한다면 저작권 정보를 출력하지 않도록 ?nologo 스위치를 사용할 수 있다. 이와 같이 별다른 것도 출력하지 않는 유틸리티가 명령줄 자동화를 위해서는 더욱 좋으므로, 이것은 매우 멋진 기능이다. 다음 단계는 링커인 light를 사용하는 것이다.
light에서 어떤 에러가 발견되지 않았다면 MSI 파일이 생성된다. 탐색기에서 더블 클릭을 하여 설치할 수 있지만, 명령줄에서 실행하는 윈도우 인스톨러 도구를 사용할 수도 있다.
테스트가 끝났으면 같은 유틸리티를 사용하여 프로그램을 제거할 수 있다.
설치제거를 위해서 스위치 /u가 아니라 /x를 사용한 것에 주의해야 한다.
마지막으로, 알아야 할 WiX 도구가 하나 더 있다. dark라는 도구가 그것인데 기존 MSI 파일에서 그에 해당하는 WXS 파일을 생성하는 도구다. 이것은 MSI 파일과 WiX 파일이 서로 어떻게 작용하는지 이해하는데에는 좋지만 복잡한 설치인 경우에 굉장히 큰 WiX 소스 파일이 생성될 수 있다는 것을 알고 있어야 한다.
마지막으로(What Next?)
WiX를 사용하여 MSI 파일을 작성하는 것에 대한 많은 내용들을 자세히 설명할 수 있지만, 모든 것을 설명하려면 책 한 권 분량이 될 것이다. 대신에 여기서는 잠시 뒤로 물러서서 큰 그림을 그려보자.
WiX를 사용하면 설치 패키지 구축을 위한 과정이 세밀하게 제어할 수 있는 원본 XML 소스 파일이 된다. XML 소스 파일을 소스 코드 컨트롤을 사용하여 유지한다면 모든 변경사항은 추적될 것이며 사고가 발생한 경우에도 재빨리 원상복구할 수 있다. 또한, 어떻게 하면 WiX 파일을 자동으로 생성할 수 있을지 알 수 있을 것이다. 복잡한 소프트웨어 제품은 설치하기 위해 필요한 수백개의 기능과 컴포넌트로 구성된 방대한 목록을 갖게 될 것이다. 이러한 목록을 엑세스나 엑셀의 "XML로 저장하기"를 사용하여 자동으로 WiX 소스 파일을 작성할 수 있을 것이다. 결국, 설치 파일이 많은 개발자들에 의해 생성될 수 있으며, 각 개발자들의 작업 결과는 자동화된 도구를 사용한 XML 소스 파일의 일부분이 될 수 있을 것이다.
이러한 계획이 동작하는가? 물론이다! 이 도구는 마이크로소프트 내부에서 많은 팀들이 수년간 사용했던 것이며, 이제 시험대에 올라왔다. WiX를 오픈 소스로 발표함에 따라 필요한 기능을 추가하거나 향상된 보안을 위한 기능을 추가할 수 있을 것이다. WiX는 설치 파일 작성자에게 결국 윈윈이 될 것이다.
Mike Gunderloy는 Larkware의 수석 개발자(Lead Developer)이며, 프로그래밍에 대한 다양한 책과 글의 저자이다.
원문 URL: http://www.ondotnet.com/pub/a/dotnet/2004/04/19/wix.html
마이크로소프트에서 소스 코드를 제공하는 오픈 소스 커뮤니티로 유명한 소스포지(SourceForge)(http://sourceforge.net)에 오픈 소스 라이선스로 응용 프로그램을 발표하여 많은 사람들을 놀래켰다. 마이크로소프트가 오픈 소스 코드로 내놓은 것은 이번이 처음은 아니지만, WiX(Windows Installer XML)(http://sourceforge.net/projects/wix) 프로젝트는 발표 이후로 다양한 논란이 있지만 기술적인 면에서는 어떠한가? 손쉽게 편집할 수 있는 XML 파일을 이용하여 설치 프로그램을 개발 과정에 통합하기를 원하는 개발자들에게는 다양한 매력적인 것들을 제공하는 것을 알 수 있다. 따라서, 여기서는 정치적 논쟁은 제쳐놓고, WiX를 사용하여 실제로 무엇을 할 수 있는가만 알아보기로 하자.
기본 개념
분명히 하기위해, WiX는 XML 파일을 이용하는 도구들의 모음이며, 이 XML 파일들을 MSI 파일로 변경하는 것이다. 물론, MSI 파일은 새로운 소프트웨어를 설치하기 위해 윈도우 설치 서비스(Windows Installer Service)에서 사용하는 소스 파일이다. 설치를 위해서 윈도우 설치 서비스를 사용하면 프로그램 추가/삭제에서 설치 과정 중에 문제가 발생할 경우 시스템을 손상시키지 않고 자동으로 원상복구하는 기능을 제공한다.
마이크로소프트 같은 대기업에서 설치 프로그램을 작성하는 사람들은 아무것도 안하는 것이 아니라 설치 프로그램을 작성하는 일을 한다. 그럼에도 불구하고 대부분의 개발자들에게 설치 프로그램을 작성하는 것은 개발에 들이는 노력에 비하면 부수적인 것에 불과하다. 윈도우 설치 도구를 사용하기 전에 먼저 설치 프로그램에 대한 4가지 기본 개념을 이해하는 것이 필요하다.
- 제품은 설치하려는 소프트웨어가 여러 개 모여 구성된 것이다. 제품은 마이크로소프트 오피스 2003과 같이 덩치가 큰 것에서부터 파일 하나로 구성된 “Hello World”와 같이 작은 것도 있다. 각 제품은 제품 코드(GUID)로 식별할 수 있다. 제품의 파일에 상대적으로 작은 변경이면 제품 코드를 변경하지 않아도 된다.(역주. 제품 번호는 2.3.11.203과 같이 메이저번호.마이너번호.개정번호.빌드번호의 형식으로 구성된다)
- 윈도우 설치 서비스가 제품을 설치하는데 필요한 모든 것을 갖고 있는 것을 패키지라 한다. 패키지는 설치가 필요로 하는 MSI 파일과 CAB(캐비닛) 파일과 같은 외부파일로 구성된다. 패키지도 패키지 코드(GUID)로 구분된다. 패키지가 변경되면 새로운 패키지 코드를 할당해야 한다.
- 기능(feature)은 소프트웨어를 사용하는 사용자가 이해할 수 있는 기능들을 말한다. 도우미 시스템(help system)이라면 철자 검사나 마법사와 같은 것들이 하나의 기능이 될 수 있다. 사용자가 설치하거나 제거할 수 있는 것들을 트리 형태로 표시해주는 소프트웨어를 설치한 적이 있을 것이다. 그러한 선택사항 각각을 하나의 기능이라 한다. 기능은 패키지 안에서 유일하게 식별할 수 있는 문자열로 구분한다.
- 컴포넌트는 인스톨러가 설치할 수 있는 소프트웨어의 단위다. 컴포넌트는 파일, 레지스트리 키, 단축키, 리소스 등을 포함할 수 있다. 각 컴포넌트는 제품에 관계없이 모든 패키지에서 유일하게 식별할 수 있는 컴포넌트 ID(GUID)로 알 수 있다.
위 네 가지 개념은 윈도우 설치 서비스의 복잡한 부분을 간단하게 설명한 것이지만, WiX를 사용하는 데에는 충분하다. 이 주제에 대해서 깊이 알고 싶다면, 인스톨러가 사용하는 데이터베이스에 대한 레퍼런스를 보기 바란다. InstallSite.Org에 이에 대한 도서 목록을 제공하고 있으므로 이를 참고하거나 MSDN 라이브러리에서 윈도우 설치 문서를 찾아볼 수 있다.
설치 파일 빌드하기
몇 가지 명령줄 도구와 기본 에디터인 Orca는 Windows Installer SDK에서 제공된다. 이러한 도구들을 사용하여 윈도우 설치 서비스의 모든 기능을 사용하는 패키지를 만들 수 있다. 그렇다면 왜 이 SDK를 깊이 살펴보지 않는가?라고 질문할 수 있다. 그렇지만, 이들 도구는 특별히 강력한 기능을 제공하지도 않고, 사용하기 쉬운 것도 아니다.
다행히도 SDK가 유일한 제품이 아니다. Wise(wise.com)나 InstallShield(installshield.com)과 같은 많은 회사들이 설치 패키지 작성을 위한 도구들을 작성하고 있다. 이들 도구들은 초보자 뿐만 아니라 설치 서비스의 모든 기능을 사용하려는 숙련된 개발자들에게 도움을 준다. 이러한 도구들은 사용자 인터페이스 편집기, 자동으로 의존성을 검사하는 도구들, 마법사를 비롯한 강력한 도구들을 제공한다. 마이크로소프트도 Visual Studio .Net의 설치 프로젝트에서 설치 패키지를 작성할 수 있다.
그러나 이러한 개발자를 위한 도구들은 자동화된 빌드 프로세스에 적합하지 않다. 최근의 체크인, 변경된 파일 이름과 같은 다양한 변경사항에 따라 설치 파일에 어떤 것들을 포함시킬지를 결정하는 것과 같은 작업에 적합하지 않다. 그러한 이유로 WiX가 개발된 것이다. WiX는 XML 파일을 사용하여 윈도우 설치 패키지의 구조를 정의할 수 있으므로, XML 파일이 제공하는 일반적인 장점들을 사용할 수 있다. 다양한 도구를 사용한 쉬운 편집, 잘 알려진 기술을 사용한 파일을 편집하는 기능, 소스 코드 컨트롤로 소스 파일을 관리할 수 있는 기능등을 사용할 수 있다. WiX 도구는 명령줄 도구이므로 대부분의 빌드 프로세스에 적합하다.
WiX 소스 파일
WiX 소스 파일은 어떤가? 다음에서 볼 수 있는 것처럼 간단하다.
〈?xml version="1.0" encoding="utf-8"?〉
〈Wix xmlns="http://schemas.microsoft.com/wix/2003/01/wi"〉
〈Product Name="Fancy Hello" Id="4AA22F5D-D457-4A58-99FB-56AFF7FFD2CC"
Version="1.0.0" Manufacturer="Lark Group, Inc." Language="1033"〉
〈Package Id="6697CCC3-B351-4DCE-820E-DEAC87F57A2A"
Comments="This MSI file installs the FancyHello application"
Manufacturer="Lark Group, Inc." InstallerVersion="200"
Languages="1033" Compressed="yes"/〉
〈Media Id="1" EmbedCab="yes" Cabinet="Fancy.cab"/〉
〈Directory Id="TARGETDIR" Name="SourceDir"〉
〈Directory Id="ProgramFilesFolder" Name="PFiles"〉
〈Directory Id="FHDir" Name="Fancy" LongName="FancyHello"〉
〈Component Id="SayHello Documentation"
Guid="8637E553-C046-60E0-9101-8D35A2870C86"〉
〈File Id="readme" Name="Readme.txt"
LongName="Readme.txt" DiskId="1" src="Readme.txt"/〉
〈/Component〉
〈Component Id="Core"
Guid="B081FEDE-736F-541C-26EA-BA1015D31B37"〉
〈File Id="Main program" Name="FANCYH~1.EXE"
LongName="FancyHello.exe" DiskId="1"
src="FancyHello.exe"〉
〈Shortcut Id="Program shortcut"
Directory="ProgramMenuFolder" Name="SayHello"
Target="DefaultFeature" Show="normal"
WorkingDirectory="TARGETDIR"/〉
〈/File〉
〈/Component〉
〈/Directory〉
〈/Directory〉
〈Directory Id="ProgramMenuFolder" Name="PMFolder"〉
〈/Directory〉
〈/Directory〉
〈Feature Id="DefaultFeature" Level="1"〉
〈ComponentRef Id="SayHello Documentation"/〉
〈ComponentRef Id="Core"/〉
〈/Feature〉
〈/Product〉
〈/Wix〉
이 파일을 WiX로 빌드하면 하나의 실행파일과 README 파일로 구성된 “Hello World” 응용 프로그램을 설치하고, 시작->프로그램 메뉴에서 응용 프로그램을 실행할 수 있는 단축 아이콘을 추가한다. 이러한 빌드 과정을 보여주기 전에 파일의 각 부분을 먼저 살펴보도록 하자.
〈?xml version="1.0" encoding="utf-8"?〉
〈Wix xmlns="http://schemas.microsoft.com/wix/2003/01/wi"〉
...
〈/Wix〉
표준 XML 헤더 다음에 모든 WiX 소스 파일은 WiX 스키마를 참고하는 Wix 루트 요소를 정의해야 한다.
〈Product Name="Fancy Hello" Id="4AA22F5D-D457-4A58-99FB-56AFF7FFD2CC"
Version="1.0.0" Manufacturer="Lark Group, Inc." Language="1033"〉
...
〈/Product〉
설명할 필요없이 Product 요소는 인스톨러가 설치할 제품을 정의한다. 각 요소 이름은 윈도우 설치 데이터베이스의 테이블에 해당하며, 속성은 열에 해당한다. 이러한 관계가 WiX에서 사용하는 일반적인 패턴이다.
그러나, 이러한 관계가 정확하게 일치하는 것은 아니다. 예를 들어, 설치 데이터베이스는 다양한 테이블의 관계를 정의하기 위해 외래키(foreign key)를 사용하지만, WiX 소스 파일은 이러한 관계를 포함하기 위해 중첩을 사용한다. WiX 도구를 사용할 때는 정확한 외래키 값을 사용하도록 주의해야 한다.
〈Package Id="6697CCC3-B351-4DCE-820E-DEAC87F57A2A"
Comments="This MSI file installs the FancyHello application"
Manufacturer="Lark Group, Inc." InstallerVersion="200"
Languages="1033" Compressed="yes"/〉
Product 요소안에 WiX 파일에 대한 패키지를 정의하는 Package 요소가 있다.
〈Media Id="1" EmbedCab="yes" Cabinet="Fancy.cab"/〉
Media 요소는 MSI 파일과 관련된 CAB 파일에 저장되어 있는 배포용 미디어를 정의한다. 이런 경우에 EmdebCab 속성을 yes로 정의하여 MSI 파일에 CAB 파일을 포함시킬 수 있다. 이렇게 작성된 패키지는 하나의 파일로 구성된다. 패키지 하나에 여러 개의 Media 요소를 사용할 수 있다. 이 기능은 다양한 디스켓에 나누어 소프트웨어를 배포할 때에 비하면 덜 중요한 기능이 되었다.
〈Directory Id="TARGETDIR" Name="SourceDir"〉
〈Directory Id="ProgramFilesFolder" Name="PFiles"〉
〈Directory Id="FHDir" Name="Fancy" LongName="FancyHello"〉
...
〈/Directory〉
〈/Directory〉
〈Directory Id="ProgramMenuFolder" Name="PMFolder"〉
〈/Directory〉
〈/Directory〉
Directory 요소는 설치 서비스가 이 소프트웨어를 사용할 디렉터리 계층을 정의하기 위해 사용한다. Id 속성은 임의로 정의한 것이 아니라 윈도우 인스톨러에서 정의한 특별한 디렉터리를 의미한다. 프로그램 파일 폴더를 나타낸 ProgramFilesFolder 속성과 ProgramMenuFolder 속성은 특별한 디렉터리이다.
〈Component Id="SayHello Documentation"
Guid="8637E553-C046-60E0-9101-8D35A2870C86"〉
〈File Id="readme" Name="Readme.txt"
LongName="Readme.txt" DiskId="1" src="Readme.txt"/〉
〈/Component〉
〈Component Id="Core"
Guid="B081FEDE-736F-541C-26EA-BA1015D31B37"〉
〈File Id="Main program" Name="FANCYH~1.EXE"
LongName="FancyHello.exe" DiskId="1"
src="FancyHello.exe"〉
〈Shortcut Id="Program shortcut"
Directory="ProgramMenuFolder" Name="SayHello"
Target="DefaultFeature" Show="normal"
WorkingDirectory="TARGETDIR"/〉
〈/File〉
〈/Component〉
Component 요소와 하위 요소는 설치될 소프트웨어를 정의하는 부분이다. 여기서 첫번째 컴포넌트는 하나의 파일로 되어 있으며, 두번째 컴포넌트는 파일과 파일에 대한 단축아이콘을 포함하고 있다. WiX는 XML 파일에 정의된 파일들을 검색한다. 따라서 가장 좋은 방법은 소스 파일과 XML 파일을 같은 폴더에 두고, WiX 도구는 실행 경로 설정에 포함시키는 것이다.
〈Feature Id="DefaultFeature" Level="1"〉
〈ComponentRef Id="SayHello Documentation"/〉
〈ComponentRef Id="Core"/〉
〈/Feature〉
마지막으로(여기서는), Feacture 요소는 패키지에 한 가지 기능과 기능과 컴포넌트 사이의 관계를 모두 정의한다. 여기서, 기능은 두 가지 컴포넌트를 모두 포함한다.
물론, MSI 파일은 매우 복잡한 작업을 수행할 수 있으며, 그에 해당하는 WiX 소스 파일도 여기에 소개한 것보다 훨씬 복잡해진다. 복잡한 파일을 개발함에 따라 윈도우 인스톨러 SDK와 WiX 문서를 책상 가까이에 두게 될 것이다.
빌드와 테스트
WiX 소스 파일로 MSI로 변환하는 것은 2단계 과정을 거친다. 두 가지 과정 모두 명령줄 도구를 사용하여 수행된다. 첫번째는 컴파일러 candle이며, 사용법은 다음과 같다.
E:\Program Files\wix>candle fancyhellosetup.wxs
Microsoft (R) Windows Installer Xml Compiler version 2.0.1615.0
Copyright (C) Microsoft Corporation 2003. All rights reserved.
fancyhellosetup.wxs
잘못된 것이 없다면 WiX 도구의 출력결과는 매우 간단하다. Candle은 단순히 입력 파일의 이름을 출력한다. 원한다면 저작권 정보를 출력하지 않도록 ?nologo 스위치를 사용할 수 있다. 이와 같이 별다른 것도 출력하지 않는 유틸리티가 명령줄 자동화를 위해서는 더욱 좋으므로, 이것은 매우 멋진 기능이다. 다음 단계는 링커인 light를 사용하는 것이다.
E:\Program Files\wix>light fancyhellosetup.wixobj
Microsoft (R) Windows Installer Xml Linker version 2.0.1615.0
Copyright (C) Microsoft Corporation 2003. All rights reserved.
light에서 어떤 에러가 발견되지 않았다면 MSI 파일이 생성된다. 탐색기에서 더블 클릭을 하여 설치할 수 있지만, 명령줄에서 실행하는 윈도우 인스톨러 도구를 사용할 수도 있다.
msiexec /i fancyhellosetup.msi
테스트가 끝났으면 같은 유틸리티를 사용하여 프로그램을 제거할 수 있다.
msiexec /x fancyhellosetup.msi
설치제거를 위해서 스위치 /u가 아니라 /x를 사용한 것에 주의해야 한다.
마지막으로, 알아야 할 WiX 도구가 하나 더 있다. dark라는 도구가 그것인데 기존 MSI 파일에서 그에 해당하는 WXS 파일을 생성하는 도구다. 이것은 MSI 파일과 WiX 파일이 서로 어떻게 작용하는지 이해하는데에는 좋지만 복잡한 설치인 경우에 굉장히 큰 WiX 소스 파일이 생성될 수 있다는 것을 알고 있어야 한다.
마지막으로(What Next?)
WiX를 사용하여 MSI 파일을 작성하는 것에 대한 많은 내용들을 자세히 설명할 수 있지만, 모든 것을 설명하려면 책 한 권 분량이 될 것이다. 대신에 여기서는 잠시 뒤로 물러서서 큰 그림을 그려보자.
WiX를 사용하면 설치 패키지 구축을 위한 과정이 세밀하게 제어할 수 있는 원본 XML 소스 파일이 된다. XML 소스 파일을 소스 코드 컨트롤을 사용하여 유지한다면 모든 변경사항은 추적될 것이며 사고가 발생한 경우에도 재빨리 원상복구할 수 있다. 또한, 어떻게 하면 WiX 파일을 자동으로 생성할 수 있을지 알 수 있을 것이다. 복잡한 소프트웨어 제품은 설치하기 위해 필요한 수백개의 기능과 컴포넌트로 구성된 방대한 목록을 갖게 될 것이다. 이러한 목록을 엑세스나 엑셀의 "XML로 저장하기"를 사용하여 자동으로 WiX 소스 파일을 작성할 수 있을 것이다. 결국, 설치 파일이 많은 개발자들에 의해 생성될 수 있으며, 각 개발자들의 작업 결과는 자동화된 도구를 사용한 XML 소스 파일의 일부분이 될 수 있을 것이다.
이러한 계획이 동작하는가? 물론이다! 이 도구는 마이크로소프트 내부에서 많은 팀들이 수년간 사용했던 것이며, 이제 시험대에 올라왔다. WiX를 오픈 소스로 발표함에 따라 필요한 기능을 추가하거나 향상된 보안을 위한 기능을 추가할 수 있을 것이다. WiX는 설치 파일 작성자에게 결국 윈윈이 될 것이다.
Mike Gunderloy는 Larkware의 수석 개발자(Lead Developer)이며, 프로그래밍에 대한 다양한 책과 글의 저자이다.
TAG :
이전 글 : 게임 서버의 구조(1)
다음 글 : 게임 서버의 구조(2)
최신 콘텐츠