머신에서 빌드한 다음, Windows 샌드박스에서 앱을 실행하고 자동화합니다.
winapp run . --on sandbox --detach
winapp ui inspect --on sandbox -a MyApp
winapp ui invoke --on sandbox SubmitButton -a MyApp
run를 앱 이름 또는 MyApp에서 출력된 게스트 PID로 바꾸세요.
--detach 는 다음 명령이 앱을 검사할 수 있도록 실행 후 반환합니다. 없으면 run 앱이 종료되기를 기다립니다. 샌드박스는 명령과 다시 빌드 간에 계속 실행됩니다.
시작하기 전에
- 하드웨어 가상화를 사용하도록 설정된 지원되는 버전에서 Windows 11 24H2 이상 버전을 사용합니다.
- 게스트 winapp은 x64 및 Arm64를 지원합니다. x86 앱은 실행 및 x86 종속성 일치에 대한 게스트 지원이 필요합니다. x64 런타임은 x86 앱을 충족하지 않습니다.
- 실제 입력 및 화면 캡처를 위해 호스트 세션을 잠금 해제된 상태로 유지합니다.
Windows 기능 켜기 또는 끄기에서 Windows샌드박스를 사용하도록 설정하거나 관리자 터미널에서 실행합니다.
dism.exe /Online /Enable-Feature /FeatureName:Containers-DisposableClientVM /All /NoRestart
작업을 저장하고 준비가 되면 Windows 다시 시작합니다. 그런 다음 시작 메뉴에서 Windows 샌드박스를 열고 클라이언트 설치 또는 업데이트를 완료합니다. winapp은 기능을 사용하도록 설정하거나, 클라이언트를 설치하거나, 권한 상승을 요청하거나, Windows 다시 시작하지 않습니다. 필수 구성 요소가 없으면 설치 지침에 따라 중지됩니다. 관찰된 보류 중인 Windows 다시 시작은 별도로 보고됩니다.
콜드 연결 또는 다시 연결은 잠시 집중할 수 있습니다. 연결되면 winapp은 활성화하지 않고 자체 클라이언트 창을 화면 끄기 상태로 유지합니다. 직접 연 샌드박스 창이 제자리에 남아 있습니다.
Important
빌드는 여전히 컴퓨터에서 실행됩니다. 프로젝트 평가, 복원 및 컴파일은 서로 독립적이지 않습니다.
--on sandbox 에서는 신뢰할 수 없는 프로젝트를 안전하게 빌드할 수 없습니다.
하나의 샌드박스는 하나의 공유 환경입니다. 내부 앱 및 워크플로는 사용자, 데스크톱, 레지스트리, 패키지, 런타임 및 네트워크 액세스를 공유합니다. 그들은 서로를 관찰하거나 방해 할 수 있습니다. 상호 신뢰할 수 없는 워크플로에 별도의 컴퓨터를 사용합니다.
Windows 한 번에 하나의 샌드박스를 허용합니다. winapp은 직접 연 인스턴스를 포함하여 실행 중인 인스턴스를 다시 사용합니다. 이를 준비하면 winapp의 공유 부트스트랩 폴더, 게스트 에이전트, 개발자 모드 및 인바운드 방화벽 규칙이 추가됩니다. winapp은 채택된 인스턴스를 중지하거나 관련 없는 앱을 제거하지 않습니다. 암묵적인 호스트 대체는 없습니다: Sandbox 실행을 요청한 명령은 그곳에서 실행되거나 실패합니다.
실행 및 다시 빌드
winapp run .\MyApp.csproj --on sandbox --detach --json
winapp run .\publish --on sandbox --detach
winapp run . --on sandbox --clean --detach
--arch, --no-build, --framework, --property, --configuration 빌드 옵션 및 --no-restore와 같은 빌드 옵션은 호스트에 적용됩니다. 등록, 시작 및 디버깅은 게스트에서 발생합니다. 앱이 컴퓨터에 등록되지 않았습니다.
| 옵션 | 샌드박스의 효과 |
|---|---|
--detach |
종료를 기다리지 않고 시작 후 반환 |
--no-launch |
시작하지 않고 배포 및 등록 |
--clean |
이 배포를 다시 설치하고 애플리케이션 데이터 지우기 |
--unregister-on-exit |
앱이 종료된 후 이 패키지 등록 제거 |
--with-alias |
전달된 스트림으로 해당 게스트 실행용 별칭 시작 |
--debug-output |
게스트 디버그 출력 스트리밍; 패키지된 앱만 |
패키지되지 않은 앱은 배포된 폴더에서 실행 파일을 시작합니다. 등록할 패키지가 없습니다.
--debug-output 는 패키지되지 않은 샌드박스 실행에 대해 거부됩니다.
다시 실행하면 변경된 파일이 전송되고 빌드 출력에서 삭제된 파일이 제거됩니다.
애플리케이션 데이터는 요청 --clean하지 않는 한 유지됩니다. 불완전한 배포가 시작되지 않습니다. 다시 시도하면 게스트 복사본이 다시 작성됩니다. winapp을 준비하는 동안 빌드 파일이 변경되면 빌드를 완료하고 다시 시도합니다.
웜 UI 명령은 샌드박스 준비 메시지를 반복하지 않고 결과만 보고합니다. 샌드박스 시작 및 연결 복구는 여전히 진행 상황을 보고합니다. 연결 시간 정보 및 진단 세부 정보에는 --quiet을(를) 사용하고, --json 및 --verbose는 진행률 표시를 숨깁니다.
JSON 실행에는 게스트 프로세스 ID 및 대상 범위가 포함됩니다.
{
"ProcessId": 4212,
"Sandbox": true,
"ProcessScope": "sandbox",
"UiTargetArgs": "--on sandbox -a 4212",
"ExecutionTarget": {
"Kind": "sandbox",
"Id": "default",
"Architecture": "arm64",
"Epoch": "..."
}
}
이러한 필드는 별도의 문서가 아니라 실행 결과의 추가 필드입니다. 앱을 검사할 때 전체 winapp ui inspect --on sandbox -a 4212 값을 복사합니다: UiTargetArgs.
샌드박스를 다시 생성한 후에는 PID와 창 핸들을 다시 확인해야 합니다. 이들은 호스트나 이후의 게스트가 아니라 해당 샌드박스 세대에만 속합니다.
분리형 앱 및 에이전트의 수명 주기
게스트 에이전트가 중지되면 에이전트 복구 중을 포함하여 분리된 비패키지형 앱이 종료됩니다.
명령 사이에 사라지면 --detach와 함께 다시 실행하고 해당 UI 대상을 다시 찾습니다.
분리하는 대신 앱이 종료되기를 기다리면 앱이 종료되는 것을 확인할 수 있지만, 그렇다고 해서 앱이 에이전트 손실 후에도 계속 실행되는 것은 아닙니다. 패키지된 앱은 에이전트의 프로세스 수명이 아닌 Windows 활성화를 사용합니다. 샌드박스를 닫거나 다시 시작하면 샌드박스 내부의 모든 앱이 종료됩니다.
공유 런타임
winapp은 앱의 패키지 종속성, Windows 앱 SDK 요구 사항 및 *.runtimeconfig.json 시작하기 전에 확인합니다. 호스트 캐시를 사용하거나 필요한 페이로드를 다운로드한 다음, 사용자 머신이 아니라 게스트에서 누락된 지원 런타임을 설치합니다.
패키지 요구 사항에는 게시자, 버전 및 아키텍처가 포함됩니다. 공유 .NET 런타임 선택은 애플리케이션의 구성된 롤 포워드 정책 및 아키텍처를 적용합니다. 동일한 주 버전에서 최신 런타임이 작동된다고 가정하지 마세요.
프레임워크, 런타임 구성 또는 종속성을 지원하지 못할 경우 명령을 시작하기 전에 명시적으로 실패하고 요구 사항을 식별합니다. 해당 오류에 대한 조치를 따르세요. 프로젝트에서 지원하는 경우 자체 포함 게시는 해당 공유 런타임에 대한 필요성을 제거합니다. 관련 없는 패키지 종속성은 제거하지 않습니다.
UI 자동화
winapp ui list-windows --on sandbox
winapp ui inspect --on sandbox -a MyApp
winapp ui invoke --on sandbox SubmitButton -a MyApp
winapp ui screenshot --on sandbox -a MyApp -o .\result.png
모든 ui 동사는 --on sandbox을(를) 취합니다. 앱 이름, PID, 창 핸들 및 선택기는 게스트 내부에서 해석됩니다. 앱을 대상으로 하는 명령에는 -a/--app 또는 -w/--window를 사용하세요. winapp은 마지막으로 실행한 앱을 추정하지 않습니다.
--on sandbox을 생략하면 대신 호스트 데스크톱이 선택됩니다.
실제 입력 및 기록에는 축소되지 않은 연결된 샌드박스 클라이언트가 필요합니다. 입력할 수 없는 경우에도 읽기 전용 검사가 작동할 수 있습니다. winapp은 활성화 없이 최소화된 자체 클라이언트를 복원할 수 있습니다. 최소화된 수동으로 열린 클라이언트는 사용자가 복원해야 합니다. 재연결 후 입력을 사용할 수 없으면, 명령은 입력을 전달했다고 주장하는 대신 실패합니다. 오류에서 다시 연결 명령을 사용하고 다시 시도합니다.
샌드박스를 시작하거나 다시 연결하지 않고 데스크톱 준비 상태를 확인하는 데 사용합니다 winapp target snapshot sandbox --json . 인식된 터미널 오류 창은 원격 데스크톱으로 계산되지 않습니다. winapp이 여전히 연결 중이거나 검사할 수 없어 선택한 데스크톱을 확인할 수 없는 경우 준비 상태를 사용할 수 없게 됩니다. 기다렸다가 다시 시도하십시오. 여러 원격 데스크톱은 여전히 모호할 수 있습니다. 스냅샷은 창을 닫거나 오류를 해결하지 않습니다.
선택기, 입력 메서드 및 어설션에 대한 UI 자동화 를 참조하세요.
샌드박스에서 UI 워크플로 조정
서로 협력하는 명령에는 하나의 WINAPP_UI_WORKFLOW_ID를 사용하고, 각 독립적인 워크플로마다 서로 다른 값을 사용합니다.
호출할 때마다 설정하세요. 특히 에이전트가 각 도구 호출마다 새로운 셸을 시작하는 경우에는 더욱 그렇습니다. winapp은 해시된 샌드박스 생성 특정 ID를 전달합니다. 원시 호스트 값이 게스트로 전송되지 않습니다.
예를 들어 동일한 값을 사용하여 두 터미널에서 레코드를 기록하고 상호 작용합니다. 각 새 워크플로에 대한 새 값을 선택합니다.
터미널 1:
$env:WINAPP_UI_WORKFLOW_ID = 'myapp-checkout-01'
winapp ui record --on sandbox -a MyApp --duration-sec 20 --frames -o .\checkout.mp4
레코딩이 실행되는 동안 터미널 2:
$env:WINAPP_UI_WORKFLOW_ID = 'myapp-checkout-01'
winapp ui invoke --on sandbox SubmitButton -a MyApp
$env:WINAPP_UI_WORKFLOW_ID = 'myapp-checkout-01'
winapp ui inspect --on sandbox -a MyApp
모두 녹음 및 동작이 완료되면:
$env:WINAPP_UI_WORKFLOW_ID = 'myapp-checkout-01'
winapp ui yield --on sandbox
명명된 워크플로는 마지막 명령 이후 4초 동안 UI 턴을 유지합니다. yield 는 즉시 릴리스합니다. ID가 없으면 각 명령은 완료 시 자신의 턴을 반납합니다.
따라서 no-ID 기록은 해당 기간 동안 다른 데스크톱 변경 워크플로를 차단합니다.
읽기 전용 검사는 기다리지 않습니다. 호스트 및 게스트 UI 회전은 별개입니다.
일시 중지한 후 다시 검사하고 필요한 메뉴 또는 대화 상자를 다시 엽니다. 다른 워크플로에서 게스트 데스크톱을 사용했을 수 있습니다. 협조적 회전은 앱을 서로 격리하지 않습니다.
스크린샷 및 녹화
앱 창에 캡처를 사용하거나 target 셸 및 설치 관리자 대화 상자를 포함하여 전체 네이티브 게스트 데스크톱에 대한 캡처를 사용합니다ui.
winapp ui record --on sandbox -a MyApp --duration-sec 10 --frames -o .\app.mp4
winapp target screenshot sandbox -o .\sandbox.png
winapp target record sandbox --duration-sec 20 --frames -o .\sandbox.mp4
출력은 -o에 전달되며, 을 생략하는 경우에도 마찬가지입니다. 스크린샷의 기본값은 screenshot.png이며, 녹음/녹화에는 recording-<timestamp>-<guid>.mp4를 사용합니다.
녹화의 경우 --frames, JPEG, <output-name>.frames, 및 manifest.json가 포함된 frames.ndjson 디렉터리도 제공합니다. 결과 보고서에 호스트 경로를 표시합니다. 대상 녹화는 게스트에서 수행되며, 녹화가 종료되고 전달이 완료되면 호스트 파일을 사용할 수 있게 됩니다.
target screenshot 는 창을 활성화하지 않고 게스트의 UI 턴을 기다립니다.
호스트 샌드박스 창의 제목 표시줄과 테두리는 제외됩니다. 해당 PNG는 크기가 조정되지 않습니다. 게스트 화면 원본 (0,0)을 사용하면 이미지 좌표는 좌표 입력 동사(예: ui drag 또는 ui touch --at. --on sandbox)에서 직접 사용할 수 있습니다.
음수 원점이 있는 데스크톱에 보고된 원점을 추가합니다.
coordinates.sourceBounds을 사용하여 coordinates.contentRect 및 --json를 읽습니다. 둘 다 실제 픽셀과 배타적인 오른쪽/아래쪽 경계를 사용합니다.
대상 기록은 JSON 및 프레임 매니페스트에서 동일한 필드를 보고합니다. MP4 및 JPEG 프레임은 크기 조정 및 인코더 패딩을 포함하여 --max-edge 매핑을 공유합니다. 이미지 픽셀 (x,y)을 매핑하려면 먼저 contentRect 밖의 점을 제외한 다음, 각 소스 좌표를 sourceStart + floor((pixel - contentStart + 0.5) * sourceSize / contentSize)로 계산합니다.
다운 스케일링은 정밀도를 잃습니다. 정확한 좌표가 중요한 경우 네이티브 PNG를 사용합니다. 게스트 데스크톱의 경계를 변경하면 변경 전의 프레임만 보존하고 프레임 매니페스트를 부분적으로 표시하여 기록을 display_changed중지합니다.
기존 MP4 또는 .frames와 쌍을 이루는 디렉터리는 기본적으로 허용되지 않습니다. 새 경로를 사용하거나 --overwrite을 전달해 새 테이크가 완료된 후 이를 교체하세요. 이전 프레임 번들은 <output-name>.frames.previous-<id>로 유지되며, 대체 항목에서 --frames가 생략되는 경우도 포함됩니다. 캡처에 실패하면 이전 기록이 그대로 유지됩니다.
스크립트 및 에이전트에 대해 긍정 --duration-sec 을 선호합니다. npm uiRecord 및 targetRecord 도우미에는 durationSec가 필요합니다. 이들의 abort signal은 정상 종료가 아니라 강제 중단을 수행합니다. 지원되는 값은 참조 ui record 하세요.
CLI 기간이 없으면 녹화는 중지 신호를 기다립니다.
캡처가 시작된 후 Ctrl+C를 누르면 stopReason: cancelled와 함께 녹화를 정상적으로 완료하고 반환할 수 있습니다. 다른 중단은 유용한 비디오 또는 프레임을 유지할 수 있습니다.
partialOutput, recoveryHint, stopReason가 있는 경우 이를 읽고, 정상적인 완료를 가정하지 말고 보고된 증거 경로를 사용합니다. 녹화 중 전체 데스크톱 캡처를 사용할 수 없게 되면, 사용할 수 없는 데스크톱의 캡처를 계속하는 대신 capture_unavailable와 함께 중지됩니다. 프레임을 복구하기 위해 샌드박스를 전면으로 가져오지 않습니다. 사용 가능한 증거를 사용할 수 있기 전에 캡처가 실패할 수 있습니다.
실패한 게스트 기록의 경우 복구된 증거는 호스트의 고유한 <output>.partial-<id> 디렉터리에 배치됩니다. 배달에 실패하면 수신된 파일은 보고된 복구 경로(예: <output>.recovery-<id>복구 경로) 아래에 유지되고 게스트 원본은 유지됩니다. 샌드박스를 다시 시도하거나 닫기 전에 샌드박스를 계속 실행하고 오류의 복구 작업을 따릅니다. 보존된 부분 파일이 반드시 재생할 수 있는 비디오는 아닙니다.
스크린샷 및 비디오에는 중요한 정보가 포함될 수 있습니다. MP4와 동일한 주의로 프레임 디렉터리를 처리합니다. 기록 옵션 및 결과 필드를 참조 ui record 하세요.
샌드박스 검사
winapp target snapshot sandbox
winapp target snapshot sandbox --json
이 보고서는 VM을 만들거나 클라이언트를 다시 연결하거나 에이전트를 복구하지 않고 준비 상태, 현재 배포 및 게스트 창을 보고합니다. 샌드박스가 실행되지 않으면 해당 사실을 보고하고 성공적으로 종료됩니다. 하나를 시작하려면 winapp run . --on sandbox --detach를 사용합니다.
이 보고서는 게스트가 지원하는 작업을 현재 클라이언트가 수행할 수 있는 것과 구분합니다. 최소화된 클라이언트는 게스트가 둘 다 지원하는 경우에도 입력 또는 캡처를 방지할 수 있습니다.
UI PID에는 배포에서 추적 중인 런처 프로세스가 아니라 게스트 창 목록을 사용합니다.
JSON Work root 필드(텍스트 출력에서는 workRoot로 표시됨)는 상대 파일 전송 경로의 절대 기준 경로이며, 일반적으로 C:\WinApp\work입니다. 이는 C:\WinApp와는 별개이며, 일반적으로 capabilities.managedRoot이고, 게스트가 관리되는 루트를 보고하지 않는 경우 생략됩니다.
여러 클라이언트 창 때문에 대상을 명확히 캡처할 수 없는 경우 오류 메시지에 후보 목록이 표시됩니다. 다시 시도하기 전에 어떤 창을 닫을지 결정하십시오.
명령 실행 및 파일 복사
winapp target exec sandbox -- dotnet --info
$copy = winapp target push sandbox .\setup.ps1 Setup\setup.ps1 --json | ConvertFrom-Json
winapp target exec sandbox --cwd (Split-Path -Parent $copy.targetPath) -- powershell -ExecutionPolicy Bypass -File .\setup.ps1
winapp target pull sandbox Results .\results
설정 및 진단에 사용합니다 target exec . 게스트 사용자로 실행되고 표준 스트림을 전달하며 명령의 종료 코드를 반환합니다. 전체 대화형 터미널이 아닙니다. 콘솔 애플리케이션에는 리디렉션된 파이프가 표시됩니다.
--json 자식 명령의 stdout이 아닌 winapp 오류 형식을 지정합니다.
push 및 pull의 경우, 대상 경로는 workRoot에서 보고한 target snapshot를 기준으로 하는 상대 경로입니다. 절대 경로, 루트 기준 경로 및 UNC 경로는 허용되지 않습니다. 단일 파일은 이름을 지정하는 대상에 정확히 배치됩니다. 디렉터리가 해당 대상 아래에 해당 구조를 유지합니다. 푸시(JSON targetPath) 후에 인쇄된 확인된 게스트 경로를 사용하여 다음 명령의 선택을 합니다. 단일 파일의 --cwd경우 부모 디렉터리를 사용합니다. 게스트가 관리되는 루트를 보고하지 않으면 복사하기 전에 푸시가 실패합니다. 기본 경로를 가정하지 않고 오류의 업데이트 지침을 따릅니다.
신뢰할 수 있는 설치 스크립트만 실행합니다. 이 예제에서는 새로 생성된 샌드박스가 일반적으로 Restricted 정책에 따라 스크립트를 거부하므로 프로세스 범위의 -ExecutionPolicy Bypass를 사용합니다.
전송은 변경되지 않은 파일을 건너뛰고 파일을 게시하기 전에 대체 파일을 확인합니다. 심볼릭 링크와 정션은 따라가지 않습니다. 배포는 이를 거부하며, 디렉터리 복사 시에는 링크된 항목을 건너뜁니다. 링크를 통해 직접 명명된 연결된 원본 또는 대상 경로가 거부됩니다. 대신 실제 파일 또는 디렉터리를 복사합니다.
앱 제거 및 샌드박스 종료
winapp unregister --on sandbox --manifest .\Package.appxmanifest
현재 디렉터리에 매니페스트를 사용하면 생략 --manifest할 수 있습니다. 이렇게 하면 현재 샌드박스에서 winapp에 등록된 일치하는 개발 패키지만 제거됩니다.
외부에 설치된 패키지는 ID가 일치하는 경우에도 단독으로 남아 있습니다.
--force는 --on와 함께 사용할 수 없으며 지원되지 않습니다. 소유권 검사를 우회할 수 없습니다.
이것은 매니페스트 기반 패키지 정리이지, 패키지되지 않은 앱이나 .cs 입력에 대한 등록 해제 명령이 아닙니다.
샌드박스는 계속 실행됩니다. Windows 샌드박스의 자체 CLI를 사용하여 수명을 관리합니다.
wsb list
wsb connect --id <id>
wsb stop --id <id>
중지하면 게스트와 해당 작업이 삭제됩니다. 필요한 증거를 먼저 저장하고 사용 중인 인스턴스를 중지하기 전에 사용자의 동의를 얻습니다. 이후 winapp 명령은 새 샌드박스를 만들 수 있습니다. 나중에 모든 앱 대상을 다시 검색합니다.
Troubleshooting
오류 userAction에 따릅니다. 권고 nextCommand 는 자동으로 실행할 수 있는 권한이 아니라 제안입니다. 자동화에서 구조화된 error.code를 검사하세요.
인프라 장애는 70로 종료될 수 있지만, 임의의 애플리케이션도 70을(를) 반환할 수 있습니다. 숫자형 종료 상태만으로는 이 둘을 구분할 수 없습니다.
라우트된 UI 작업에서 제안된 복구 명령은 --on <target>를 유지하므로, 제안을 복사해도 동일한 실행 대상에서 유지됩니다.
| 오류 또는 증상 | 무엇을 해야 할지 |
|---|---|
sandbox_unsupported |
Windows 버전 및 펌웨어 가상화 확인 |
sandbox_setup_required |
위의 지침을 사용하여 Windows 샌드박스를 사용하도록 설정한 다음 준비가 되면 다시 시작합니다. |
sandbox_setup_requires_restart |
Windows 보류 중인 다시 시작을 보고합니다. 준비가 되면 작업을 저장하고 다시 시작한 다음 다시 시도합니다. |
sandbox_setup_incomplete |
시작에서 Windows 샌드박스를 열고 클라이언트 설정/업데이트를 완료한 다음 다시 시도합니다. |
sandbox_unmanaged_instance, sandbox_target_ambiguous |
보고된 인스턴스/창을 검사합니다. 모호성을 해결하기 위해 관련 없는 작업을 중지하지 마세요. |
sandbox_input_not_ready, sandbox_no_interactive_session |
기존 클라이언트를 복원하거나 지시된 대로 다시 연결한 다음 다시 시도합니다. |
sandbox_agent_incompatible |
버전 오류 안내를 따르고, 요청이 있으면 해당 설치 방식에 따라 설치된 CLI를 업그레이드한 다음, 동의가 있는 경우에만 닫기 또는 재시도를 수행합니다. |
sandbox_agent_busy |
다른 명령이 완료되기를 기다린 다음 다시 시도합니다. |
sandbox_terminated, sandbox_target_stale, sandbox_stale_handle |
앱을 다시 실행하고 게스트 PID/창을 다시 검색합니다. |
sandbox_state_unavailable |
WINAPP_TARGET_STATE_ROOT에 쓰기 권한이 있는지 확인하거나, 설정된 경우 %USERPROFILE%\.winapp\state을 수정하십시오. |
sandbox_deployment_dirty, sandbox_transfer_interrupted |
배포 또는 전송 다시 시도 |
sandbox_runtime_provision_failed |
명명된 종속성 또는 지원되지 않는 런타임 구성을 확인합니다. 공유 런타임 참조 |
sandbox_package_conflict, sandbox_provisioned_package_conflict |
패키지별 작업을 따릅니다. 관련 없는 패키지 또는 받은 편지함 패키지를 제거하지 마세요. |
sandbox_artifact_failed |
보고된 출력 및 클라이언트 준비 상태를 확인합니다. 부분 증거 보존 |
target_invalid, target_invalid_arguments |
오류에 표시된 대상 또는 옵션 수정 |
winapp update 는 설치된 CLI가 아닌 프로젝트 SDK 종속성을 업데이트합니다. 호스트/게스트 CLI 비호환성에 대한 수정 사항은 아닙니다.
빌드 28000 샌드박스에서 대상 공유
테스트된 빌드 28000 샌드박스는 공유 대상을 열거할 수 없습니다. 샌드박스에서는 다른 앱 기능을 테스트하되, Share의 소스-대상 흐름은 그 밖에서 검증하세요.
참고하십시오
Windows developer