WiX 부트 스트 래퍼 프로젝트 구조

Question

우리는 Microsoft Office와 유사한 제품을 가지고 있습니다. 공유 라이브러리가 많은 여러 응용 프로그램. 우리는 현재 여러 개별 MSI 패키지를 사용하여 각 응용 프로그램을 독립적으로 설치하기 때문에이 제품의 배포 프로세스를 리팩토링하려고합니다. 이것이 작동하는 동안 WiX 부트 스트 래퍼를 사용하여 MSI 파일을 번들로 만들고 하나의 설정 응용 프로그램 만 만들려합니다. 현재 모든 공유 라이브러리는 각 MSI 패키지에 포함되어 있으므로 많은 공간이 필요합니다.

우리는이 달성하기 위해 기본적으로 두 가지 옵션이 있습니다 :

• 을 하나 개 윅스 설치 (MSI) 프로젝트를 만듭니다; 모든 제품을 개별적으로 포함하십시오. 특징. 이 경우 공유 라이브러리를 처리하는 것은 꽤 똑바로 입니다. 그러나 프로젝트의 구조는 너무 커서 제게는 입니다.
• 여러 MSI 패키지를 만듭니다. 각 제품에는 제품이 하나만 있으며이를 부트 스트랩퍼에 묶으십시오. 내 의견으로는,이 접근 방식은보다 유연하고 더 명확하게 파일과 관련하여 및 구성 요소의 측면에서 정렬됩니다. 그러나 공유 라이브러리는 어떻게 작동합니까? 각은 모든 MSI 파일에 포함되어서는 안됩니다.

WiX 부트 스트 래퍼 프로젝트에서 어떤 접근 방식이 선호됩니까?

Answer 1

많은 기능을 갖춘 하나의 큰 MSI는 지원하기가 너무 어렵습니다.

MSI간에 구성 요소를 쉽게 공유 할 수 있습니다. 공유 구성 요소에는 동일한 GUID 및 구성 요소 키 경로가 있어야합니다. details을 참조하십시오.

이 목표를 쉽게 달성하려면 모든 공유 구성 요소 (각 구성 요소 또는 자체 조각의 구성 요소 그룹)에 대해 WiX 라이브러리 프로젝트를 만듭니다. 그런 다음 라이브러리를 모든 WiX Package 프로젝트에 포함하고 WiX Package 프로젝트의 해당 구성 요소 (또는 구성 요소 그룹)를 참조하십시오.

Answer 2

공유 구성 요소를 여러 개의 MSI로 그룹화 한 다음 응용 프로그램에 대해 하나 이상의 부트 스트랩퍼를 만들 수 있습니다.

몇 가지 주요 사항은 알고 : 부트 스트 래퍼는 MSI를 설치 그렇게 할 때

1. MsiPackages 구성 할 수 있습니다, 그것은 표시하거나 (ARP) 목록 "프로그램 및 기능"의 MsiPackage을 표시하지 않습니다.

2. MSI는 자체 UI가 있거나있을 수 있습니다. 어쨌든 MsiPackage 요소에서이를 억제 할 수 있습니다. 설치하는 동안 사용자에게 정말로 필요한 것이 있다면 커스텀 부트 스트 래퍼 응용 프로그램에서 MSI로 MsiProperty로 전달할 수 있습니다.

그래서 각 응용 프로그램과 각 공유 구성 요소 그룹에 대해 MSI를 제안합니다. 그리고 하나 또는 응용 프로그램 MSI 및 필요한 공유 MSI에 대한 하나 이상의 부트 스트랩퍼. Visual Studio 및 WiX와 마찬가지로 custom bootstrapper application UI (C++ 또는 .NET)를 만드는 경우 사용자는 하나의 부트 스트 래퍼를 사용하여 다양한 응용 프로그램을 선택적으로 설치/제거 할 수 있습니다.