현재 MSI Windows Installer를 통해 배포 된 제품을 만들고 있습니다. 이 제품은 WiX Burn과 같은 부트 스트 래퍼/체인너를 사용하거나 InstallShield와 같은 저작 도구를 사용하여 MSI 내부의 다른 양식을 사용하여 고객이 통합하고 있습니다.MSI 대신 MSM을 사용할 때의 제한/이점은 무엇입니까?
이 시나리오를 염두에두고 MSI를 유지하는 대신 병합 모듈 (Merge Modules : MSM)을 사용하는 데있어 제한 및/또는 이점이 무엇인지 알고 싶었고 요즘은 MSI를 유지하기 위해 요즘 권장되는 방법이 무엇인지 알고 싶었습니다. .
종이 병합 모듈은 괜찮지 만 현실 세계에서는 결함이 발견되기 전에 많은 설정으로 병합 될 수 있으므로 업데이트하기가 쉽지 않으므로 오류가 발생하기 쉽습니다. 결과적으로 병합 모듈은 모두에 권장하지 않습니다. 부트 스트 래퍼 또는 배치 파일을 통해 배치 프로세스로 실행될 수 있으며 쉽게 업데이트 될 수있는 단일 MSI을 선호합니다. 이렇게하면 일반적으로 직관적이지 않은 모든 종류의 문제를 피할 수 있습니다.
는 그 모듈 공유 파일에 대한 의미있는 파일 시스템의 위치에 설치 진정으로 공유 파일과 변화 자주을 것을 잘 작동 병합 추가 할. 이들은 일반적으로 OS-runtimes입니다. 이러한 병합 모듈은 일반적으로 많이 테스트되고 잘 작동합니다. 그러나 종종 사람들은 자주 변경되는 파일에 대해 병합 모듈을 사용하고 결국 다른 형식으로 다른 위치에 설치하게됩니다. 이런 종류의 사용은 총 난장판이고 엄청난 낭비입니다.
모든 말로하면 - 병합 모듈을 통해 여러 설정으로 파일 세트를 반복적으로 변경하지 않고 고급 릴리스 관리가 필요할 때 실제로 병합 모듈을 성공적으로 사용했습니다. 그렇더라도 업데이트를 필요로하는 파일 몇 개를 가지고 잠시 후에 버전 문제가 발생했습니다. 프로젝트를 다른 사람에게 맡기고 잘못된 병합 모듈을 사용하면 사소한 오류가 발생합니다. 또한 작은 병합 모듈 버그 수정으로 인해 모든 설정을 다시 빌드해야하는 경험이있었습니다. 모든 설정은 다시 품질 보증을 통과해야했습니다. 아주 단단한 커플 링으로 인해 매우 실망 스럽습니다. 당신의 요구 사항은 간단하고 당신이 파일들을 공유하는 거대한 멀티 제품 출시 프로젝트를 복용하지 않는 경우
는 MSI 대신 의 MSM를 사용합니다. 모듈 업데이트 또는 디자인 문제를 병합하기 때문에 많은 설정에서 동일한 오류가 발생할 위험이 적고 이해하기 쉽고 일반적으로 다루어야 할 작업이 적습니다.
답변 해 주셔서 감사합니다! 버전 문제에 대한 참고 사항이 있습니까? 내 제품이 많은 주요 업그레이드를 사용하기 때문에 나는 단지 알고 싶습니다 ... –
병합 모듈에는 문제가 없습니다. 그들의 주요 용도 (언급되지 않은)는 공유입니다. 여러 개의 MSI 파일에 동일한 공유 파일 집합이 필요하면 공유 규칙을 유지하기 위해 동일한 구성 요소 집합이 필요합니다. 또는 MSI 빌드에서 클라이언트와 같은 파일 (예 : Microsoft)을 사용하도록 클라이언트에 파일을 제공하는 경우 병합 모듈을 제공하십시오. 이것이 MS와 다른 공급 업체가 병합 모듈을 재배포하여 모든 사람이 MSI를 구축하고 파일 공유 재난없이 동일한 시스템에 설치할 수있는 이유 중 하나입니다. 또한 병합 모듈이 MSI 파일의 공통 UI로 사용되는 것을 보았습니다. 하지만 주로 공유 파일이 올바르게 사용되는지 확인하는 것이 필수적입니다. 공유 파일을 잘못 사용하여 발생하는 재난이 병합 모듈을 사용하는 데 어려움이 있다는 사실을 경험을 통해 알 수 있습니다. 또한 범용이며 MSI 파일을 작성하는 모든 도구에 포함될 수 있습니다.
패치, 버전 또는 수정이 어려운 병합 모듈을 찾지 못했습니다. 주요 업그레이드는 문제가되지 않습니다.내가 본 유일한 잠재적 인 문제는 패치 (.msp) 빌드를 만드는 동안 병합 모듈의 모든 바이너리를 다시 빌드하는 프로세스를 빌드하는 것입니다. 하나의 바이너리 만 수정해야하지만 모두 컴파일하면 패치 프로세스 (두 개의 MSI 파일과 그 내용 사이의 델타)가 패치에 포함되어야한다고 알려주도록 버전과 내부가 충분히 변경 될 수 있습니다 변경되었지만 실제로 문제가되는 경우이 문제를 피할 수 있습니다.
감사의 시간을내어 주셔서 감사합니다 @ PhilDW! 그래서 다른 고객이 통합하는 제품을 가지고 있다고 생각하면 MSM을 사용하는 것이 좋은 방법일까요? 그렇다면 우리 제품 만 배포하여 MSM을 구축 할 수 있을까요? 아니면이 경우 MSI에 직접 가야합니까? 또한 MSM을 사용하는 경우 MSI에 한계가 있는지 알고 있습니까? 예를 들어 사용자 지정 작업은 어떻습니까? –
일반적으로 대부분 동의합니다. 나는 여전히 병합 모듈이 OS 런타임 및 공유 파일의 적절한 위치에서 실제로 공유되는 파일에 가장 잘 작동 함을 발견했습니다. 종종 사람들은 자주 변경되는 파일에 대해 병합 모듈을 사용하고 결국 다른 형식으로 다른 위치에 설치하게됩니다. 총 난장판과 낭비 된 노력. 좋은 디자인으로 병합 모듈은 합리적으로 괜찮습니다. –
MSI 파일에 대한 MSM 제한 사항은 사과와 오렌지입니다. MSM은 MSI 파일을 만들 때만 사용할 수 있습니다. 다른 방법으로는 콘텐츠를 설치할 수 없습니다. 당신은 내가 알 수없는 MSM 파일에 대한 어떤 가정을 가지고 있습니다. 그래서 그 질문은 의아해하고 있습니다. MSM 파일을 클라이언트에 제공하면 MSI 파일을 작성하는 데만 사용할 수 있습니다. Microsoft가 ATL, C++ 등의 Dll 지원을 포함하는 설정을 빌드하기 위해 사람들을위한 병합 모듈을 배포하는 것과 마찬가지로 이해하기 쉽습니다. 그래서 우리는 모두 올바르게 설치하고 적절하게 공유합니다. – PhilDW
토론이 도움이되기를 바랍니다. 고객에게 그들이 원하는 것을 물어보십시오. 그리고 모든 고객을 위해 공유 위치에 실제 독립형 제품을 설치하거나 각 제품의 설치 폴더에 몇 개의 파일을 추가하는 것과는 매우 다른 점을 기억하십시오. –
@Glytzhkof의 토론이 정말 도움이되었습니다. 나는 모든 충고를 할 것이다. 감사! –