51 lines
5.2 KiB
Markdown
51 lines
5.2 KiB
Markdown
# Microsoft Store 배포 방식
|
|
|
|
현재 EG-BIM에는 자체 업데이터와 PC 전체 설치 구조가 있으므로 MSI·EXE 등록 경로를 우선 검토한다. Store 배포에 MSIX가 반드시 필요한 것은 아니다.
|
|
|
|
## 두 경로의 차이
|
|
|
|
| 항목 | MSI·EXE 등록 | MSIX 제출 |
|
|
| --- | --- | --- |
|
|
| 파일 보관 | 자체 HTTPS 저장소 | Microsoft 호스팅 |
|
|
| 서명 | 게시자가 설치 파일과 포함 PE 파일 서명 | Store가 패키지 서명 처리 |
|
|
| 업데이트 | 자체 업데이터 담당 | Store 관리 |
|
|
| 지정 테스터 배포 | 자체 서버에서 구현 | Package Flights 지원 |
|
|
| 비율 배포 | 자체 서버에서 구현 | Store 점진 업데이트 지원 |
|
|
| 현재 앱 적용 | 기존 경로와 설치 기능을 유지하는 방향 | 경로·레지스트리·CAD 연동·업데이터 검증 필요 |
|
|
|
|
[Microsoft 배포 방식 비교](https://learn.microsoft.com/en-us/windows/apps/distribute-through-store/how-to-distribute-your-win32-app-through-microsoft-store)
|
|
|
|
## MSI 및 EXE 제출 조건
|
|
|
|
1. 버전별 고정 HTTPS 다운로드 URL을 제출한다.
|
|
2. 제출한 URL의 파일은 이후 덮어쓰지 않는다. 새 파일은 새 URL로 등록한다.
|
|
3. 무인 설치를 지원한다. 설치 UI는 표시하지 않지만 UAC 표시는 허용된다.
|
|
4. 설치 중 본체나 런타임을 추가 다운로드하지 않는 전체 설치 파일이어야 한다.
|
|
5. 설치 파일과 포함된 PE 파일에 신뢰 가능한 코드 서명이 있어야 한다.
|
|
|
|
Store용은 필요한 오프라인 런타임과 MSI를 포함한 단일 `FullSetup.exe` 등 제출 요건을 만족하는 파일로 만든다. 대용량으로 단일 파일의 생성·서명 제한을 넘으면 이 경로를 사용 가능하다고 간주하지 않는다. 자체 배포용 분할 CAB 폴더나 작은 `WebSetup.exe`가 그대로 Store 제출을 대신하는 것은 아니다. 현재 `.ism`의 웹 설치형 선행 조건은 그대로 이관하지 않고 실제 의존성을 정리한다. [공식 패키지 요구사항](https://learn.microsoft.com/en-us/windows/apps/publish/publish-your-app/msi/app-package-requirements), [출력 프로필과 용량 검사](../code-design/05-release-pipeline.md)
|
|
|
|
## 자체 배포와 함께 운영
|
|
|
|
자체 사이트와 Store에서 같은 검증 완료 전체 설치 파일을 사용할 수 있다. Store에는 일반 사용자에게 공개할 릴리스만 등록한다. 최초 설치 후의 업데이트는 자체 서버가 그룹별로 제어한다.
|
|
|
|
Store MSI·EXE 등록은 자체 서버의 4단계 배포 정책을 대신하지 않는다. 자체 서버의 배포 중지와 Store의 새 사용자 설치 중지는 별도 조치다. 두 경로의 공개 상태와 설치 패키지 버전을 함께 기록해야 한다.
|
|
|
|
Store 등록·심사 시점과 자체 배포 시점을 조정하고, Store의 오래된 전체 설치 파일로 시작한 사용자가 최신 허용 릴리스로 이동하는 경로도 검증한다.
|
|
|
|
Store의 신규 설치용 등록 파일은 항상 전체 MSI·EXE로 유지한다. MSP를 신규 설치 파일 대신 제출하지 않는다. 설치 이후 자체 업데이터는 [버전별 패치 정책](08-version-patching.md)에 따라 호환되는 MSP를 적용할 수 있으며, 해당 버전의 전체 설치본과 패치 적용 결과가 같은 관리 상태가 되는지 검증한다.
|
|
|
|
## MSIX로 전환할 경우
|
|
|
|
Package Flights에 개발자·1차·2차 테스트 그룹을 구성하고 정식 제출을 일반 사용자 단계에 연결할 수 있다. Microsoft 계정으로 테스터를 등록하고 Flight도 인증 절차를 거친다. 초기 앱 제출 게시 후 Flight를 구성하는 흐름을 고려한다. [Package Flights](https://learn.microsoft.com/en-us/windows/apps/publish/package-flights)
|
|
|
|
Store 점진 배포는 기존 사용자의 업데이트에 대한 비율 제어다. 최초 설치에도 같은 비율 제한이 적용된다고 가정하지 않는다. 중지는 이미 업데이트된 앱을 이전 버전으로 되돌리지 않으므로 수정 릴리스를 준비해야 한다. [점진 배포](https://learn.microsoft.com/en-us/windows/apps/publish/gradual-package-rollout)
|
|
|
|
MSIX 전환 시에는 고정 설치 경로, 설치 위치 쓰기, 외부 CAD·플러그인·COM 연동, 사용자 설정 이동, 런타임을 검증한다. 현재 구조만으로 불가능하다고 판정한 것은 아니다. [MSIX 준비 사항](https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-prepare)
|
|
|
|
## SmartScreen과 설치 경로
|
|
|
|
Microsoft 공식 안내는 Store를 통한 MSI·EXE 설치 과정에는 SmartScreen 경고가 없고 UAC는 나타날 수 있다고 구분한다. 이는 Microsoft가 해당 EXE를 재서명한다는 의미가 아니다. Store에서 제공하는 MSIX 패키지 서명 처리와 다르다.
|
|
|
|
같은 EXE를 자체 웹사이트에서 내려받으면 일반 다운로드의 SmartScreen 평판 판단을 받는다. Store 등록만으로 자체 배포 URL까지 경고 면제가 되지는 않는다. Store 설치 후 자체 업데이터가 내려받는 파일도 별도의 서명·검증이 필요하며 Store 설치 경로의 효과를 그대로 가정하지 않는다. [코드 서명 및 배포 경로 비교](https://learn.microsoft.com/en-us/windows/apps/package-and-deploy/code-signing-options)
|