패키징 개요

패키징은 앱을 설치, 업데이트 및 Windows 통합하는 방법을 정의합니다. WinUI 3 앱은 기본적으로 패키지되지만 기존 Win32 애플리케이션과 같은 많은 데스크톱 앱은 패키지되지 않은 상태로 실행됩니다. 패키지된 앱 또는 패키지되지 않은 앱 중에서 선택하는 것은 사용할 수 있는 기능, 사용하는 배포 모델 및 고객이 얻는 전반적인 환경에 영향을 줍니다.

메모

새 WinUI 3 앱을 빌드하시겠습니까? 이미 기본적으로 패키지되어 있습니다. 아래 지침은 일반적으로 기존 앱을 포팅하거나, 엔터프라이즈 머신에 배포하거나, 원래 패키지되지 않은 앱에 Windows 기능을 추가할 때 명시적 선택을 해야 하는 개발자에게 가장 적합합니다.

앱 패키징이 중요한 이유

패키지 앱은 기본 설치 모델, 자동 업데이트 및 백그라운드 작업, 알림, 상황에 맞는 메뉴 확장, 공유 대상 및 기타 확장성 지점을 포함하여 패키지 ID가 필요한 Windows 기능에 액세스할 수 있습니다. 패키징은 또한 Microsoft Store 및 엔터프라이즈 배포 도구와 같은 채널을 통해 보다 깔끔한 배포, 안정적인 업데이트 및 간소화된 배포를 보장하는 데 도움이 됩니다.

패키지 ID가 필요한 기능

패키지 ID가 있는 애플리케이션에서만 이러한 Windows 기능이 작동합니다. 이는 전체 MSIX 패키징 또는 외부 위치로 패키징(Sparse 패키징)에 해당합니다.

특징 설명
백그라운드 작업 앱이 포그라운드에 없을 때(예: 데이터 동기화, 다운로드 처리 또는 시스템 이벤트 응답) 코드를 실행합니다.
Windows AI API(Phi Silica, OCR 등) 로컬 언어 모델, 텍스트 인식 및 이미지 분석과 같은 디바이스 내 AI 기능에 액세스합니다.
푸시 알림 (WNS) Windows Notification Service를 통해 클라우드 서비스에서 실시간 알림을 받습니다.
공유 대상 시스템 공유 시트를 통해 다른 앱의 콘텐츠를 직접 귀하의 앱으로 공유할 수 있도록 사용자에게 권한을 부여하십시오.
사용자 지정 상황에 맞는 메뉴 확장 파일 탐색기 및 기타 셸 화면의 오른쪽 클릭 메뉴에 앱의 작업을 추가합니다.
파일 형식 및 프로토콜 연결 특정 파일 형식 또는 URI 프로토콜(예: yourapp://)에 대한 처리기로 앱을 등록합니다.
시작 작업 사용자가 Windows 로그인할 때 자동으로 앱을 시작합니다.
App Services 다른 앱이 호출할 수 있는 백그라운드 서비스를 노출하여 앱 간 통신을 사용하도록 설정합니다.

팁 (조언)

Windows API를 호출할 때 E_ILLEGAL_METHOD_CALL 또는 APPMODEL_ERROR_NO_PACKAGE 오류가 발생하는 경우, 이는 패키지 ID가 필요함을 나타냅니다. 가장 낮은 마찰 수정으로 외부 위치(스파스 패키징)가 있는 패키징 을 참조하세요.

자세한 내용은 패키지 ID가 필요한 기능을 참조하세요.

한눈에 모델 패키징

모델 패키지 ID 설치 관리자 자격 기준을 충족하는 매장 적합한 대상
패키지(MSIX) ✅ 예 MSIX가 설치 관리자를 대체합니다. ✅ 예(MSIX 제출) 새 앱, 스토어 게시, 엔터프라이즈 MDM
외부 위치로 패키징 ✅ 예 기존 인스톨러 ✅ 예(MSI/EXE 제출) 자체 설치 관리자가 있는 기존 앱, 독립 소프트웨어 공급업체(ISV)
패키지되지 않음 ❌ 아니요 MSI 또는 EXE 설치 관리자(또한: 비 스토어 배포용 XCopy 또는 스크립트) ✅ 예(MSI/EXE 제출 - 자동 설치 지원이 있는 MSI 또는 EXE 설치 관리자 필요) 광범위한 Win32 배포, 내부 도구

패키지된 앱(MSIX)

패키지된 앱은 MSIX를 사용하며 많은 Windows 확장성 지점에 필요한 패키지 ID가 있습니다. 패키지 ID를 사용하면 Windows 플랫폼 API의 호출자를 안정적으로 식별할 수 있으므로 이러한 기능이 이에 따라 달라집니다.

  • 패키지된 앱은 일반적으로 파일 시스템 및 레지스트리 가상화를 사용하는 간단한 앱 컨테이너에서 실행됩니다(레거시 앱 및 MSIX AppContainer 앱의 경우 AppContainer 참조).
  • 필요한 경우 앱 컨테이너에서 실행 되지 않도록 앱을 구성할 수도 있습니다.
  • MSIX는 패키징 및 설치 모두에 사용됩니다( MSIX란?참조).

외부 위치로 패키징(스파스 패키징)

외부 위치( 스파스 패키지라고도 함)를 사용하여 패키징하면 설치 관리자, 이진 위치 또는 업데이트 프로세스를 변경하지 않고도 기존 앱과 함께 작은 ID 패키지를 등록할 수 있습니다. Windows 10 버전 2004(빌드 19041)에서 도입되었습니다.

이는 자체 설치 관리자(NSIS, WiX, InstallShield 등)를 통해 제공되고 MSIX로 대체하지 않으려는 기존 Win32/WPF/WinForms 앱의 가장 좋은 장소입니다. 경량 ID 패키지를 등록하면, 기존 이진 파일의 위치는 그대로 유지되며, 패키지 ID로 제어되는 Windows 기능의 전체 세트를 사용할 수 있습니다.

역량 MSIX 외부 위치
설치 관리자를 대체합니다. 예 No
패키지 내의 바이너리 파일 예 아니요(외부)
자격 기준을 충족하는 매장 예(MSIX 제출) 예(MSI/EXE 제출)
패키지 ID 예 예
업데이트 메커니즘 MSIX 업데이트 기존의 메커니즘

전체 안내: 외부 위치로 패키징하여 패키지 ID 부여하기

패키지되지 않은 앱

패키지되지 않은 앱은 MSIX를 사용하지 않으며 패키지 ID가 없으므로 위에 나열된 기능에 액세스할 수 없습니다.

  • API 표면, 파일 시스템 접근, 레지스트리 접근, 권한 상승 및 프로세스 모델 측면에서 전혀 제한을 받지 않습니다.
  • 설치 및 업데이트는 .exe, .msi 사용자 지정 설치 관리자, ClickOnce 또는 xcopy 배포에 의존합니다.

패키지 해제를 커밋하기 전에 위의 기능 테이블을 로드맵에 대해 확인합니다. 알림, 백그라운드 작업 또는 AI API가 다가올 경우, 패키지로 시작하는 것을 고려하십시오.

시나리오에서 선택

시나리오 권장 모델 세부 정보
Microsoft Store에 게시하는 인디 개발자 패키지화된 (MSIX) 형식 권장 MSIX는 스토어 관리형 업데이트, 차등 다운로드 및 제거를 가능하게 하는 권장 경로입니다. WinUI 3 앱은 기본적으로 패키지됩니다. 코드 서명은 스토어에서 무료로 처리됩니다. 패키지된 앱 배포 →

기존 MSI 또는 EXE 설치 관리자가 있는 Win32 앱은 MSI/EXE 제출 경로를 통해 스토어에 게시할 수도 있지만 스토어는 기존 사용자에게 업데이트를 푸시하지 않습니다. 업데이트는 앱 또는 설치 관리자가 처리해야 합니다.
Intune 또는 구성 관리자를 통해 배포된 엔터프라이즈 앱 기존 설치 프로그램의 패키지 위치 또는 외부 위치 새 앱은 MSIX를 사용해야 합니다. 자체 설치 관리자가 있는 기존 앱은 외부 위치에서 패키지를 사용할 수 있습니다. 코드 서명: 자체 서명된 인증서(Intune, 그룹 정책 또는 구성 관리자 통해 신뢰할 수 있음) 또는 Azure 아티팩트 서명(이전의 신뢰할 수 있는 서명) 사용합니다. 패키지된 앱 배포 →
ISV는 자체 설치 관리자를 사용하여 직접 다운로드를 전달합니다. 외부 위치로 패키징 기존 설치 관리자와 함께 경량 ID 패키지를 등록합니다. 코드 서명: 비 스토어 배포에는 CA에서 신뢰할 수 있는 인증서가 필요합니다. Azure 아티팩트 서명(이전의 신뢰할 수 있는 서명) 권장되는 저렴한 옵션입니다. → 패키지 ID 부여

또는 MSI/EXE 제출 경로를 통해 기존 설치 관리자를 스토어에 제출합니다.
내부 도구 또는 개발자 유틸리티 Unpackaged 빌드 및 배포가 가장 간단합니다. Windows 앱 SDK NuGet을 통해 작동하지만 일부 기능은 사용할 수 없습니다.

팁 (조언)

코드 서명 비용에 대해 잘 모르시나요? Microsoft Store를 통해 MSIX 패키지를 게시하면 최종 사용자 신뢰를 위해 인증서를 별도로 얻거나 관리할 필요가 없습니다. Microsoft가 패키지를 다시 서명합니다. 스토어를 통해 Win32 MSI/EXE 설치 관리자 게시하려면 Microsoft 신뢰할 수 있는 루트 프로그램의 CA에 인증서를 연결해야 합니다; 자체 서명은 허용되지 않습니다. 다른 배포 경로의 경우 서명 방법은 배포 컨텍스트에 따라 달라집니다. 엔터프라이즈 환경은 디바이스 관리를 통해 자체 서명된 인증서를 신뢰할 수 있지만, 더 광범위한 비 스토어 배포에는 일반적으로 CA에서 신뢰할 수 있는 코드 서명 솔루션이 필요합니다. Azure 아티팩트 서명(이전의 신뢰할 수 있는 서명) 하드웨어 토큰이 필요하지 않은 Microsoft 권장 옵션( 참조)입니다.

프레임워크 종속 배포 및 자체 포함 배포

패키징 모델과는 별도로 Windows 앱 SDK 사용하는 앱은 런타임 종속성을 수행하는 방법을 선택합니다.

  • Framework 종속: Windows 앱 SDK 런타임을 사용자의 컴퓨터에 설치해야 합니다. 앱의 공간이 더 작아집니다. 또한 런타임이 이미 설치되어 있거나 자동으로 설치되는 것에 의존합니다.
  • 자체 포함: 모든 Windows 앱 SDK 이진 파일이 앱과 함께 제공됩니다. 더 큰 공간; 외부 런타임 요구 사항이 없습니다. 잠긴 엔터프라이즈 환경에 적합합니다.

→ 자체 포함 앱 배포

MSIX 시작하기

Win32 데스크톱 앱(클래스 데스크톱 앱이라고도 함) 또는 Windows Presentation Foundation(WPF) 및 Windows Forms(WinForms)를 포함한 .NET 앱을 빌드하는 경우 MSIX를 사용하여 앱을 패키지하고 배포할 수 있습니다.

기타 설치 기술

관련 콘텐츠

  • Last updated on