# InstallShield 대체와 기존 설치본 전환

권고안은 WiX로 MSI를 작성하고 Burn으로 필수 런타임과 MSI를 묶은 전체 설치 EXE를 만드는 것이다. 사용자에게는 기존처럼 EXE 설치 파일을 제공할 수 있다. WiX 채택과 도구 버전·이용 조건은 구현 시작 전에 확정한다.

## 대체 도구 검토

| 선택지 | 장점 | 이 프로젝트의 주요 과제 |
| --- | --- | --- |
| WiX MSI + Burn EXE | MSI 업그레이드 체계 활용, 설치 정의의 코드 관리, 런타임 묶음 설치 | 기존 구성요소·레지스트리·사용자 지정 작업 이관 |
| Inno Setup EXE | 스크립트 기반 제작, 저장소에 IRX SDK 설치 경험 존재 | 기존 MSI 제거 및 새 설치 실패 복구를 별도 설계 |
| MSIX | Store 관리 업데이트와 패키지 배포 기능 | 설치 경로, CAD 연동, 데이터 저장, 자체 업데이트 구조 검증 |

WiX와 Burn의 기능은 [WiX 공식 설명](https://docs.firegiant.com/wix/)을 참고한다. IRX SDK 설치기는 본 프로그램과 설치 범위·목적이 다르므로 그대로 재사용한다고 가정하지 않는다.

## 산출물과 설치 경로

- `EG-BIM.msi`: 앱 파일, 레지스트리, 바로가기 등 설치 정의.
- `Setup.exe`와 MSI·분할 CAB·필수 런타임 폴더: 대용량 제품의 기본 전체 설치 레이아웃. 단일 파일이 가능한 경우에만 `FullSetup.exe`로 묶는다.
- `Patch.msp`: 지원하는 기준 버전에서 목표 버전으로 갱신하는 Windows Installer 패치. 세부 정책은 [버전별 패치](08-version-patching.md)를 따른다.
- `WebSetup.exe`: 서버의 고정된 MSI·CAB·런타임을 받아 설치하는 네트워크 진입점. 사용자별 목표 릴리스 선택은 배포 서버/업데이터와 연계한다.

총 용량이 2GB를 넘을 때는 외부 CAB 분할을 사용하며 단일 CAB·개별 파일·서명 EXE의 한계를 별도로 검사한다. 자세한 출력 프로필과 제한 처리는 [릴리스 생성 설계](../code-design/05-release-pipeline.md)를 따른다.

신규 설치 기본 경로는 `%ProgramFiles%\Baron\EG-BIM`으로 하고 기존 설치본은 실제 등록 경로를 탐지해 유지한다. 사용자 지정 경로를 무조건 기본 경로로 변경하지 않는다. 설치 경로와 사용자 데이터 경로는 분리하며 일반 사용자에게 프로그램 폴더의 광범위한 쓰기 권한을 부여하지 않는다.

## 기존 제거 작업의 위험

`Setup.rul`의 `CleanAfterUninstall`은 앱 폴더 일부, AppData의 설정·도구 폴더, 공용 데이터 일부, 사용자·시스템 레지스트리를 삭제한다. CAD 파일 확장자 `.dwg`, `.dxf` 등의 키도 삭제 대상이다.

`.ism`의 `UnintallAction`은 `REMOVE="ALL"` 조건으로 연결되어 있어 업그레이드 중 구버전 제거에서도 실행될 수 있다. 새 설치기에서 제거 동작을 개선하더라도 이미 설치된 구버전의 제거 동작이 자동으로 바뀌지는 않는다.

현재 설정의 RemoveExistingProducts는 InstallInitialize보다 앞에 있다. 새 설치기는 기존 제거와 신규 설치의 실행 순서 및 실패 복구를 다시 설계한다. WiX의 `afterInstallInitialize` 방식은 검토 후보지만 사용자 지정 파일·레지스트리 삭제까지 자동 복구된다고 가정하지 않는다. [WiX MajorUpgrade 동작](https://docs.firegiant.com/wix/schema/wxs/majorupgrade/)

## 전환 절차

1. 지원할 기존 버전별 ProductCode·UpgradeCode·설치 경로·필수 런타임을 수집한다.
2. 실행 중인 앱과 관련 도구를 확인하고, 작업 저장 후 종료하도록 안내한다.
3. 사용자 설정·CUI·사용자 추가 리소스를 제거 대상 밖에 백업한다. 백업 성공을 검증하기 전에는 기존 제품을 제거하지 않는다.
4. 새 설치 파일과 런타임을 모두 확보하고 서명·해시·디스크 공간을 검증한다.
5. 검증된 업그레이드 순서로 기존 제품 제거와 새 제품 설치를 수행한다.
6. 호환되는 사용자 설정을 복원하고, 도면 열기·저장·출력·인증·플러그인 실행을 확인한다.
7. 설치 완료 후 상태 확인까지 성공한 경우에만 백업 정리를 허용한다.

현재 백업·복원 코드는 일부 예외를 내부에서 처리하고 성공 여부를 호출자에게 명확히 전달하지 않는다. 전환용 경로에는 결과 상태와 실패 로그를 추가한다. 백업을 다운로드 임시 폴더 정리와 함께 삭제하지 않도록 수명도 분리한다.

PC 전체 설치와 HKCU·AppData의 사용자별 데이터를 구분한다. 다른 관리자 계정으로 UAC를 승인한 경우에도 원래 사용자의 설정을 다뤄야 하며, 여러 사용자의 프로필은 각 소유자와 복원 시점을 정의한다.

## MSI 식별자와 복구

기존 UpgradeCode를 계승하는 Major Upgrade를 우선 검토하되, 실제 배포본의 아키텍처·언어·제품 식별자와 함께 시험한다. 새 Major Upgrade의 ProductCode와 패키지 식별자는 적절히 갱신한다. GUID 복사만으로 호환성이 보장되지는 않는다.

위 Major Upgrade 권고는 최초 설치기 전환과 설치 구조가 달라지는 업데이트에 적용한다. 이후 모든 릴리스의 ProductCode를 변경하지 않는다. 같은 제품 계열의 MSP Minor Upgrade는 ProductCode와 구성요소 규칙을 유지하며 ProductVersion을 올리는 방향으로 설계한다. 전체 설치 파일의 갱신 방식도 해당 패치 계열과 일치시킨다. [Windows Installer 업데이트 구분](https://learn.microsoft.com/en-us/windows/win32/msi/patching-and-upgrades)

Windows Installer는 제품 버전 비교에 앞의 세 필드를 사용한다. 네 번째 숫자만 올려 새 업데이트를 구분하는 설계를 피하고, 제품 버전과 빌드 식별자의 매핑을 정한다. [ProductVersion 규칙](https://learn.microsoft.com/en-us/windows/win32/msi/productversion)

설치 중 실패 복구와 설치 완료 후 이전 릴리스 복귀는 별도 기능이다. 데이터 형식 변경으로 복귀가 불가능하면 더 높은 제품 버전의 수정 릴리스를 배포한다. 새 빌드에서 InstallShield 사용을 중단하더라도 최초 전환 시 기존 설치본의 등록된 제거 엔진을 호출할 수는 있다.