다음을 통해 공유

Windows 설치 관리자 모범 사례

  • 아티클

이 섹션에서는 애플리케이션 개발자, 설치 작성자, IT 전문가 및 인프라 개발자가 Windows Installer 사용에 대한 모범 사례를 찾는 데 도움이 되는 기본 Windows Installer SDK 설명서에 연결된 팁 목록을 열거합니다.

Windows Installer 버전을 업데이트합니다.

  • Windows Server 2008 R2 및 Windows 7에서 Windows Installer 5.0을 사용합니다. 운영 체제와 함께 제공되는 Windows Installer 버전입니다.
  • Windows Server 2008, Windows Server 2003 SP1(서비스 팩 1),, Windows Vista SP1(서비스 팩 1), 또는 Windows XP SP2(서비스 팩 2)에서 Windows Installer 4.5를 사용합니다. 최신 Windows Installer 버전을 얻는 방법에 대한 자세한 내용은 Windows Installer 재배포 가능 항목을 참조하세요.
  • Windows 2000 SP3(서비스 팩 3)에서 Windows Installer 3.1을 사용합니다. Windows Installer 버전 3.1에는 더 나은 애플리케이션 서비스 및 패치를 지원하는 기능이 있습니다.
  • 많은 중요한 기능이 버전 3.0에 도입되었으며 Windows Installer 버전 2.0에서 지원되지 않음 섹션에 나열되어 있습니다. Windows Installer 2.0용으로 만든 설치 패키지 및 업데이트는 Windows Installer 3.0 이상을 사용하여 설치할 수 있습니다. Windows Installer 3.0에서 사용하는 새 테이블이 포함된 패치 패키지는 Windows Installer 3.0 패치 기능 없이 이전 버전의 Windows Installer를 사용하여 계속 적용할 수 있습니다. 또한 이전 버전의 Windows Installer에서 적용할 수 없는 Windows Installer 3.0이 명시적으로 필요한 패치를 작성할 수도 있습니다. 사용자가 설치 프로그램 버전을 업데이트할 수 없는 경우 애플리케이션 또는 업데이트가 Windows Installer의 향후 업데이트와 호환되는지 확인합니다.
  • Windows Installer의 이전 버전에서 지원하지 않는 Windows Installer 기능 목록은 Windows Installer의 새로운 기능을 참조하세요.

Windows 로고 인증 요구 사항을 충족합니다.

  • 로고 프로그램에 애플리케이션을 제출할 생각이 없더라도 로고 인증 지침을 따르면 Windows Installer 패키지를 개선하는 데 도움이 될 수 있습니다. 로고 요구 사항에 대한 개요와 특정 로고 인증 프로그램에 대한 링크는 Windows Installer 및 로고 요구 사항을 참조하세요.

지역화를 위해 패키지를 준비합니다.

  • 원본 설치 패키지를 작성할 때 향후 지역화를 준비하는 것이 좋습니다. Windows Installer 패키지 지역화에서 제안된 패키지 지역화 프로시저를 따를 수 있습니다.

Windows Installer 개발 도구 및 설명서를 업데이트합니다.

  • Windows Installer 개발 도구는 재배포할 수 없으며 Microsoft에서 제공하는 이러한 도구 버전만 사용해야 합니다. 이들은 Microsoft Windows SDK(소프트웨어 개발 키트)의 Windows Installer 개발자용 Windows SDK 구성 요소에서 사용할 수 있습니다.
  • 여러 독립 소프트웨어 공급업체에서 Windows Installer 패키지를 만들거나 수정하는 도구를 제공합니다. 이러한 도구는 Windows Installer SDK에서 제공하는 도구보다 사용하기 쉬운 패키지 제작 환경을 제공할 수 있습니다. Windows Installer 정보의 기타 원본에서 설명한 정보 리소스에서 이러한 도구에 대해 자세히 알아볼 수 있습니다.
  • 일부 개발자에게는 텍스트 파일에서 패키지를 빌드하는 기능이 더 직관적일 수 있습니다. Sourceforge.net에서 사용할 수 있는 WiX(Windows Installer XML) 도구 집합은 XML 소스 코드에서 Windows 설치 패키지를 빌드합니다.
  • Windows Installer SDK의 설명서는 가장 자주 업데이트됩니다.
  • Windows Vista 이상용 Windows Installer 개발자용 Windows SDK 구성 요소에서 사용할 수 있는 최신 버전의 Msizap.exe(버전 3.1.4000.2726 이상)를 사용합니다. 낮은 버전의 Msizap.exe는 사용자 컴퓨터의 다른 애플리케이션에 적용된 모든 업데이트에 대한 정보를 제거할 수 있습니다. 이 정보가 제거되는 경우 추가 업데이트를 받으려면 이러한 다른 애플리케이션을 제거하고 다시 설치해야 할 수 있습니다.
  • 데이터베이스 테이블 편집기 Orca.exe는 Windows Installer 패키지 및 병합 모듈을 만들고 편집하기 위한 데이터베이스 테이블 편집기입니다. 기본 GUI 인터페이스가 있지만 Windows Installer 데이터베이스의 고급 편집을 지원합니다. 다른 애플리케이션을 기본 개발 도구로 사용하는 경우에도 패키지 문제를 해결하고 테스트할 때 Orca.exe를 사용하는 것이 편리할 수 있습니다.
  • 블로그, 기술 채팅, 뉴스 그룹, 기술 문서 및 웹 사이트에서 사용할 수 있는 최신 Windows Installer 정보는 Windows Installer 정보의 기타 원본을 참조하세요.

레거시 설정 애플리케이션을 다시 패키지하기로 결정한 경우 올바른 재패키지 방법을 따릅니다.

많은 애플리케이션 공급업체는 설치 또는 해당 제품에 대한 네이티브 Windows Installer 패키지를 제공합니다. 기존 레거시 설치 애플리케이션을 Windows Installer 패키지로 변환하는 소프트웨어를 재패키지 도구라고 합니다. 기존 설치 애플리케이션을 다시 패키지하는 것은 최상의 개발 방법이 아닙니다. 처음부터 Windows Installer 기능을 활용하도록 설계된 애플리케이션은 사용자가 더 쉽게 설치하고 서비스할 수 있습니다. 재패키지 소프트웨어를 사용하기로 결정한 경우 다음 방법을 사용하면 더 나은 Windows Installer 패키지를 생성하는 데 도움이 될 수 있습니다.

  • 재패키지 도구는 설치 전후의 준비 시스템 사진을 찍어 레거시 설치를 Windows Installer 패키지로 변환합니다. 캡처 프로세스 중에 발생하는 모든 레지스트리 변경 내용, 파일 변경 내용 또는 시스템 설정이 설치에 포함됩니다. 의도한 사용자의 시스템에 최대한 가깝게 설치를 재패키지하는 데 사용되는 컴퓨터의 하드웨어 및 소프트웨어를 구성합니다. 서로 다른 각 하드웨어 구성에 대해 별도의 패키지를 만듭니다. 깨끗한 준비 컴퓨터를 사용하여 재패키지합니다. 불필요한 애플리케이션을 제거합니다. 불필요한 프로세스를 모두 중지합니다. 필수적이지 않은 모든 시스템 서비스를 닫습니다.
  • 작업을 시작하기 전에 항상 원본 설치의 복사본을 만듭니다. 항상 복사본 작업을 합니다. 패키지 빌드가 완료되기 전에 재패키지 도구를 중지하지 마세요. 재패키지 도구가 패키지를 손상하더라도 원본은 그대로 유지됩니다.
  • Microsoft 소프트웨어 업데이트를 Windows Installer 패키지로 다시 패키지하지 마세요. Microsoft는 서비스 팩과 같은 소프트웨어 업데이트를 설치를 자동으로 실행하는 자동 압축 해제 파일로 릴리스합니다. 이러한 업데이트는 Windows Installer와 다른 설치 프로그램을 사용하여 보호된 Windows 리소스를 바꾸며 Windows Installer 패키지로 변환할 수 없습니다. Windows 서비스 팩을 배포하는 방법에 대한 자세한 내용은 Microsoft TechNet에서 서비스 팩 배포 가이드를 참조하세요.
  • 재패키지 도구를 사용하여 Windows Installer 패키지를 새 패키지로 변환하지 마세요. Windows Installer는 구성 정보를 시스템과 애플리케이션 리소스에 추가합니다. 재패키지 도구가 설치 전후의 시스템을 비교할 때 재패키지 도구는 구성 정보를 애플리케이션의 일부로 잘못 해석합니다. 이는 일반적으로 재패키지된 애플리케이션을 손상시킵니다. 대신 사용자 지정 변환을 사용하여 기존 Windows Installer 패키지를 수정하거나 새 패키지를 만듭니다. Msitran.exe 도구를 사용하여 사용자 지정 변환을 만들 수 있습니다.
  • 재패키지 도구를 사용하여 여러 Windows Installer 패키지를 단일 패키지로 통합하지 마세요. 대신 Msistuff.exe 도구를 사용하여 패키지를 차례로 설치하도록 Setup.exe 부트스트랩 실행 파일을 구성할 수 있습니다.
  • 고객이 쉽게 사용자 지정할 수 있도록 Windows Installer 패키지를 만듭니다. 설치 중에 Windows Installer가 사용하는 전역 변수는 공용 속성 또는 사용자 지정 변환을 사용하여 설정할 수 있습니다. 이러한 속성의 사용에 대한 설명서와 모든 사용자 지정 가능한 값에 대한 실제 기본값을 제공합니다. 속성 가져오기 및 설정에 대한 자세한 내용은 속성 사용을 참조하세요. 사용자 지정 변환의 예는 사용자 지정 변환 예를 참조하세요.

보호된 리소스를 바꾸려고 시도하지 마세요.

Windows Installer 패키지는 설치 또는 업데이트 중에 보호된 리소스를 바꾸려고 시도해서는 안 됩니다. Windows는 필수 시스템 파일, 폴더 및 레지스트리 키의 바꾸기를 방지하기 때문에 Windows Installer는 이러한 리소스를 제거하거나 바꾸지 않습니다. 이러한 리소스를 보호하면 애플리케이션 및 운영 체제 오류를 방지할 수 있습니다.

  • Windows Server 2008 또는 Windows Vista에서 실행할 때 Windows Installer는 WRP( Windows 리소스 보호)로 보호되는 모든 파일 또는 레지스트리 키의 설치를 건너뛰고 로그 파일에 경고를 입력합니다. 오류 없이 나머지 설치를 계속합니다. 자세한 내용은 Windows Installer 및 Windows 리소스 보호 사용을 참조하세요.
  • WRP는 WFP(Windows 파일 보호)의 새 이름입니다. WRP는 필수 시스템 파일뿐만 아니라 레지스트리 키와 폴더를 보호합니다. Windows Server 2003, Windows XP 및 Windows 2000에서 Windows Installer가 WFP로 보호된 파일을 발견하면 설치 프로그램은 WFP가 파일을 설치하도록 요청합니다. 자세한 내용은 Windows Installer 및 Windows 리소스 보호 사용을 참조하세요.

중요하지 않은 리소스에 의존하지 마세요.

설치 또는 업데이트는 다음과 같은 이유로 중요하지 않은 리소스 설치에 의존해서는 안 됩니다.

  • 사용자 지정 작업은 사용자가 설치하는 대신 알리는 기능에 속하는 구성 요소에 의존하는 경우 실패할 수 있습니다.
  • InstallFinalize 작업 전에 시퀀스된 사용자 지정 작업은 설치 중인 어셈블리가 포함된 구성 요소에 의존하는 경우 실패할 수 있습니다. Windows Installer는 InstallFinalize 작업이 완료될 때까지 어셈블리를 GAC(전역 어셈블리 캐시)에 커밋하지 않습니다.

API를 사용하여 Windows Installer 구성 정보를 검색합니다.

애플리케이션 또는 업데이트의 설치는 컴퓨터에 저장된 Windows Installer 구성 정보에 대한 직접 액세스에 의존해서는 안 됩니다. 대신 Windows Installer 애플리케이션 프로그래밍 인터페이스를 사용하여 구성 정보를 검색합니다. 구성 정보의 위치와 형식은 Windows Installer 서비스에서 관리하며 변경될 수 있습니다.

구성 요소 주위에 애플리케이션 설치를 구성합니다.

Windows Installer 서비스는 구성 요소라고 하는 리소스 컬렉션을 설치하거나 제거합니다. 구성 요소는 일반적으로 공유되기 때문에 설치 패키지 작성자는 기능 또는 애플리케이션의 구성 요소를 지정할 때 규칙을 따라야 합니다.

  • 애플리케이션을 구성 요소로 구성할 때 구성 요소 규칙을 준수하여 다른 애플리케이션을 손상시키지 않고 새 구성 요소 또는 새 버전의 구성 요소를 설치하고 제거할 수 있습니다. 설치 프로그램 구성 요소 정의에 설명된 절차를 따를 수 있습니다.
  • 설치 프로그램은 구성 요소 테이블에 지정된 각 구성 요소 ID GUID로 모든 구성 요소를 추적합니다. 구성 요소 ID GUID가 올바른 것은 Windows Installer 참조 계산 메커니즘의 작동에 필수적입니다. 구성 요소 코드 변경의 지침을 따릅니다.
  • 패키지가 구성 요소 규칙을 위반해야 하는 경우 가능한 결과를 알고 설치 시 사용자 시스템의 구성 요소를 손상시킬 수 있는 위치에 이러한 구성 요소를 설치하지 않도록 합니다. 자세한 내용은 구성 요소 규칙이 위반되면 어떻게 되나요?를 참조하세요.
  • 기존 파일을 바꿀 때 Windows Installer가 파일 버전 관리 규칙을 어떻게 적용하는지 알고 있어야 합니다. Windows Installer는 구성 요소의 파일을 설치하기 전에 먼저 구성 요소의 키 파일이 이미 설치되어 있는지 확인합니다. 설치 프로그램이 대상 위치에 설치된 구성 요소의 키 파일과 이름이 같은 파일을 찾으면 두 키 파일의 버전, 날짜 및 언어를 비교하고 파일 버전 관리 규칙을 사용하여 패키지에서 제공하는 구성 요소를 설치할지 여부를 결정합니다. 설치 프로그램이 키 파일에 따라 구성 요소 기반을 바꿔야 한다고 결정하면 설치된 각 파일에 대한 파일 버전 관리 규칙을 사용하여 파일 바꾸기 여부를 결정합니다.

큰 Windows Installer 패키지의 크기를 줄입니다.

매우 큰 Windows 패키지는 시스템 리소스를 사용하며 사용자가 설치하기 어려울 수 있습니다. 다음 방법으로 매우 큰 Windows Installer 패키지의 크기를 줄이는 것이 좋습니다.

  • 설치 파일을 압축하여 캐비닛(.cab) 파일에 저장합니다. 설치 프로그램을 사용하면 .cab 파일을 별도의 외부 파일로 저장하거나 MSI 패키지 자체의 데이터 스트림으로 저장할 수 있습니다. 자세한 내용은 캐비닛 및 압축 원본 사용을 참조하세요.
  • .msi 파일 크기 줄이기에 설명된 옵션 중 하나를 사용하여 .msi 파일에서 낭비되는 스토리지 공간을 제거합니다.
  • Windows Installer 패키지에 32767개가 넘는 파일이 포함된 경우 데이터베이스의 스키마를 변경해야 합니다. 자세한 내용은 큰 패키지 작성을 참조하세요.

사용자 지정 작업을 사용하는 경우 좋은 사용자 지정 작업 사례를 따릅니다.

Windows Installer에는 애플리케이션의 설치 및 유지 관리를 위한 여러 기본 제공 표준 작업이 있습니다. 개발자는 자신만의 사용자 지정 작업을 만드는 대신 표준 작업에 최대한 의존해야 합니다. 그러나 설치 패키지 개발자가 사용자 지정 작업을 작성해야 하는 경우가 있습니다.

어셈블리를 사용하는 경우 올바른 어셈블리 사례를 따릅니다.

패키지가 소프트웨어 어셈블리를 사용하는 경우 패키지에 어셈블리 추가, 어셈블리 업데이트 및 어셈블리 설치 및 제거에 대한 지침을 따릅니다.

동시 설치를 제공하지 마세요.

중첩 설치라고도 하는 동시 설치는 현재 실행 중인 설치 중에 다른 Windows Installer 패키지를 설치합니다. 동시 설치를 사용하는 것은 고객이 서비스하기 어렵기 때문에 좋은 방법이 아닙니다. 동시 설치에서는 패치 및 업그레이드가 작동하지 않을 수 있습니다. 동시 설치 사용에 대한 권장 대안은 대신 설치 애플리케이션과 외부 UI 처리기를 사용하여 여러 Windows Installer 패키지를 순차적으로 설치하는 것입니다.

외부 UI 처리기 사용에 대한 자세한 내용은 MsiSetExternalUI를 사용하여 설치 모니터링을 참조하세요. 레코드 기반 외부 처리기 사용에 대한 자세한 내용은 MsiSetExternalUIRecord를 사용하여 설치 모니터링을 참조하세요.

동시 설치는 경우에 따라 제어된 회사 환경에서 공용이 아닌 애플리케이션을 설치하는 데 사용됩니다. 동시 설치를 사용하기로 결정한 경우 다음 지침을 따릅니다.

  • 배송 제품을 설치하거나 업데이트하기 위해 동시 설치를 사용하지 마세요.
  • 동시 설치는 구성 요소를 공유하면 안 됩니다.
  • 관리 설치에는 동시 설치가 포함되어서는 안 됩니다.
  • 통합 ProgressBar는 동시 설치와 함께 사용하면 안 됩니다.
  • 보급할 리소스는 동시 설치로 설치하면 안 됩니다.
  • 애플리케이션의 동시 설치를 수행하는 패키지는 부모 제품이 제거될 때 동시 애플리케이션도 제거해야 합니다. 중첩 설치는 제어판의 프로그램 추가/제거에서 부모 제품의 컨텍스트 아래에 있습니다.

패키지 이름과 패키지 코드를 일관되게 유지합니다.

.msi 파일에는 사용자가 패키지를 식별할 수 있도록 하는 이름을 지정할 수 있지만 제품 코드를 변경하지 않고 이름을 변경해서는 안 됩니다.

  • .msi 파일에 사용자가 Windows Installer 패키지의 콘텐츠를 식별할 수 있도록 사용자에게 식별 이름을 지정합니다.
  • 제품 코드는 애플리케이션의 기본 ID이며 애플리케이션에 대한 포괄적인 업데이트가 있을 때마다 변경해야 합니다. 자세한 내용은 ProductCode 및 제품 코드 변경을 참조하세요. 애플리케이션의 .msi 파일 이름 변경은 포괄적인 변경으로 간주되며 일관성을 유지하기 위해 항상 제품 코드의 해당 변경이 필요합니다.
  • 패키지 코드는 지정된 설치에 대한 올바른 패키지를 검색하고 유효성을 검사하기 위해 설치 프로그램에서 사용하는 기본 식별자입니다. 동일하지 않은 두 개의 .msi 파일에는 동일한 패키지 코드가 없어야 합니다. 패키지 코드를 변경하지 않고 패키지를 변경하는 경우 설치 프로그램에서 둘 다 여전히 액세스할 수 있는 경우 설치 프로그램은 최신 패키지를 사용하지 않을 수 있습니다. 패키지 코드는 요약 정보 스트림의 수정 버전 번호 요약 속성에 저장됩니다.
  • 제품 코드 및 패키지 코드 GUID의 문자는 모두 대문자여야 합니다.

SelfReg 및 TypeLib 테이블을 사용하지 마세요.

  • 설치 패키지 작성자는 자체 등록 및 SelfReg 테이블을 사용하지 않는 것이 좋습니다. 대신 레지스트리 테이블 그룹에 있는 하나 이상의 테이블을 작성하여 모듈을 등록해야 합니다. 자체 등록 루틴은 중요한 구성 정보를 숨기는 경향이 있기 때문에 자체 등록으로 인해 Windows Installer의 많은 이점이 손실됩니다. 자체 등록을 피하는 이유 목록은 SelfReg 표를 참조하세요.
  • 설치 패키지 작성자는 TypeLib 테이블을 사용하지 않는 것이 좋습니다. TypeLib 테이블을 사용하는 대신 Registry 테이블을 사용하여 형식 라이브러리를 등록합니다. TypeLib 테이블을 사용한 설치가 실패하고 롤백해야 하는 경우 롤백은 컴퓨터를 롤백 이전과 동일한 상태로 복원하지 못할 수 있습니다.

사용자 인터페이스 없이 설치하는 옵션을 제공합니다.

관리자는 종종 사용자 상호 작용 없이 회사 내에서 애플리케이션을 배포하는 것을 선호합니다. 애플리케이션이 사용자 인터페이스 수준 없음으로 설치되는 옵션을 제공하도록 하는 것이 좋습니다.

  • 구성 정보는 공용 속성을 사용합니다. 관리자는 명령줄에서 이 정보를 제공할 수 있습니다.
  • 설치가 대화 상자와의 사용자 상호 작용에서 수집된 정보에 의존하도록 요구하지 마세요. 자동 설치 중에는 이 정보를 사용할 수 없습니다.
  • 자동 설치 중에 사용자 컴퓨터를 자동으로 다시 시작하지 마세요.
  • 관리자는 명령줄 옵션 "/q"를 사용하여 설치할 때 사용자 인터페이스 수준을 설정할 수 있습니다. 사용자 인터페이스 수준은 MsiSetInternalUI를 호출하여 프로그래밍 방식으로 설정할 수도 있습니다.

AlwaysInstallElevated 정책을 사용하지 마세요.

AlwaysInstallElevated 정책이 설정되지 않은 경우 관리자가 배포하지 않은 애플리케이션은 사용자 권한을 사용하여 설치되며 관리되는 애플리케이션만 상승된 권한을 가져옵니다. 이 정책을 설정하면 Windows Installer가 시스템에 애플리케이션을 설치할 때 시스템 권한을 사용하도록 지시합니다. 이 방법은 이 정책이 설정되면 관리자가 아닌 사용자가 승격된 권한으로 설치를 실행하고 컴퓨터의 보안 위치에 액세스할 수 있기 때문에 컴퓨터를 보안 위험에 노출시킬 수 있습니다. 비관리자를 위해 상승된 권한으로 패키지를 설치하거나 사용자별 관리되는 애플리케이션을 패치할 때 AlwaysInstallElevated 정책이 아닌 다른 방법을 사용하는 것이 좋습니다.

무단 설치를 제한하려면 DisableMedia 정책을 사용하도록 설정합니다.

DisableMedia 정책은 애플리케이션의 무단 설치를 방지할 수 있습니다. 이 정책을 사용하면 한 제품의 유지 관리 설치를 실행하는 사용자와 관리자가 찾아보기 대화 상자를 사용하여 설치 가능한 다른 제품의 원본에 대해 CD-ROM과 같은 미디어 원본을 찾을 수 없습니다. 설치가 상승된 권한으로 수행되었는지 여부에 관계없이 다른 제품에 대한 탐색이 금지됩니다. 사용자가 올바르게 레이블이 지정된 미디어 원본이 있는 경우 사용자는 여전히 미디어에서 제품을 다시 설치할 수 있습니다.

원본 패키지 원본 파일을 안전하게 유지하고 사용자가 사용할 수 있도록 합니다.

경우에 따라 애플리케이션을 필요에 따라 설치, 복구 또는 업데이트하기 위해 Windows Installer 패키지의 원래 원본이 필요할 수 있습니다. 설치 프로그램이 사용 가능한 원본을 찾을 수 없는 경우 사용자에게 미디어를 제공하거나 필요한 원본이 포함된 네트워크 위치로 이동하라는 메시지가 표시됩니다. 사용자에게 묻지 않고 설치 프로그램에 필요한 원본이 있는지 확인하는 것이 좋습니다.

  • 디지털 서명 및 외부 캐비닛 파일을 사용하여 설치 프로그램에서 사용 중인 원래 원본이 안전한지 확인합니다. 공용된 위치에 저장된 압축되지 않은 원본 이미지는 안전하지 않습니다.
  • SOURCELIST 속성에 애플리케이션의 설치 패키지에 대한 네트워크 또는 URL 원본 경로의 전체 목록을 포함합니다.
  • 원본 경로에 DFS(분산 파일 시스템) 공유를 사용합니다.
  • Windows Installer API를 사용하여 Windows Installer 애플리케이션 및 패치에 대한 원본 목록 정보를 검색하고 수정합니다. 자세한 내용은 설치 원본 관리를 참조하세요.
  • 설치 프로그램 개체, 제품 개체 및 패치 개체의 메서드와 속성을 사용하여 Windows Installer 애플리케이션 및 패치에 대한 원본 목록 정보를 검색하고 수정합니다.
  • 패치가 원래 원본에 대한 액세스를 요구할 가능성을 최소화하려면 패치가 원래 설치 원본에 대한 액세스를 요구하지 않도록 방지에 나열된 사항을 준수합니다.
  • 시스템의 임시 폴더가 아닌 위치에 패키지 원본 파일을 저장합니다. 임시 폴더에 저장된 Windows Installer 원본 파일은 사용자가 사용할 수 없게 될 수 있습니다.

배포 문제 해결 시 사용자 컴퓨터에서 자세한 로깅을 사용하도록 설정합니다.

Windows Installer 로깅에는 사용자 컴퓨터에서 사용할 수 있는 자세한 로깅 옵션이 포함되어 있습니다. 상세 로그의 정보는 Windows Installer 패키지 배포 문제를 해결할 때 유용할 수 있습니다.

  • 명령줄 옵션, MsiLogging 속성, 로깅 정책, MsiEnableLog 사용, 및 EnableLog 메서드를 사용하여 사용자 컴퓨터에서 자세한 정보 로깅을 사용하도록 설정할 수 있습니다.
  • Windows Installer 로그 파일을 해석하는 데 매우 유용한 리소스는 Wilogutl.exe입니다. 이 도구는 로그 파일 분석을 지원하고 로그 파일에서 발견된 오류에 대한 제안 솔루션을 표시합니다.
  • 자세한 로깅 옵션은 문제 해결 목적으로만 사용해야 하며 시스템 성능과 디스크 공간에 부정적인 영향을 미칠 수 있으므로 그대로 두어서는 안 됩니다. 제어판에서 프로그램 추가/제거 도구를 사용할 때마다 새 파일이 만들어집니다.

제거하면 사용자의 컴퓨터가 깨끗한 상태로 유지됩니다.

애플리케이션 제거는 설치만큼 중요합니다. Windows Installer 패키지를 제거할 때 사용자 컴퓨터에 불필요한 부분이 남아 있지 않아야 합니다.

  • 사용자의 컴퓨터에서 제거했어야 하는 파일이 제거를 실행한 후에도 설치된 상태로 남아 있으면 설치 프로그램이 분리된 파일 제거에 설명된 이유 중 하나 이상으로 인해 해당 파일이 포함된 구성 요소를 제거하지 못하는 것일 수 있습니다.
  • 애플리케이션을 등록해야 하는 경우 애플리케이션이 제거될 때 레지스트리 정보를 제거하도록 패키지를 작성합니다. 자세한 내용은 구성 요소 설치 또는 제거 시 레지스트리 키 추가 또는 제거를 참조하세요. 애플리케이션이 등록되지 않은 경우 애플리케이션은 제어판의 프로그램 추가/제거 기능에 나열되지 않으며 Windows Installer를 사용하여 관리할 수 없습니다.
  • 제어판 프로그램 추가 또는 제거 기능에서 애플리케이션을 숨기고 Windows Installer를 사용하여 애플리케이션을 관리할 수 있도록 하려면 애플리케이션 추가 및 제거하고 레지스트리에 추적 없음 유지 설명된 지침을 따릅니다.
  • 제거 시 필요에 따라 사용자 지정 작업을 실행하거나 실행하지 않도록 조건을 지정해야 합니다. 설치 및 제거 시 다른 사용자 지정 작업을 실행해야 할 수 있습니다.
  • 사용자별 사용자 지정 정보는 컴퓨터의 텍스트 파일에 저장할 수 있습니다. 이렇게 하면 이 사용자 지정 사용자가 현재 로그온하지 않은 경우에도 애플리케이션을 제거할 때 파일을 제거할 수 있다는 이점이 있습니다.

사용자별 및 컴퓨터별 설치 배포를 위한 패키지를 테스트합니다.

고객이 컴퓨터별 또는 사용자별 설치 컨텍스트에서 설치할 패키지를 배포할지 여부를 결정할 수 있도록 하는 것이 좋습니다.

  • 개발 과정에서 애플리케이션을 특정 사용자만 사용할 수 있는지 또는 컴퓨터의 모든 사용자가 사용할 수 있는지 고려합니다.
  • 사용자별 설치 및 컴퓨터별 설치 컨텍스트 모두에 대해 패키지가 올바르게 작동하는지 테스트합니다.
  • 패키지를 쉽게 사용자 지정할 수 있도록 만들고 고객이 사용자 또는 컴퓨터별로 배포할지 여부를 결정할 수 있습니다.

애플리케이션을 배송하기 전에 서비스 전략을 계획하고 테스트합니다.

처음으로 애플리케이션을 배포하기 전에 애플리케이션 서비스 방법을 결정해야 합니다.

  • 향후 애플리케이션 서비스에 사용할 것으로 예상되는 업데이트 형식을 고려합니다. Windows Installer는 소규모 업데이트, 부 업그레이드 및 주요 업그레이드의 세 가지 형식의 업데이트를 제공합니다. 이들 간의 차이점은 패치 및 업그레이드 항목에 설명되어 있습니다.
  • 애플리케이션을 배송하기 전에 각 업데이트 형식으로 서비스를 제공한 후 예상대로 작동하는지 테스트합니다.

원래 원본에 대한 업데이트 종속성을 줄입니다.

애플리케이션을 업데이트하는 데 원래 원본 파일이 필요한 경우 애플리케이션 서비스가 더 어려워질 수 있습니다. 다음 방법은 원래 원본에 대한 업데이트 종속성을 줄이는 데 도움이 될 수 있습니다.

사용할 수 없는 병합 모듈을 배포하지 마세요.

병합 모듈의 소유자와 애플리케이션의 소유자가 다른 경우 애플리케이션은 구성 요소 설치를 위해 병합 모듈에 의존해서는 안 됩니다. 두 소유자가 애플리케이션 또는 모듈을 업데이트하기 위해 조정해야 하기 때문에 애플리케이션 서비스가 어려울 수 있습니다. 병합 모듈을 사용한 모든 애플리케이션을 모르면 애플리케이션 소유자는 업데이트가 다른 애플리케이션과 호환되지 않을 위험 없이 병합 모듈을 업데이트할 수 없습니다. 병합 모듈의 소유자는 이미 병합 모듈을 설치한 Windows Installer 패키지를 업데이트할 직접 메서드가 없습니다.

  • 다른 Windows Installer 설치로 사용자에게 필요한 구성 요소를 제공하는 것이 좋습니다.

관리 설치를 패치하지 마세요.

작업 그룹의 멤버가 애플리케이션을 설치할 수 있도록 네트워크에서 애플리케이션의 원래 Windows Installer 패키지 관리 설치를 제공합니다. 그런 다음 이 관리 이미지의 사용자는 자신의 컴퓨터에 있는 애플리케이션의 로컬 인스턴스에 업데이트를 적용해야 합니다. 이렇게 하면 사용자가 관리 이미지와 동기화 상태를 유지할 수 있습니다. 다음과 같은 이유로 관리자 설치에 업데이트를 적용하지 않는 것이 좋습니다.

  • 사용자가 업데이트를 얻는 데 필요한 다운로드의 크기와 대기 시간은 패치를 다운로드할 때보다 증가합니다. 업데이트된 전체 Windows Installer 패키지 및 원본 파일을 다운로드하고 다시 캐시하고 다시 설치해야 합니다.
  • 사용자는 주문형 설치를 수행할 수 없으며 애플리케이션을 다시 캐시하고 다시 설치할 때까지 업데이트된 관리 설치에서 애플리케이션을 복구할 수 없습니다.
  • 관리자 설치에 패치를 적용하면 패키지에서 디지털 서명이 제거됩니다. 관리자는 패키지에 다시 서명해야 합니다. 디지털 서명 사용에 대한 자세한 내용은 디지털 서명 및 Windows Installer를 참조하세요.
  • 많은 이진 파일 패치는 애플리케이션의 RTM 이미지를 대상으로 하며 이전 파일 버전이 필요합니다. 업데이트된 관리자 설치에서 설치된 애플리케이션의 로컬 인스턴스는 다른 업데이트와 함께 작동하지 않을 수 있습니다. 많은 이진 파일 패치 애플리케이션이 실패할 수 있습니다.
  • 관리자 설치에 패치를 적용하면 원본 파일과 .msi 파일이 업데이트되지만 네트워크 이미지에 업데이트 정보가 표시되지는 않습니다. 사용자는 관리 설치에서 받은 업데이트를 확인할 수 없습니다. 이로 인해 관리 이미지 측에 이미 적용된 업데이트와 사용자 측에 적용된 업데이트 시퀀스를 지정할 수 없습니다.
  • 관리자 설치에 적용된 패치는 제거 가능한 패치가 아닙니다. 이렇게 하면 사용자 컴퓨터에 캐시된 패키지 코드가 관리자 설치의 패키지 코드와 달라지는 것을 방지할 수 있습니다. 사용자 컴퓨터에 캐시된 패키지 코드가 관리자 설치의 패키지 코드와 다른 경우 관리자 설치에서 애플리케이션을 다시 설치한 다음 클라이언트 컴퓨터를 패치합니다.
  • 관리 이미지를 패치하여 소규모 업데이트를 적용하기로 결정한 경우 관리 이미지를 패치하여 소규모 업데이트 적용 항목에 설명된 지침을 따릅니다.

상승된 권한으로 실행할 업데이트를 등록합니다.

Windows Installer 3.0부터 패치가 상승된 권한을 가진 것으로 등록된 후 사용자별 관리 컨텍스트에 설치된 애플리케이션에 패치를 적용할 수 있습니다. 버전 3.0 이전의 Windows Installer 버전을 사용하여 사용자별 관리 컨텍스트에 설치된 애플리케이션에 패치를 적용할 수 없습니다.

MsiPatchSequence 테이블을 사용하여 패치를 시퀀싱합니다.

패키지에 MsiPatchSequence 테이블을 포함하고 패치 시퀀싱 정보를 추가합니다. Windows Installer 버전 3.0부터 설치 프로그램은 여러 패치를 설치할 때 MsiPatchSequence 테이블을 사용하여 최상의 패치 적용 시퀀스를 결정할 수 있습니다. 패치 제품군을 정의하려면 Windows Installer 버전 3.0의 패치 시퀀싱 백서에 설명된 지침을 사용합니다.

  • 가능한 경우 모든 패치를 단일 패치 제품군에 속하는 것으로 지정합니다. 대부분의 경우 단일 패치 제품군은 패치 시퀀스를 지정하는 데 충분한 유연성을 제공합니다. 여러 패치 제품군을 사용하면 제작의 복잡성이 증가합니다. 패치 제품군에 의미 있는 이름을 할당하고 시간이 지남에 따라 증가하는 해당 패치 제품군의 시퀀스 값을 할당합니다. 다중 패치 예에 따라 패치가 발급된 순서대로 패치를 적용합니다.
  • Patchwiz.dll의 PatchSequence 테이블을 사용하여 MsiPatchSequence 테이블의 정보를 생성합니다. Windows Installer 3.0과 함께 릴리스된 PATCHWIZ.DLL 버전은 패치 시퀀싱 정보를 자동으로 생성할 수 있습니다. 새 패치를 추가하는 방법에 대한 자세한 내용은 패치 시퀀스 정보 생성을 참조하세요. 패치 시퀀싱 시나리오에 대한 자세한 내용은 Windows Installer 버전 3.0의 패치 시퀀싱 백서를 참조하세요.

설치 패키지를 철저히 테스트합니다.

Windows Installer 패키지의 올바른 설치, 복구 및 제거를 테스트합니다. 테스트 프로세스를 다음 부분으로 나눌 수 있습니다.

  • 설치 테스트 - 애플리케이션 기능의 가능한 모든 조합으로 설치를 테스트합니다. 관리자 설치, 롤백 설치 및 주문형 설치를 포함한 모든 형식의 설치를 테스트합니다. .msi 파일 클릭, 명령줄 옵션, 제어판에서 설치 등 가능한 모든 설치 방법을 시도해 보세요. 가능한 모든 권한 컨텍스트에서 사용자가 패키지를 설치할 수 있는지 테스트합니다. 가능한 모든 방법으로 패키지를 배포한 후 패키지를 설치해 보세요. 각 테스트에 대해 Windows Installer 로깅을 사용하도록 설정하고 설치 프로그램 로그 및 이벤트 로그에서 발견된 모든 오류를 해결합니다.
  • 사용자 인터페이스 테스트 - 가능한 모든 사용자 인터페이스 수준으로 설치된 패키지를 테스트합니다. 사용자 인터페이스 없이 사용자 인터페이스를 통해 제공된 모든 정보를 사용하여 설치된 패키지를 테스트합니다. 사용자 인터페이스의 접근성을 확인하고 사용자 인터페이스가 다양한 화면 해상도 및 글꼴 크기에서 예상대로 작동하는지 확인합니다.
  • 서비스 및 복구 테스트 - 패키지가 소규모 업데이트, 부 업그레이드 및 주요 업그레이드로 제공되는 패치 및 업그레이드를 처리할 수 있는지 테스트합니다. 패키지를 배포하기 전에 각 형식의 평가판 업데이트를 작성하고 원본 패키지에 적용해 보세요.
  • 제거 테스트 - 패키지를 제거할 때 사용자 컴퓨터에 불필요한 부분이 남지 않고 패키지에 속한 정보만 제거되었는지 확인합니다. 패키지를 제거한 후 테스트 컴퓨터를 다시 부팅하고 일반 시스템 도구 및 기타 표준 애플리케이션의 무결성을 확인합니다. 가능한 모든 권한 컨텍스트에서 사용자가 패키지를 제거할 수 있는지 테스트합니다. 패키지를 제거하는 모든 방법을 테스트하고 .msi 파일을 클릭한 다음 명령줄 옵션을 시도하고 제어판에서 패키지를 제거해 보세요. 각 테스트에 대해 Windows Installer 로깅을 사용하도록 설정하고 설치 프로그램 로그 및 이벤트 로그에서 발견된 모든 오류를 해결합니다.
  • 제품 기능 테스트 - 패키지를 설치, 복구 또는 제거한 후 애플리케이션이 예상대로 작동하는지 확인합니다.

신규 또는 수정된 설치 패키지를 배포하기 전에 모든 유효성 검사 오류를 수정합니다.

새롭거나 수정된 Windows Installer 패키지를 처음 설치하기 전에 패키지 유효성 검사를 실행합니다. 유효성 검사는 Windows Installer 데이터베이스에서 제작 오류의 유효성을 검사합니다. 유효성 검사를 통과하지 못한 패키지를 설치하려고 하면 사용자 시스템이 손상될 수 있습니다.

  • Orca.exe 또는 Msival2.exe를 사용하여 패키지의 유효성을 검사할 수 있습니다. 두 도구 모두 Windows SDK와 함께 제공됩니다. 타사 공급업체도 ICE 유효성 검사 시스템을 제작 환경에 통합할 수 있습니다.
  • SDK와 함께 제공되는 .cub 파일에 포함된 표준 내부 일관성 평가기 - ICE 집합을 사용하거나 ICE 빌드 및 .cub 파일에 추가하여 유효성 검사를 사용자 지정할 수 있습니다.
  • Evalcom2.dll을 사용하여 설치 패키지 및 병합 모듈에 대한 유효성 검사 자동화를 구현할 수 있습니다.

보안 설치를 작성합니다.

설치 중에 보안 환경을 유지하는 데 도움이 되도록 패키지를 개발할 때 다음 지침을 따릅니다.

HANDLE 대신 PMSIHANDLE 사용

PMSIHANDLE 형식 변수는 msi.h에 정의되어 있습니다. PMSIHANDLE 개체가 범위를 벗어나면 설치 프로그램이 닫히므로 애플리케이션에서 PMSIHANDLE 유형을 사용하는 것이 좋습니다. 반면 애플리케이션은 MsiCloseHandle을 호출하여 MSIHANDLE 개체를 닫아야 합니다. PMSIHandle은 API 서명 호환성을 위해 MSIHANDLE에 캐스팅 연산자를 제공합니다.

예를 들어, 다음과 같은 코드를 사용하는 경우:

MSIHANDLE hRec = MsiCreateRecord(3);

다음으로 변경합니다.

PMSIHANDLE hRec = MsiCreateRecord(3);