패키지 지원 프레임워크 시작
패키지 지원 프레임워크는 MSIX 컨테이너에서 실행할 수 있도록(코드를 수정하지 않고) 기존 데스크톱 애플리케이션에 픽스를 적용하는 데 도움이 되는 오픈 소스 키트입니다. 패키지 지원 프레임워크는 애플리케이션이 최신 런타임 환경의 모범 사례를 수행하는 데 도움이 됩니다.
이 문서에서는 패키지 지원 프레임워크의 각 구성 요소에 대한 설명과 이를 사용하는 단계별 가이드를 제공합니다.
패키지 지원 프레임워크 내의 내용 이해
패키지 지원 프레임워크에는 실행 파일, 런타임 관리자 DLL 및 런타임 수정 사항 세트가 포함됩니다.
프로세스는 다음과 같습니다.
- 애플리케이션에 적용할 수정 사항을 지정하는 구성 파일을 만듭니다.
- PSF(패키지 지원 프레임워크) 시작 관리자 실행 파일을 가리키도록 패키지를 수정합니다.
사용자가 애플리케이션을 시작할 때 패키지 지원 프레임워크 시작 관리자가 실행되는 첫 번째 실행 파일입니다. 구성 파일을 읽고 런타임 수정 사항과 런타임 관리자 DLL을 애플리케이션 프로세스에 삽입합니다. 런타임 관리자는 애플리케이션이 MSIX 컨테이너 내부에서 실행해야 할 때 수정사항을 적용합니다.
1단계: 패키지된 애플리케이션 호환성 문제 식별
먼저 애플리케이션에 대한 패키지를 만듭니다. 그런 다음, 설치하고, 실행하고, 동작을 관찰합니다. 호환성 문제를 식별하는 데 도움이 되는 오류 메시지가 표시될 수 있습니다. 프로세스 모니터를 사용하여 문제를 식별할 수도 있습니다. 일반적인 문제는 작업 디렉터리 및 프로그램 경로 권한과 관련된 애플리케이션 가정과 관련이 있습니다.
프로세스 모니터를 사용하여 문제 식별
프로세스 모니터 는 앱의 파일 및 레지스트리 작업 및 결과를 관찰하기 위한 강력한 유틸리티입니다. 이렇게 하면 애플리케이션 호환성 문제를 이해하는 데 도움이 될 수 있습니다. 프로세스 모니터를 연 후 애플리케이션 실행 파일의 이벤트만 포함하도록 필터(필터 > 필터...)를 추가합니다.
이벤트 목록이 표시됩니다. 이러한 이벤트의 대부분은 결과 열에 SUCCESS라는 단어가 나타납니다.
필요에 따라 이벤트를 필터링하여 오류만 표시할 수 있습니다.
파일 시스템 액세스 실패가 의심되는 경우 System32/SysWOW64 또는 패키지 파일 경로 아래에 있는 실패한 이벤트를 검색합니다. 필터도 여기에 도움이 될 수 있습니다. 이 목록의 맨 아래에서 시작하여 위쪽으로 스크롤합니다. 이 목록의 맨 아래에 나타나는 오류가 가장 최근에 발생했습니다. "액세스 거부됨" 및 "경로/이름을 찾을 수 없음"과 같은 문자열이 포함된 오류에 주의하고 의심스럽지 않은 항목을 무시합니다. PSFSample에는 두 가지 문제가 있습니다. 다음 이미지에 표시되는 목록에서 이러한 문제를 볼 수 있습니다.
이 이미지에 표시되는 첫 번째 문제에서 애플리케이션은 "C:\Windows\SysWOW64" 경로에 있는 "Config.txt" 파일에서 읽지 못합니다. 애플리케이션이 해당 경로를 직접 참조하려고 할 가능성은 거의 없습니다. 대부분의 경우 상대 경로를 사용하여 해당 파일에서 읽으려고 하며, 기본적으로 "System32/SysWOW64"는 애플리케이션의 작업 디렉터리입니다. 이는 애플리케이션에서 현재 작업 디렉터리가 패키지의 어딘가로 설정될 것으로 예상한다는 것을 시사합니다. appx 내부를 살펴보면 파일이 실행 파일과 동일한 디렉터리에 있는 것을 볼 수 있습니다.
두 번째 문제는 다음 이미지에 나타납니다.
이 문제에서 애플리케이션은 패키지 경로에 .log 파일을 쓰지 못하고 있습니다. 이는 파일 리디렉션 수정이 도움이 될 수 있음을 시사합니다.
2단계: 런타임 수정 찾기
PSF에는 파일 리디렉션 수정과 같이 지금 바로 사용할 수 있는 런타임 수정이 포함되어 있습니다.
파일 리디렉션 수정
파일 리디렉션 수정을 사용하여 MSIX 컨테이너에서 실행되는 애플리케이션에서 액세스할 수 없는 디렉터리에서 데이터를 쓰거나 읽으려는 시도를 리디렉션할 수 있습니다.
예를 들어 애플리케이션이 애플리케이션 실행 파일과 동일한 디렉터리에 있는 로그 파일에 쓰는 경우 파일 리디렉션 수정을 사용하여 로컬 앱 데이터 저장소와 같은 다른 위치에 해당 로그 파일을 만들 수 있습니다.
커뮤니티의 런타임 수정
GitHub 페이지에 대한 커뮤니티 기여 검토해야 합니다. 다른 개발자가 사용자와 비슷한 문제를 해결하고 런타임 수정 사항을 공유했을 수 있습니다.
3단계: 런타임 수정 적용
Windows SDK의 몇 가지 간단한 도구와 다음 단계를 수행하여 기존 런타임 수정 사항을 적용할 수 있습니다.
- 패키지 레이아웃 폴더 만들기
- 패키지 지원 프레임워크 파일 가져오기
- 패키지에 추가
- 패키지 매니페스트 수정
- 구성 파일 만들기
각 작업을 살펴보겠습니다.
패키지 레이아웃 폴더 만들기
.msix(또는 .appx) 파일이 이미 있는 경우 패키지의 준비 영역으로 사용할 레이아웃 폴더로 콘텐츠를 압축을 풀 수 있습니다. MakeAppx 도구를 사용하여 명령 프롬프트에서 이 작업을 수행할 수 있습니다. SDK의 설치 경로에 따라 Windows 10 PC에서 makeappx.exe 도구를 찾을 수 있습니다. x86: C:\Program Files (x86)\Windows Kits\10\bin\x86\makeappx.exe x64: C:\Program Files (x86)\Windows Kits\10\bin\x64\makeappx.exe
makeappx unpack /p PSFSamplePackage_1.0.60.0_AnyCPU_Debug.msix /d PackageContents
이렇게 하면 다음과 같은 항목이 표시됩니다.
시작할 .msix(또는 .appx) 파일이 없는 경우 패키지 폴더와 파일을 처음부터 만들 수 있습니다.
패키지 지원 프레임워크 파일 가져오기
독립 실행형 Nuget 명령줄 도구를 사용하거나 Visual Studio를 통해 PSF Nuget 패키지를 가져올 수 있습니다.
명령줄 도구를 사용하여 패키지 가져오기
다음 위치에서 https://www.nuget.org/downloadsNuget 명령줄 도구를 설치합니다. 그런 다음 Nuget 명령줄에서 다음 명령을 실행합니다.
nuget install Microsoft.PackageSupportFramework
또는 패키지 확장의 이름을 .zip으로 바꾸고 압축을 풉니다. 필요한 모든 파일은 /bin 폴더 아래에 있습니다.
Visual Studio를 사용하여 패키지 가져오기
Visual Studio에서 솔루션 또는 프로젝트 노드를 마우스 오른쪽 단추로 클릭하고 Nuget 패키지 관리 명령 중 하나를 선택합니다. Microsoft.PackageSupportFramework 또는 PSF를 검색하여 Nuget.org 패키지를 찾습니다. 그런 다음 설치합니다.
패키지에 패키지 지원 프레임워크 파일 추가
필요한 32비트 및 64비트 PSF DLL 및 실행 파일을 패키지 디렉터리에 추가합니다. 다음 표를 가이드로 따르세요. 또한 필요한 모든 런타임 수정 사항을 포함하려고 합니다. 이 예제에서는 파일 리디렉션 런타임 수정이 필요합니다.
| 애플리케이션 실행 파일은 x64입니다. | 애플리케이션 실행 파일은 x86입니다. |
|---|---|
| PSF시작 관리자64.exe | PSF시작 관리자32.exe |
| PSFRuntime64.dll | PSFRuntime32.dll |
| PSFRunDll64.exe | PSFRunDll32.exe |
이제 패키지 콘텐츠가 다음과 같이 표시됩니다.
패키지 매니페스트 수정
텍스트 편집기에서 패키지 매니페스트를 연 다음 요소의 Application 특성을 PSF 시작 관리자 실행 파일의 이름으로 설정합니다Executable. 대상 애플리케이션의 아키텍처를 알고 있는 경우 적절한 버전인 PSF시작 관리자32.exe 또는 PSF시작 관리자64.exe를 선택합니다. 그렇지 않은 경우 PSF시작 관리자32.exe는 모든 경우에 작동합니다. 다음은 예입니다.
<Package ...>
...
<Applications>
<Application Id="PSFSample"
Executable="PSFLauncher32.exe"
EntryPoint="Windows.FullTrustApplication">
...
</Application>
</Applications>
</Package>
구성 파일 만들기
파일 이름을 config.json만들고 해당 파일을 패키지의 루트 폴더에 저장합니다. 방금 대체한 실행 파일을 가리키도록 config.json 파일의 선언된 앱 ID를 수정합니다. 프로세스 모니터를 사용하여 얻은 지식을 사용하여 작업 디렉터리를 설정할 뿐만 아니라 파일 리디렉션 수정을 사용하여 패키지 상대 "PSFSampleApp" 디렉터리에서 읽기/쓰기를 .log 파일로 리디렉션할 수도 있습니다.
{
"applications": [
{
"id": "PSFSample",
"executable": "PSFSampleApp/PSFSample.exe",
"workingDirectory": "PSFSampleApp/"
}
],
"processes": [
{
"executable": "PSFSample",
"fixups": [
{
"dll": "FileRedirectionFixup.dll",
"config": {
"redirectedPaths": {
"packageRelative": [
{
"base": "PSFSampleApp/",
"patterns": [
".*\\.log"
]
}
]
}
}
}
]
}
]
}
다음은 config.json 스키마에 대한 가이드입니다.
| 배열 | key | 값 |
|---|---|---|
| 애플리케이션 | id | 패키지 매니페스트에 있는 Id 요소의 Application 특성 값을 사용합니다. |
| 애플리케이션 | executable | 시작하려는 실행 파일에 대한 패키지 상대 경로입니다. 대부분의 경우 패키지를 수정하기 전에 패키지 매니페스트 파일에서 이 값을 가져올 수 있습니다. 요소 특성의 Executable 값입니다 Application . |
| 애플리케이션 | workingDirectory | (선택 사항) 시작하는 애플리케이션의 작업 디렉터리로 사용할 패키지 상대 경로입니다. 이 값을 설정하지 않으면 운영 체제에서 디렉터리를 애플리케이션의 작업 디렉터리로 사용합니다 System32 . |
| 프로세스 | executable | 대부분의 경우 경로 및 파일 확장명을 제거하여 위에서 구성한 이름 executable 입니다. |
| 수정 | dll | 수정에 대한 패키지 상대 경로, 로드할 .msix/.appx입니다. |
| 수정 | config | (선택 사항) fixup dll의 동작 방식을 제어합니다. 이 값의 정확한 형식은 각 수정에서 이 "Blob"을 원하는 대로 해석할 수 있으므로 픽스업 단위로 달라집니다. |
applications, processes및 fixups 키는 배열입니다. 즉, config.json 파일을 사용하여 둘 이상의 애플리케이션, 프로세스 및 수정 DLL을 지정할 수 있습니다.
앱 패키지 및 테스트
다음으로 패키지를 만듭니다.
makeappx pack /d PackageContents /p PSFSamplePackageFixup.msix
그런 다음 서명합니다.
signtool sign /a /v /fd sha256 /f ExportedSigningCertificate.pfx PSFSamplePackageFixup.msix
자세한 내용은 패키지 서명 인증서를 만드는 방법 및 signtool을 사용하여 패키지에 서명하는 방법을 참조하세요.
PowerShell을 사용하여 패키지를 설치합니다.
참고 항목
먼저 패키지를 제거해야 합니다.
powershell Add-AppPackage .\PSFSamplePackageFixup.msix
애플리케이션을 실행하고 런타임 수정이 적용된 동작을 관찰합니다. 필요에 따라 진단 및 패키징 단계를 반복합니다.
패키지 지원 프레임워크가 실행 중인지 확인
런타임 수정이 실행 중인지 여부를 검사 수 있습니다. 이 작업을 수행하는 방법은 작업 관리자를 열고 자세한 내용을 클릭하는 것입니다. 패키지 지원 프레임워크가 적용된 앱을 찾고 앱 세부 정보를 확장하여 자세한 내용을 확인합니다. 패키지 지원 프레임워크가 실행 중인지 확인할 수 있어야 합니다.
추적 수정 사용
패키지된 애플리케이션 호환성 문제를 진단하는 다른 방법은 추적 수정을 사용하는 것입니다. 이 DLL은 PSF에 포함되며 프로세스 모니터와 유사한 앱 동작에 대한 자세한 진단 보기를 제공합니다. 애플리케이션 호환성 문제를 표시하도록 특별히 설계되었습니다. 추적 수정을 사용하려면 패키지에 DLL을 추가하고 config.json에 다음 조각을 추가한 다음 애플리케이션을 패키지하고 설치합니다.
{
"dll": "TraceFixup.dll",
"config": {
"traceLevels": {
"filesystem": "allFailures"
}
}
}
기본적으로 추적 수정은 "예상"으로 간주될 수 있는 오류를 필터링합니다. 예를 들어 애플리케이션은 검사 없이 파일을 무조건 삭제하여 파일이 이미 있는지 확인하고 결과를 무시하려고 할 수 있습니다. 이로 인해 일부 예기치 않은 오류가 필터링될 수 있으므로 위의 예제에서는 파일 시스템 함수에서 모든 오류를 수신하도록 선택합니다. Config.txt 파일에서 읽으려는 시도가 "파일을 찾을 수 없음" 메시지와 함께 실패한다는 것을 알고 있기 때문에 이 작업을 수행합니다. 이는 자주 관찰되고 일반적으로 예기치 않은 것으로 간주되지 않는 오류입니다. 실제로는 예기치 않은 오류에 대해서만 필터링을 시작한 다음, 여전히 식별할 수 없는 문제가 있는 경우 모든 오류로 되돌아가는 것이 가장 좋습니다.
기본적으로 추적 수정의 출력은 연결된 디버거로 전송됩니다. 이 예제에서는 디버거를 연결하지 않고 대신 SysInternals의 DebugView 프로그램을 사용하여 출력을 봅니다. 앱을 실행한 후 이전과 동일한 오류를 볼 수 있으며, 이는 동일한 런타임 수정을 가리키게 됩니다.
런타임 수정 디버그, 확장 또는 만들기
Visual Studio를 사용하여 런타임 수정을 디버그하거나, 런타임 수정을 확장하거나, 처음부터 새로 만들 수 있습니다. 성공하려면 이러한 작업을 수행해야 합니다.
- 패키징 프로젝트 추가
- 런타임 수정을 위한 프로젝트 추가
- PSF 시작 관리자 실행 파일을 시작하는 프로젝트 추가
- 패키징 프로젝트 구성
완료되면 솔루션은 다음과 같이 표시됩니다.
이 예제의 각 프로젝트를 살펴보겠습니다.
| 프로젝트 | 목적 |
|---|---|
| DesktopApplicationPackage | 이 프로젝트는 Windows 애플리케이션 패키징 프로젝트를 기반으로 하며 MSIX 패키지를 출력합니다. |
| Runtimefix | 런타임 수정의 역할을 하는 하나 이상의 대체 함수가 포함된 C++ 동적 연결 라이브러리 프로젝트입니다. |
| PSF시작 관리자 | C++ 빈 프로젝트입니다. 이 프로젝트는 패키지 지원 프레임워크의 런타임 배포 가능 파일을 수집하는 장소입니다. 실행 파일을 출력합니다. 해당 실행 파일은 솔루션을 시작할 때 실행되는 첫 번째 실행 파일입니다. |
| WinFormsDesktopApplication | 이 프로젝트에는 데스크톱 애플리케이션의 소스 코드가 포함되어 있습니다. |
이러한 모든 유형의 프로젝트가 포함된 전체 샘플을 보려면 PSFSample을 참조하세요.
솔루션에서 이러한 각 프로젝트를 만들고 구성하는 단계를 살펴보겠습니다.
패키지 솔루션 만들기
데스크톱 애플리케이션에 대한 솔루션이 아직 없는 경우 Visual Studio에서 새 빈 솔루션을 만듭니다.
가지고 있는 모든 애플리케이션 프로젝트를 추가할 수도 있습니다.
패키징 프로젝트 추가
Windows 애플리케이션 패키징 프로젝트가 아직 없는 경우 프로젝트를 만들어 솔루션에 추가합니다.
Windows 애플리케이션 패키징 프로젝트에 대한 자세한 내용은 Visual Studio를 사용하여 애플리케이션 패키징을 참조하세요.
솔루션 탐색기 패키징 프로젝트를 마우스 오른쪽 단추로 클릭하고 편집을 선택한 다음 프로젝트 파일의 맨 아래에 추가합니다.
<Target Name="PSFRemoveSourceProject" AfterTargets="ExpandProjectReferences" BeforeTargets="_ConvertItems">
<ItemGroup>
<FilteredNonWapProjProjectOutput Include="@(_FilteredNonWapProjProjectOutput)">
<SourceProject Condition="'%(_FilteredNonWapProjProjectOutput.SourceProject)'=='<your runtime fix project name goes here>'" />
</FilteredNonWapProjProjectOutput>
<_FilteredNonWapProjProjectOutput Remove="@(_FilteredNonWapProjProjectOutput)" />
<_FilteredNonWapProjProjectOutput Include="@(FilteredNonWapProjProjectOutput)" />
</ItemGroup>
</Target>
런타임 수정을 위한 프로젝트 추가
솔루션에 C++ DLL(동적 연결 라이브러리) 프로젝트를 추가합니다.
해당 프로젝트를 마우스 오른쪽 단추로 클릭한 다음 속성을 선택합니다.
속성 페이지에서 C++ 언어 표준 필드를 찾은 다음 해당 필드 옆의 드롭다운 목록에서 ISO C++17 표준(/std:c++17) 옵션을 선택합니다.
해당 프로젝트를 마우스 오른쪽 단추로 클릭한 다음 상황에 맞는 메뉴에서 Nuget 패키지 관리 옵션을 선택합니다. 패키지 원본 옵션이 모두 또는 nuget.org 설정되어 있는지 확인합니다.
해당 필드 옆에 있는 설정 아이콘을 클릭합니다.
PSF* Nuget 패키지를 검색한 다음 이 프로젝트에 대해 설치합니다.
기존 런타임 수정을 디버그하거나 확장하려면 이 가이드의 런타임 수정 찾기 섹션에 설명된 지침을 사용하여 얻은 런타임 수정 파일을 추가합니다.
새 수정 사항을 만들려는 경우 아직 이 프로젝트에 아무것도 추가하지 마세요. 이 가이드의 뒷부분에서 이 프로젝트에 올바른 파일을 추가하는 데 도움이 됩니다. 지금은 솔루션을 계속 설정하겠습니다.
PSF 시작 관리자 실행 파일을 시작하는 프로젝트 추가
솔루션에 C++ 빈 프로젝트 프로젝트를 추가합니다.
이전 섹션에서 설명한 것과 동일한 지침을 사용하여 PSF Nuget 패키지를 이 프로젝트에 추가합니다.
프로젝트의 속성 페이지를 열고 일반 설정 페이지에서 애플리케이션의 아키텍처에 따라 대상 이름 속성을 PSFLauncher32PSFLauncher64 설정합니다.
솔루션의 런타임 수정 프로젝트에 프로젝트 참조를 추가합니다.
참조를 마우스 오른쪽 단추로 클릭한 다음 속성 창에서 이러한 값을 적용합니다.
| 속성 | 값 |
|---|---|
| 로컬 복사 | True |
| 로컬 위성 어셈블리 복사 | True |
| 참조 어셈블리 출력 | True |
| 라이브러리 종속성 링크 | False |
| 라이브러리 종속성 입력 연결 | False |
패키징 프로젝트 구성
패키징 프로젝트에서 애플리케이션 폴더를 마우스 오른쪽 단추로 클릭한 다음 참조 추가를 선택합니다.
PSF 시작 관리자 프로젝트 및 데스크톱 애플리케이션 프로젝트를 선택한 다음 확인 단추를 선택합니다.
참고 항목
애플리케이션에 대한 소스 코드가 없는 경우 PSF 시작 관리자 프로젝트를 선택하기만 하면 됩니다. 구성 파일을 만들 때 실행 파일을 참조하는 방법을 보여 줍니다.
애플리케이션 노드에서 PSF 시작 관리자 애플리케이션을 마우스 오른쪽 단추로 클릭한 다음 진입점으로 설정을 선택합니다.
패키징 프로젝트에 명명된 config.json 파일을 추가한 다음, 다음 json 텍스트를 복사하여 파일에 붙여넣습니다. 패키지 작업 속성을 Content로 설정합니다.
{
"applications": [
{
"id": "",
"executable": "",
"workingDirectory": ""
}
],
"processes": [
{
"executable": "",
"fixups": [
{
"dll": "",
"config": {
}
}
]
}
]
}
각 키에 대한 값을 제공합니다. 이 표를 가이드로 참조하세요.
| 배열 | key | 값 |
|---|---|---|
| 애플리케이션 | id | 패키지 매니페스트에 있는 Id 요소의 Application 특성 값을 사용합니다. |
| 애플리케이션 | executable | 시작하려는 실행 파일에 대한 패키지 상대 경로입니다. 대부분의 경우 패키지를 수정하기 전에 패키지 매니페스트 파일에서 이 값을 가져올 수 있습니다. 요소 특성의 Executable 값입니다 Application . |
| 애플리케이션 | workingDirectory | (선택 사항) 시작하는 애플리케이션의 작업 디렉터리로 사용할 패키지 상대 경로입니다. 이 값을 설정하지 않으면 운영 체제에서 디렉터리를 애플리케이션의 작업 디렉터리로 사용합니다 System32 . |
| 프로세스 | executable | 대부분의 경우 경로 및 파일 확장명을 제거하여 위에서 구성한 이름 executable 입니다. |
| 수정 | dll | 로드할 수정 DLL에 대한 패키지 상대 경로입니다. |
| 수정 | config | (선택 사항) 픽스업 DLL의 동작 방식을 제어합니다. 이 값의 정확한 형식은 각 수정에서 이 "Blob"을 원하는 대로 해석할 수 있으므로 픽스업 단위로 달라집니다. |
완료되면 config.json 파일이 다음과 같이 표시됩니다.
{
"applications": [
{
"id": "DesktopApplication",
"executable": "DesktopApplication/WinFormsDesktopApplication.exe",
"workingDirectory": "WinFormsDesktopApplication"
}
],
"processes": [
{
"executable": ".*App.*",
"fixups": [ { "dll": "RuntimeFix.dll" } ]
}
]
}
참고 항목
applications, processes및 fixups 키는 배열입니다. 즉, config.json 파일을 사용하여 둘 이상의 애플리케이션, 프로세스 및 수정 DLL을 지정할 수 있습니다.
런타임 수정 디버그
Visual Studio에서 F5 키를 눌러 디버거를 시작합니다. 가장 먼저 시작되는 것은 PSF 시작 관리자 애플리케이션으로, 대상 데스크톱 애플리케이션을 시작합니다. 대상 데스크톱 애플리케이션을 디버그하려면 디버그 연결> 프로세스를 선택한 다음 애플리케이션 프로세스를 선택하여 데스크톱 애플리케이션 프로세스에 수동으로 연결해야 합니다. 네이티브 런타임 수정 DLL을 사용하여 .NET 애플리케이션의 디버깅을 허용하려면 관리 코드 및 네이티브 코드 형식(혼합 모드 디버깅)을 선택합니다.
이 설정이 완료되면 데스크톱 애플리케이션 코드 및 런타임 수정 프로젝트의 코드 줄 옆에 중단점을 설정할 수 있습니다. 애플리케이션에 대한 소스 코드가 없는 경우 런타임 수정 프로젝트의 코드 줄 옆에만 중단점을 설정할 수 있습니다.
F5 디버깅은 .msix/.appx 패키지에서 설치하는 대신 패키지 레이아웃 폴더 경로에서 느슨한 파일을 배포하여 애플리케이션을 실행하므로 레이아웃 폴더에는 일반적으로 설치된 패키지 폴더와 동일한 보안 제한이 없습니다. 따라서 런타임 수정을 적용하기 전에 패키지 경로 액세스 거부 오류를 재현할 수 없습니다.
이 문제를 해결하려면 F5 느슨한 파일 배포 대신 .msix/.appx 패키지 배포를 사용합니다. .msix/.appx 패키지 파일을 만들려면 위에서 설명한 대로 Windows SDK에서 MakeAppx 유틸리티를 사용합니다. 또는 Visual Studio 내에서 애플리케이션 프로젝트 노드를 마우스 오른쪽 단추로 클릭하고 스토어 -> 앱 패키지 만들기를 선택합니다.
Visual Studio의 또 다른 문제는 디버거에서 시작한 자식 프로세스에 연결하기 위한 기본 제공 지원이 없다는 것입니다. 따라서 시작 후 Visual Studio에서 수동으로 연결해야 하는 대상 애플리케이션의 시작 경로에서 논리를 디버그하기가 어렵습니다.
이 문제를 해결하려면 자식 프로세스 연결을 지원하는 디버거를 사용합니다. 일반적으로 JIT(Just-In-Time) 디버거를 대상 애플리케이션에 연결할 수 없습니다. 대부분의 JIT 기술은 ImageFileExecutionOptions 레지스트리 키를 통해 대상 앱 대신 디버거를 시작하는 것을 포함하기 때문입니다. 그러면 PSF시작 관리자.exe에서 FixupRuntime.dll을 대상 앱에 삽입하는 데 사용하는 우회 메커니즘이 무효화됩니다. Windows용 디버깅 도구에 포함되고 Windows SDK에서 가져온 WinDbg는 자식 프로세스 연결을 지원합니다. 또한 이제 UWP 앱을 직접 시작하고 디버깅할 수도 있습니다.
대상 애플리케이션 시작을 자식 프로세스로 디버그하려면 .WinDbg
windbg.exe -plmPackage PSFSampleWithFixup_1.0.59.0_x86__7s220nvg1hg3m -plmApp PSFSample
프롬프트에서 WinDbg 자식 디버깅을 사용하도록 설정하고 적절한 중단점을 설정합니다.
.childdbg 1
g
(대상 애플리케이션이 시작되고 디버거로 중단될 때까지 실행)
sxe ld fixup.dll
g
(수정 DLL이 로드될 때까지 실행)
bp ...
참고 항목
PLMDebug는 시작 시 앱에 디버거를 연결하는 데 사용할 수도 있으며 Windows용 디버깅 도구에도 포함됩니다. 그러나 WinDbg에서 제공하는 직접 지원보다 사용하기가 더 복잡합니다.
지원
질문이 있으세요? MSIX 기술 커뮤니티 사이트의 패키지 지원 프레임워크 대화 공간에 대해 문의하세요.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기