WiX : 주요 업그레이드에서 어떤 파일이 덮어 쓰이지 않는지 알려주는 방법이 있습니까?

Question

MSX, C# 사용자 지정 작업 프로그램, UI, 부트 스트 래퍼를 많이 사용하는 WiX의 큰 프로그램이 있습니다. 이름이 있습니다.

주요 업그레이드를 실행하면 이전 버전이 지워지지 않는 문제가 있습니다. 즉, 버전 1.0.0.x에서 1.1.0.x로 업그레이드하는 경우 프로그램 & 기능은 두 버전이 모두 시스템에 설치되어 있음을 보여줍니다.

이것은 많은 문제가있는 일반적인 문제입니다. 그들 중 누구도 저를 위해 일하고 있지 않습니다. - 이것에 관한 게시물이 있다면, 시도해 보았습니다.

주요 업그레이드에서 구성 요소간에 일대일 관계가 있다고 들었습니다. 즉, 제거 된 모든 구성 요소에 대해 다른 구성 요소를 추가해야합니다. 그것이 일대일 관계가 아니라면 이전 버전이 제거되지 않는 것입니다. 오래된 구성 요소가 여전히 매달려 있기 때문입니다.

걸려있는 구성 요소를 확인하는 방법이 있습니까? 로그 파일 같은 거요? MSI가 어떤 문제를 겪고 있는지 판단 할 수 있다면 문제 해결에 훨씬 더 능동적 일 수 있습니다.

---

편집 :

나는 문제가 해결되지 않지만, 씨 URMAN의 제안 덕분에 내가 바른 길에있을 수 있습니다.

레지스트리 키를 만들었지 만 아무 것도하지 않는 것 같습니다. 그러나, 나는 단어 "허용 안 함"내 제거 로그를 검색했고, 나는이 문구를 발견 9 회 :

PROPERTY CHANGE: Adding INSTALLLEVEL property. It's value is '1'. 

: 또한

Disallowing uninstallation of component: {GUID-HERE} since another client exists. 

,이 구절은 "금지"문구의 각 그룹 앞에 표시

이것은 나에게 뭔가를 제공합니다. 그러나 언급 한 GUID를 찾을 수 없습니다! 그들은 내 솔루션에 없으며 레지스트리에서 검색 할 수 있습니다. 레지스트리 검색 외에도 특정 GUID의 구성 요소를 확인하는 방법 (Windows 7 32 비트)이 있습니까?

Answer 1

주요 업그레이드의 구성 요소간에 일대일 관계가 있다고 들었습니다. 즉, 제거 된 모든 구성 요소에 대해 다른 구성 요소를 추가해야합니다. 그것이 일대일 관계가 아니라면 이전 버전이 제거되지 않는 것입니다. 오래된 구성 요소가 여전히 매달려 있기 때문입니다.

이것은 사실이 아닙니다. 작은 업그레이드의 경우는 사실이며, 특정 구성 (늦은 RemoveExistingProducts을 포함하는 경우)의 주요 업그레이드는 까다 롭습니다. 그러나 사용자가 이전 버전을 제거한 다음 새 버전을 설치하는 것과 같은 일반적인 업그레이드 기능이 더 많이 사용됩니다. 가정을 확인하여 시작하십시오. 적절한 업그레이드 (ProductVersion 및 Product Code를 변경했으며 업그레이드 테이블에 올바른 항목이 있는지 확인)가 올바른지 확인하십시오. 그런 다음 진단하십시오.

어떻게 진행되고 있는지 파악하는 가장 좋은 방법은 무엇입니까? 내 경험상 로그 파일이 최선의 방법입니다. 이전 버전은 간접적으로 제거되므로 명령 행을 사용하여 로그 할 수 없습니다. 따라서 대신 다음 레지스트리 값을 만들거나 설정하여 Logging policy을 설정하십시오. 나중에 설정을 되돌리려면 제거하십시오.로그인
데이터 : : 그런 다음 주요 업그레이드를 실행

을 voicewarmup을 해당 로그 파일을 찾을 수)

HKEY_LOCAL_MACHINE \ 소프트웨어 \ 정책은 마이크로 소프트 \ 윈도우 \ 설치
값 (REG_SZ) \ % temp %에 생성되었습니다. (% temp %를 미리 정리하면 더 쉽게 찾을 수 있고 날짜순으로 정렬하는 것이 좋습니다.) 특히 설치 제거 (ProductVersion 또는 UPGRADINGPRODUCTCODE로 식별 할 수 있음)를 살펴보십시오. 같은 구성 요소 GUID가 포함 된 구성 요소 제거를 허용하지 않습니다..

GUID가 있으면 구성 요소의 구성 요소와 현재 상태를 파악해야합니다. Orca와 같은 도구를 사용하여 빌드 된 .msi 파일을 수동으로 검사하여 구성 요소를 찾을 수 있지만 모든 클라이언트에 대해 알려주는 도구는 거의 없습니다. 내 고용주의 제품에는 InstallShield Msi Sleuth라는 도우미 도구가 포함되어 있으며,이 도구는 구성 요소 코드를 참조하여 설치된 모든 제품을 나열하거나 MsiEnumProducts 또는 Installer.ComponentClients에서 직접 빌드 할 수 있습니다. Windows Installer는 GUID를 압축되거나 압축 된 형식으로 저장하기 때문에 레지스트리를 직접 검색 할 수 없습니다.

그런 다음 "이유"를 식별하는 것이 어려운 부분 일 수 있습니다. 또는 특히 비 릴리스 버전의 제품을 본 테스트 컴퓨터에서만이 DLL을 발견 한 경우 잘못된 공유 DLL 참조 횟수만큼 간단 할 수 있습니다.

마이너 업그레이드 또는 소규모 업데이트에만 관련된 관련 대안으로 EnforceUpgradeComponentRules Policy을 설정할 수 있습니다. 이것은 어쨌든 Windows Installer가 최선을 다할 수 있도록 허용하기보다는 문제가 발생했을 때 문제를 밝혀내는 데 도움이됩니다.