Windows에서 패키지된 데스크톱 앱을 실행하는 방법 이해

  • 아티클

이 항목에서는 Windows 앱 패키지를 만들 수 있는 데스크톱 앱 유형과 주의해야 할 일부 OS(운영 체제) 동작 및 기타 세부 사항에 대해 설명합니다. 다음 항목에 대한 세부 정보를 살펴보겠습니다(여기서 볼 수 있듯이 특정 동작은 앱 유형에 따라 다름).

데스크톱 앱 유형

만들고 패키지할 수 있는 데스크톱 앱에는 두 가지 유형이 있습니다. Application 요소의 uap10:RuntimeBehavior 특성을 사용하여 앱의 형식을 앱 패키지 매니페스트에 선언합니다.

UWP(유니버설 Windows 플랫폼) 앱(uap10:RuntimeBehavior="windowsApp")도 패키지되지만 이 항목은 이에 관한 것이 아닙니다.

그런 다음 uap10:TrustLevel 특성(동일한 애플리케이션 요소)은 패키지된 앱의 프로세스가 앱 컨테이너 내에서 실행되는지 여부를 결정합니다.

  • 완전 신뢰 앱입니다. 로 선언됨 uap10:TrustLevel="mediumIL"
  • appContainer 앱입니다. 로 선언됨 uap10:TrustLevel="appContainer" 경량 앱 컨테이너에서 실행되므로 파일 시스템 및 레지스트리 가상화를 사용하여 격리됩니다. 자세한 내용은 MSIX appContainer 앱을 참조 하세요.

Important

자세한 내용, 종속성 및 기능 요구 사항은 애플리케이션에서 이러한 두 특성에 대한 설명서를 참조하세요. Windows 10 버전 2004(10.0; 빌드 19041).

패키징 및 앱 컨테이너의 목적

앱을 패키징하는 목적은 런타임에 패키지 ID를 부여하는 것입니다. 특정 Windows 기능에는 패키지 ID가 필요합니다(패키지 ID가 필요한 기능 참조). 위에서 설명한 앱 유형의 모든 조합을 패키지할 수 있으므로 패키지 ID의 이점을 누릴 수 있습니다.

그러나 appContainer 앱의 주요 목표는 다른 앱과의 호환성을 기본 최대한 시스템 상태와 앱 상태를 분리하는 것입니다. Windows는 런타임에 파일 시스템 및 레지스트리에 적용되는 특정 변경 내용을 검색하고 리디렉션하여 이를 수행합니다(가상화라고 함). 섹션이 가상화된 앱에만 적용되는 경우를 설명합니다.

설치

앱 패키지는 시스템 전체 대신 사용자 단위로 설치됩니다. 새 컴퓨터의 새 패키지에 대한 기본 위치는 app_name.exe라는 실행 파일과 함께 아래에 C:\Program Files\WindowsApps\<package_full_name>있습니다. 그러나 패키지는 다른 위치에 설치할 수 있습니다. 예를 들어 Visual Studio의 시작 명령은 프로젝트의 $(OutDir).를 사용합니다.

배포 후 패키지 파일은 읽기 전용으로 표시되고 운영 체제(OS)에 의해 크게 잠깁니다. Windows는 해당 파일이 변조된 경우 앱을 시작하지 못하도록 차단합니다.

위치 C:\Program Files\WindowsApps 는 PackageVolume이라고 합니다. 이 위치는 Windows에서 제공하는 기본 PackageVolume입니다. 그러나 모든 드라이브 및 경로에 PackageVolume을 만들 수 있습니다. 또한 모든 패키지가 PackageVolume에 설치되는 것은 아닙니다(위의 Visual Studio 예제 참조).

파일 시스템

OS는 폴더 위치에 따라 패키지된 데스크톱 앱에 대해 다양한 수준의 파일 시스템 작업을 지원합니다.

디바이스에 최적화

파일이 중복되지 않도록 하기 위해(디스크 스토리지 공간을 최적화하고 파일을 다운로드할 때 필요한 대역폭을 줄이기 위해) OS는 파일의 단일 스토리지 및 하드 연결을 활용합니다. 사용자가 MSIX 패키지를 AppxManifest.xml 다운로드할 때 패키지에 포함된 데이터가 이전 패키지 설치의 디스크에 이미 있는지 여부를 확인하는 데 사용됩니다. 여러 MSIX 패키지에 동일한 파일이 있는 경우 OS는 공유 파일을 디스크에 한 번만 저장하고 두 패키지에서 공유 파일로 하드 링크를 만듭니다. 파일이 64Kb 블록으로 다운로드되므로 다운로드되는 파일의 백분율이 디스크에 있더라도 다른 증분만 다운로드됩니다. 따라서 다운로드에 사용되는 대역폭이 줄어듭니다.

Windows 10 버전 1903 이상의 AppData 작업

이 섹션은 가상화된 앱에만 적용됩니다.

사용자 AppData 폴더에 새로 만든 모든 파일 및 폴더(예: C:\Users\<user_name>\AppData)는 사용자별 개인, 앱별 위치에 기록되지만 런타임에 병합되어 실제 AppData 위치에 표시됩니다. 이를 통해 앱 자체에서만 사용되는 아티팩트에서 어느 정도 상태를 분리할 수 있습니다. 을 사용하면 앱이 제거되면 시스템에서 해당 파일을 클린 수 있습니다.

앱과 OS 간에 더 높은 수준의 호환성과 대화형 작업을 제공하기 위해 사용자 폴더 아래의 AppData 기존 파일을 수정할 수 있습니다. OS가 앱에서 변경한 모든 파일 또는 디렉터리를 인식하므로 시스템 "썩기"가 줄어듭니다. 또한 상태 분리를 사용하면 패키지된 데스크톱 앱이 동일한 앱의 패키지되지 않은 버전이 중단된 위치를 선택할 수 있습니다. OS는 사용자의 AppData 폴더에 대한 VFS(가상 파일 시스템) 폴더를 지원하지 않습니다.

Windows 10 버전 1903 이전의 OS에서 AppData 작업

이 섹션은 가상화된 앱에만 적용됩니다.

만들기, 삭제 및 업데이트를 포함하여 사용자의 AppData 폴더에 대한 C:\Users\<user_name>\AppData모든 쓰기는 앱별 개인 위치에 쓰기 시 복사됩니다. 이렇게 하면 패키지된 앱이 실제로 프라이빗 복사본을 수정할 때 실제 AppData 앱을 편집하고 있다는 환상이 생깁니다. 이러한 방식으로 쓰기를 리디렉션하면 시스템에서 앱에서 수행한 모든 파일 수정 내용을 추적할 수 있습니다. 이렇게 하면 앱이 제거될 때 시스템에서 해당 파일을 클린 시스템 "rot"를 줄이고 사용자에게 더 나은 앱 제거 환경을 제공할 수 있습니다.

작업 디렉터리 및 애플리케이션 파일

이 섹션은 가상화된 앱에만 적용됩니다.

리디렉션 AppData외에도 Windows의 잘 알려진 폴더(System32Program Files (x86)등)는 앱 패키지의 해당 디렉터리와 동적으로 병합됩니다. 각 패키지에는 루트에 이름이 지정된 VFS 폴더가 포함되어 있습니다. 디렉터리의 모든 디렉터리 또는 파일 VFS 읽기는 런타임에 해당 네이티브 해당 항목과 병합됩니다. 예를 들어 앱은 앱 패키지의 일부로 포함될 C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\vc10.dll 수 있지만 파일이 설치되어 있는 C:\Windows\System32\vc10.dll것처럼 보입니다. 이 기본 파일이 비패키지 위치에 있는 것으로 예상되는 데스크톱 앱과의 호환성을 제공합니다.

앱 패키지에서 파일/폴더에 대한 쓰기는 허용되지 않습니다. 패키지에 포함되지 않은 파일과 폴더에 대한 쓰기는 OS에서 무시되며, 사용자에게 권한이 있어야만 허용됩니다.

일반적인 파일 시스템 작업

다음 간단한 참조 표에서는 일반적인 파일 시스템 작업과 OS에서 이러한 작업을 처리하는 방법을 보여줍니다.

연산 결과 예시
잘 알려진 Windows 파일 또는 폴더를 읽거나 열거합니다. 로컬 시스템에 대응하는 C:\Program Files\<package_full_name>\VFS\<well_known_folder> 동적 병합입니다. 읽기 C:\Windows\System32 는 의 내용과 C:\Windows\System32 그 내용을 반환합니다 C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86.
아래에 쓰기 AppData Windows 10, 버전 1903 이상: 다음 디렉터리에 만들어진 새 파일 및 폴더는 사용자별, 패키지별 프라이빗 위치로 리디렉션됩니다.
  • 로컬
  • Local\Microsoft
  • 로밍
  • Roaming\Microsoft
  • Roaming\Microsoft\Windows\Start Menu\Programs
파일 열기 명령에 대한 응답으로, OS는 먼저 사용자별, 패키지별 위치에서 파일을 엽니다. 해당 위치가 없으면 OS는 실제 AppData 위치에서 파일을 열려고 시도합니다. 파일이 실제 AppData 위치에서 열리면 해당 파일에 대한 가상화가 발생하지 않습니다. 사용자에게 권한이 있는 경우 아래 AppData 의 파일 삭제가 허용됩니다.

Windows 10 버전 1903 이전 버전: 사용자별 앱별 위치에 쓰기에 복사합니다.

 AppData 는 일반적으로 .입니다 C:\Users\<user_name>\AppData.
패키지 내부에 쓰기 허용되지 않음. 패키지가 읽기 전용입니다. 아래 C:\Program Files\WindowsApps\<package_full_name> 의 쓰기는 허용되지 않습니다.
패키지 외부에 쓰기 사용자에게 권한이 있는 경우 허용됩니다. 패키지에 C:\Windows\System32\foo.dll 포함되어 C:\Program Files\WindowsApps\<package_full_name>\VFS\SystemX86\foo.dll있지 않고 사용자에게 사용 권한이 있는 경우 쓰기가 허용됩니다.

패키지된 VFS 위치

이 섹션은 가상화된 앱에만 적용됩니다.

이 표에서는 패키지의 일부로 배송되는 파일이 앱 시스템에 오버레이되는 위치를 보여 줍니다. 실제로 앱은 내부 리디렉션된 위치에 있는 경우 이러한 파일이 나열된 시스템 위치에 C:\Program Files\WindowsApps\<package_full_name>\VFS있음을 인식합니다. FOLDERID 위치는 KNOWNFOLDERID 상수에서 가져옵니다.

시스템 위치 리디렉션된 위치([<package_root>]\VFS 아래) 아키텍처에서 유효
FOLDERID_SystemX86 SystemX86 x86, amd64
FOLDERID_System SystemX64 amd64
FOLDERID_ProgramFilesX86 ProgramFilesX86 x86, amd6
FOLDERID_ProgramFilesX64 ProgramFilesX64 amd64
FOLDERID_ProgramFilesCommonX86 ProgramFilesCommonX86 x86, amd64
FOLDERID_ProgramFilesCommonX64 ProgramFilesCommonX64 amd64
FOLDERID_Windows Windows x86, amd64
FOLDERID_ProgramData 일반적인 AppData x86, amd64
FOLDERID_System\catroot AppVSystem32Catroot x86, amd64
FOLDERID_System\catroot2 AppVSystem32Catroot2 x86, amd64
FOLDERID_System\drivers\etc AppVSystem32DriversEtc x86, amd64
FOLDERID_System\driverstore AppVSystem32Driverstore x86, amd64
FOLDERID_System\logfiles AppVSystem32Logfiles x86, amd64
FOLDERID_System\spool AppVSystem32Spool x86, amd64

등록

이 섹션(및 해당 하위 섹션)은 가상화된 앱에만 적용됩니다.

앱 패키지에는 실제 레지스트리에서 HKLM\Software에 해당하는 논리적(가상) 역할을 하는 파일이 포함되어 registry.dat 있습니다. 런타임에 가상 레지스트리는 해당 하이브의 콘텐츠를 네이티브 시스템 하이브에 병합하여 둘 다의 단일 보기를 제공합니다. 예를 들어 단일 키 Foo가 포함된 경우 registry.dat 런타임 시 HKLM\Software의 읽기에도 Foo가 포함된 것으로 표시됩니다(모든 네이티브 시스템 키 외에).

MSIX 패키지에는 HKLM 및 HKCU 키가 포함되어 있지만 다르게 처리됩니다. HKLM\Software 아래의 키만 패키지의 일부이며, HKCU 또는 레지스트리의 다른 부분에 있는 키는 포함되지 않습니다. 패키지의 키 또는 값에 대한 쓰기는 허용되지 않습니다. 패키지에 포함되지 않은 키 또는 값에 대한 쓰기는 사용자에게 권한이 있어야만 허용됩니다.

HKCU 아래의 모든 쓰기는 사용자별 개인, 앱별 위치에 쓰기에 복사됩니다. 일반적으로 제거자는 로그아웃된 사용자의 레지스트리 데이터가 탑재되지 않고 사용할 수 없으므로 HKEY_CURRENT_USER 클린 수 없습니다.

모든 쓰기는 패키지 업그레이드 중에 유지되며 앱이 완전히 제거된 경우에만 삭제됩니다.

일반적인 레지스트리 작업

이 섹션의 대부분은 가상화된 앱에만 적용됩니다.

다음 간단한 참조 표에서는 일반적인 레지스트리 작업과 OS에서 이러한 작업을 처리하는 방법을 보여줍니다.

연산 결과 예시
HKLM\Software 읽기 또는 열거 로컬 시스템에 대응하는 패키지 하이브의 동적 병합입니다. 단일 키 Foo가 포함된 경우 registry.dat 런타임에 HKLM\Software 읽기에 HKLM\Software 및 HKLM\Software\Foo의 내용이 모두 표시됩니다.
HKCU에서 쓰기 사용자별 앱별 개인 위치에 쓰기에 복사됩니다. 파일의 경우와 동일합니다 AppData .
패키지 내에 씁니다. 허용되지 않음. 패키지가 읽기 전용입니다. 패키지 하이브에 해당 키/값이 있는 경우 HKLM\Software 아래의 쓰기는 허용되지 않습니다.
패키지 외부에 쓰기 OS에서 무시됩니다. 사용자에게 권한이 있는 경우 허용됩니다. 패키지 하이브에 해당 키/값이 없고 사용자에게 올바른 액세스 권한이 있는 한 HKLM\Software의 쓰기가 허용됩니다.

제거

이 섹션은 가상화된 앱에만 적용됩니다.

사용자가 패키지를 제거하면 패키지 프로세스 중에 캡처된 리디렉션된 쓰기 또는 레지스트리뿐만 아니라 아래에 C:\Program Files\WindowsApps\<package_full_name> 있는 모든 파일 및 AppData 폴더가 제거됩니다.