MSI / WIX - 여러 인스턴스 변환 중에 구성 요소 GUID 지정

Question

Wix 3.5를 사용하면 인스턴스 변환이있는 MSI가 있으면 다른 제품 이름과 동일한 시스템에 소프트웨어를 설치할 수 있습니다. 이렇게하려면 C 조건부에 정의 된 .wxs 파일에 제품 ID 및 이름의 "하드 코딩 된"목록이 있습니다. 그러나 파일과 파일이 아닌 자원을 모두 포함하는 단일 Feature-ComponentRef 정의 만 있습니다.

설치가 잘 작동하지만 인스턴스를 제거하면 다음 두 소스에서 언급 된 동작이 나타냅니다.

http://msdn.microsoft. COM / ko / library / aa367797 (v= vs.85) .aspx

및

http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/multiple-instance-transforms-walkthrough-proposed-simple - wix-to-make-the-easier-td708828.html

특히, 파일이 아닌 파일 리소스 (이 경우 레지스트리 항목)가 제거되지 않음 내 응용 프로그램의 마지막 인스턴스를 저장하지 않습니다. (즉,이 순서로 제거한 경우 : instance1, instance2 및 instance3 - instance3의 비 파일 리소스 만 제거됩니다.

이는이 비 파일 구성 요소에 대해 고유 한 GUID가없는 것과 관련이 있습니다 (파일 구성 요소에 대한 문제가 아님) 와 관련이 있습니다.

그래서, 유효한 접근 방식이 하나의 제품 ID, 이름 및 한 세트의 기능을 갖춘 단일 .wxs 파일을 정의하는지 궁금해하고 있지만 사용자 정의 부트 스트 랩퍼가 제품 및 비 파일 구성 요소에 대한 새로운 GUID를 생성합니다. 그런 다음 런타임에 MSI 데이터베이스에 삽입하십시오. 즉, 제거하거나 업데이트 할 시간이 발생하면 설치된 인스턴스에 대한 레지스트리를 쿼리하고 GUID를 검색합니다.

이는 미리 .wxs에서 하드 코딩 된 경우 런타임에 인스턴스가 생성되며 깨끗하게 제거 할 수 있습니다.

가치가 있습니까? 태우는 것이 모든 것을 더 잘 만들어 낼 것입니까? :)

Answer 1

As of version v3.6.1511.0, there is now a "MultiInstance" attribute for components. This allows a guid to be generated on the fly for each instance as per Josh Rowes suggestion in his post to the WiX mailing list (see the link in the OP). I have tested and this works correctly to cause registry data to be removed when the current instance is uninstalled, and not when the LAST instance is uninstalled.

Answer 2

You don't need to have unique component ID's but you do need to have unique registry keys. Check out:

Authoring Multiple Instances with Instance Transforms

The article mentions:

To keep the nonfile data of each instance isolated, the base package should collect nonfile data into sets of components for each instance. The appropriate components should then be installed based on conditional statements that depend on the instance identifier.

I actually don't know what they are talking about there. I created n-Tier multiple instance installers where all the files were isolated by unique INSTALLDIR ( type 51 custom action at runtime to mutate the destination based on the InstanceID ) and all the registry data was mutated using the InstanceID as part of the path as mentioned in the article. I supported up to Sixteen unique instances with unique configuration data and unique version #'s ( each instance could be serviced via major upgrade apart from the other instances. ) All of this was to support a SaaS deployment model for an nTier application and I never ever had to create components with unique GUIDS and/or Conditional expressions.

The only thing wonky I had to do was on the client side they wanted a Shortcut on the desktop. (The Client supported multiple instances also because a site might have v1.0 in Production and v1.1 in Test )

Because I couldn't mutate the folder name (fixed) and because MSI's ShortCut table doesn't support formattable, I had to write a custom action to author the ShortCut dynamically at install table using the InstanceID into a TEMP table and then MSI created the shortcut for me.