Uruchamianie Windows Sandbox

Skompiluj na maszynie, a następnie uruchom i zautomatyzuj aplikację w piaskownicy Windows:

winapp run . --on sandbox --detach
winapp ui inspect --on sandbox -a MyApp
winapp ui invoke --on sandbox SubmitButton -a MyApp

Zastąp MyApp nazwą swojej aplikacji lub identyfikatorem PID gościa wyświetlonym przez run. --detach kończy działanie po uruchomieniu, dzięki czemu następne polecenie może sprawdzić aplikację; bez niego run czeka na zakończenie działania aplikacji. Piaskownica pozostaje uruchomiona między poleceniami a ponowną kompilacją.

Zanim zaczniesz

  • Użyj Windows 11 24H2 lub nowszej w obsługiwanej wersji z włączoną wirtualizacją sprzętu.
  • Winapp gościa obsługuje architektury x64 i Arm64. Aplikacja x86 wymaga obsługi gościa na potrzeby jej uruchamiania i dopasowywania zależności x86; środowisko uruchomieniowe x64 nie spełnia wymagań aplikacji x86.
  • Pozostaw sesję hosta odblokowaną na potrzeby rzeczywistego wprowadzania danych i przechwytywania ekranu.

Włącz piaskownicę Windows w obszarze Włączanie lub wyłączanie funkcji Windows lub uruchom je z poziomu terminalu administratora:

dism.exe /Online /Enable-Feature /FeatureName:Containers-DisposableClientVM /All /NoRestart

Zapisz pracę i uruchom ponownie Windows, gdy wszystko będzie gotowe. Następnie otwórz Piaskownicę systemu Windows z menu Start i dokończ instalację lub aktualizację klienta. winapp nie włącza tej funkcji, nie instaluje klienta, nie żąda podwyższenia uprawnień ani nie uruchamia ponownie systemu Windows. Jeśli brakuje wymaganych składników, działanie zostaje zatrzymane i wyświetlane są instrukcje konfiguracji; wykryta konieczność ponownego uruchomienia systemu Windows jest raportowana oddzielnie.

Zimne połączenie lub ponowne połączenie może na krótko skupić się. Po nawiązaniu połączenia aplikacja winapp zachowuje własne okno klienta poza ekranem bez aktywowania go. Okno piaskownicy otwarte przez Ciebie pozostaje na miejscu.

Important

Kompilacje nadal działają na twoim komputerze. Ocenianie projektu, przywracanie i kompilacja nie są od siebie odizolowane. --on sandbox nie czyni niezaufanego projektu bezpiecznym do zbudowania.

Jedna piaskownica to jedno współdzielone środowisko. Aplikacje i przepływy pracy wewnątrz niej współdzielą użytkownika, pulpit, rejestr, pakiety, środowiska uruchomieniowe i dostęp do sieci. Mogą obserwować lub zakłócać siebie nawzajem. Używaj oddzielnych maszyn do wzajemnie niezaufanych przepływów pracy.

System Windows umożliwia uruchomienie tylko jednej Piaskownicy systemu Windows jednocześnie. winapp używa już uruchomionego wystąpienia, także tego uruchomionego samodzielnie. Przygotowanie tego powoduje dodanie współdzielonych folderów rozruchowych winapp, agenta gościa, Trybu dewelopera i reguły zapory dla połączeń przychodzących. winapp nie zatrzymuje przejętej instancji ani nie usuwa niepowiązanych aplikacji. Nie ma cichego przełączenia na hosta: polecenie żądające uruchomienia w piaskownicy zostanie uruchomione tam albo zakończy się niepowodzeniem.

Uruchamianie i przebudowywanie

winapp run .\MyApp.csproj --on sandbox --detach --json
winapp run .\publish --on sandbox --detach
winapp run . --on sandbox --clean --detach

Opcje kompilacji, takie jak --configuration, --arch, --property--framework, , --no-buildi --no-restore mają zastosowanie na hoście. Rejestracja, uruchamianie i debugowanie odbywają się w gościu; aplikacja nie jest zarejestrowana na twojej maszynie.

Option Efekt w piaskownicy
--detach Powrót po uruchomieniu zamiast czekać na wyjście
--no-launch Wdrażanie i rejestrowanie bez uruchamiania
--clean Zainstaluj ponownie to wdrożenie i wyczyść dane aplikacji
--unregister-on-exit Usuń tę rejestrację pakietu po zakończeniu działania aplikacji
--with-alias Uruchamianie aliasu wykonywania gościa przy użyciu przesyłanych strumieni
--debug-output Strumieniowanie wyników debugowania gościa; tylko aplikacje pakietowane

Rozpakowane aplikacje uruchamiają plik wykonywalny z wdrożonego folderu. Nie mają pakietu do rejestracji. --debug-output jest odrzucane dla niepakietowanych uruchomień w piaskownicy.

Ponowne uruchamianie transferuje zmienione pliki i usuwa pliki usunięte z danych wyjściowych kompilacji. Dane aplikacji są zachowywane, chyba że zażądasz --clean. Niekompletne wdrożenie nie uruchamia się; ponowienie próby odbudowuje jego kopię gościa. Jeśli pliki kompilacji zmienią się podczas przygotowywania ich przez aplikację winapp, zakończ kompilację i ponów próbę.

Polecenia uruchamiane z już przygotowanego interfejsu użytkownika zwracają tylko wynik, bez ponownego wyświetlania komunikatu o przygotowaniu środowiska Sandbox. Uruchamianie środowiska izolowanego i odzyskiwanie połączenia nadal zgłaszają postęp. Użyj --verbose, aby wyświetlić informacje o czasie połączenia i szczegóły diagnostyczne; --quiet i --json wyłączają informacje o postępie. Uruchomienia JSON obejmują identyfikator procesu gościa i zakres docelowy:

{
  "ProcessId": 4212,
  "Sandbox": true,
  "ProcessScope": "sandbox",
  "UiTargetArgs": "--on sandbox -a 4212",
  "ExecutionTarget": {
    "Kind": "sandbox",
    "Id": "default",
    "Architecture": "arm64",
    "Epoch": "..."
  }
}

Są to dodatkowe pola w wyniku uruchomienia, a nie oddzielny dokument. Skopiuj całą UiTargetArgs wartość podczas inspekcji aplikacji: winapp ui inspect --on sandbox -a 4212. Ponownie wykryj identyfikatory procesów (PID) i uchwyty okien po odtworzeniu Sandboxa; należą one do tej generacji Sandboxa, a nie do hosta ani przyszłego systemu gościa.

Odłączone aplikacje i okres istnienia agenta

Odłączona aplikacja bez pakietu przestaje działać, jeśli agent gościa zostanie zatrzymany, także podczas naprawy agenta. Jeśli zniknie między poleceniami, uruchom ponownie z --detach i ponownie odnajdź docelowy element interfejsu użytkownika. Oczekiwanie na aplikację zamiast się odłączać pozwala zaobserwować moment jej zakończenia; nie sprawia jednak, że aplikacja przetrwa utratę agenta. Aplikacje pakietowe korzystają z aktywacji systemu Windows zamiast czasu życia procesu agenta. Zamknięcie lub ponowne uruchomienie piaskownicy powoduje zakończenie wszystkich aplikacji w niej.

Współdzielone środowiska uruchomieniowe

Aplikacja winapp sprawdza zależności pakietu aplikacji, wymagania pakietu Zestaw SDK do aplikacji systemu Windows oraz *.runtimeconfig.json przed uruchomieniem. Korzysta z pamięci podręcznej hosta lub pobiera potrzebne pakiety, a następnie instaluje brakujące obsługiwane środowiska uruchomieniowe w systemie gościa, a nie na Twoim komputerze.

Wymagania dotyczące pakietu obejmują wydawcę, wersję i architekturę. Wybór współużytkowanego środowiska uruchomieniowego .NET uwzględnia skonfigurowaną dla aplikacji politykę przechodzenia do nowszych wersji oraz jej architekturę; nie należy zakładać, że zadziała dowolne nowsze środowisko uruchomieniowe w ramach tej samej wersji głównej.

Jeśli obsługa platformy, konfiguracji środowiska uruchomieniowego lub zależności nie jest możliwa, polecenie zakończy się niepowodzeniem jeszcze przed uruchomieniem i wyraźnie wskaże wymagany element. Wykonaj działanie powiązane z tym błędem. Jeśli projekt to obsługuje, publikowanie jako aplikacji niezależnej eliminuje potrzebę użycia odpowiedniego współdzielonego środowiska uruchomieniowego; nie eliminuje niezwiązanych zależności pakietów.

Automatyzowanie interfejsu użytkownika

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

Każdy ui czasownik przyjmuje --on sandbox. Nazwy aplikacji, identyfikatory PID, uchwyty okien i selektory są ustalane w systemie gościa. Użyj -a/--app lub -w/--window w przypadku poleceń kierowanych do aplikacji; winapp nie odgaduje, która aplikacja została ostatnio uruchomiona. Pominięcie --on sandbox powoduje zamiast tego wybranie pulpitu hosta.

Rzeczywiste dane wejściowe i rejestrowanie wymagają połączonego, niezminimalizowanego klienta Sandbox. Sprawdzanie w trybie tylko do odczytu może nadal działać, gdy wprowadzanie danych nie jest możliwe. Aplikacja winapp może przywrócić własnego zminimalizowanego klienta bez uaktywniania; ręcznie otwartego, zminimalizowanego klienta musisz przywrócić samodzielnie. Jeśli dane wejściowe są niedostępne po ponownym połączeniu, polecenie kończy się niepowodzeniem zamiast twierdzić, że dostarczono dane wejściowe. Użyj polecenia „reconnect” w komunikacie o błędzie i spróbuj ponownie.

Użyj winapp target snapshot sandbox --json, aby sprawdzić, czy pulpit jest gotowy, bez uruchamiania Piaskownicy ani ponownego łączenia się z nią. Rozpoznane okna błędów terminalu nie są liczone jako pulpity zdalne. Jeśli aplikacja winapp nie może zweryfikować wybranego pulpitu, ponieważ nadal nawiązuje połączenie lub nie można go sprawdzić, gotowość pozostaje niedostępna; poczekaj i ponów próbę. Wiele pulpitów zdalnych może być nadal niejednoznaczne. Snapshot nie zamyka okien ani nie rozwiązuje związanych z nimi błędów za Ciebie.

Zobacz Automatyzacja interfejsu użytkownika dla selektorów, metod wejściowych i asercji.

Koordynowanie przepływów pracy interfejsu użytkownika w piaskownicy

Użyj jednego WINAPP_UI_WORKFLOW_ID dla współpracujących poleceń i innej wartości dla każdego niezależnego przepływu pracy. Ustawiaj ją przy każdym wywołaniu, zwłaszcza gdy agent uruchamia nową powłokę przy każdym wywołaniu narzędzia. winapp przekazuje zahaszowaną tożsamość specyficzną dla danej generacji piaskownicy; surowa wartość hosta nie jest wysyłana do gościa.

Na przykład rejestruj i korzystaj z dwóch terminali, używając tej samej wartości. Wybierz nową wartość dla każdego nowego przepływu pracy.

Terminal 1:

$env:WINAPP_UI_WORKFLOW_ID = 'myapp-checkout-01'
winapp ui record --on sandbox -a MyApp --duration-sec 20 --frames -o .\checkout.mp4

Terminal 2, podczas gdy nagranie jest uruchomione:

$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

Po zakończeniu zarówno nagrywania, jak i działań:

$env:WINAPP_UI_WORKFLOW_ID = 'myapp-checkout-01'
winapp ui yield --on sandbox

Nazwany przepływ pracy zachowuje swój zwrot interfejsu użytkownika przez cztery sekundy po jego ostatnim poleceniu; yield natychmiast go zwalnia. Bez identyfikatora każde polecenie po zakończeniu zwalnia swoją kolej. Nagranie no-ID blokuje zatem inne przepływy pracy zmieniające się na pulpicie przez cały czas trwania. Inspekcja w trybie tylko do odczytu nie czeka. Zmiany interfejsu użytkownika hosta i gościa są oddzielne.

Po wstrzymaniu sprawdź ponownie i otwórz ponownie dowolne potrzebne menu lub okno dialogowe: inny przepływ pracy mógł używać pulpitu gościa. Przełączanie kooperatywne nie izoluje aplikacji od siebie nawzajem.

Zrzuty ekranu i nagrania

Użyj ui przechwytywania okna aplikacji lub target przechwytywania całego natywnego pulpitu gościa, w tym powłoki i okien dialogowych instalatora:

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

Dane wyjściowe trafiają na host, również po pominięciu -o. Zrzuty ekranu są domyślnie ustawione na screenshot.png; nagrania używają polecenia recording-<timestamp>-<guid>.mp4. W przypadku nagrań --frames także dostarcza katalog <output-name>.frames zawierający pliki JPEG, frames.ndjson i manifest.json. Wyniki raportują ścieżki hosta. Nagrania docelowe są uruchamiane w systemie gościa; pliki na hoście stają się dostępne po zakończeniu nagrywania i dostarczeniu.

target screenshot czeka na kolej interfejsu użytkownika gościa bez uaktywniania żadnego okna. Nie obejmuje paska tytułu ani obramowań okna Sandbox hosta. Jego plik PNG jest nieskalowany: ze źródłem (0,0)ekranu gościa współrzędne obrazu są bezpośrednio używane przez czasowniki współrzędnych wejściowych, takich jak ui drag lub ui touch --at, z --on sandbox. Dodaj zgłoszony punkt początkowy dla pulpitu z ujemnym punktem początkowym. Użyj --json, aby odczytać coordinates.sourceBounds i coordinates.contentRect; oba używają pikseli fizycznych oraz wyłącznych prawych i dolnych krawędzi.

Nagrania docelowe raportują te same pola w formacie JSON i manifeście ramki. Ramki MP4 i JPEG korzystają z tego samego mapowania, w tym ze skalowania --max-edge i dopełnienia enkodera. Aby zamapować piksel (x,y)obrazu, najpierw odrzuć punkty poza contentRect, a następnie oblicz każdą współrzędną źródłową jako sourceStart + floor((pixel - contentStart + 0.5) * sourceSize / contentSize). Skalowanie w dół traci precyzję; użyj natywnego pliku PNG, gdy dokładne współrzędne mają znaczenie. Zmiana obszaru pulpitu gościa powoduje zatrzymanie nagrywania za pomocą display_changed, z zachowaniem tylko klatek sprzed zmiany i oznaczeniem manifestu klatek jako niepełnego.

Istniejący plik MP4 lub sparowany katalog .frames są domyślnie odrzucane. Użyj nowej ścieżki albo przekaż --overwrite, aby zastąpić je po zakończeniu nowego ujęcia. Poprzednie pakiety klatek są zachowywane w postaci <output-name>.frames.previous-<id>, również wtedy, gdy zamiennik pomija --frames. Nieudane przechwytywanie pozostawia stare nagranie bez zmian.

Ustaw dodatnią wartość --duration-sec dla skryptów i agentów. Narzędzia pomocnicze npm uiRecord i targetRecord wymagają durationSec; ich sygnał przerwania wymusza zakończenie działania, a nie łagodne zatrzymanie. Zobacz ui record, aby sprawdzić obsługiwane wartości. Jeśli nie podano czasu trwania w CLI, nagrywanie czeka na sygnał zatrzymania.

Naciśnięcie Ctrl+C po rozpoczęciu nagrywania pozwala pomyślnie zakończyć nagrywanie i zwrócić nagranie za pomocą stopReason: cancelled. Inne przerwania mogą pozwalać zachować przydatne nagranie wideo lub klatki. Odczytaj stopReason, partialOutput i recoveryHint, jeśli są obecne, i użyj zgłoszonych ścieżek do danych dowodowych zamiast zakładać standardowe ukończenie. Jeśli przechwytywanie całego pulpitu stanie się niedostępne podczas nagrywania, zatrzyma się capture_unavailable, zamiast kontynuować przechwytywanie niedostępnego pulpitu. Nie przenosi elementu Sandbox na pierwszy plan w celu odzyskania klatki. Przechwytywanie może zakończyć się niepowodzeniem, zanim będzie dostępny dowolny dostępny do użycia dowód.

W przypadku nieudanego rejestrowania gościa odzyskane dowody są umieszczane w unikatowym <output>.partial-<id> katalogu na hoście. Jeśli dostarczanie nie powiedzie się, odebrane pliki pozostaną w zgłoszonej ścieżce odzyskiwania, na przykład <output>.recovery-<id>, i oryginalne pliki gościa zostaną zachowane. Pozostaw piaskownicę uruchomioną i wykonaj działanie naprawcze wskazane w komunikacie błędu przed ponowieniem próby lub jej zamknięciem. Zachowany częściowy plik nie musi być odtwarzalnym filmem wideo.

Zrzuty ekranu i wideo mogą zawierać poufne informacje. Traktuj katalog ramek z taką samą starannością jak plik MP4. Zobacz ui record , aby uzyskać opcje rejestrowania i pola wyników.

Inspekcja piaskownicy

winapp target snapshot sandbox
winapp target snapshot sandbox --json

To umożliwia raportowanie gotowości, aktualnych wdrożeń i okien systemu gościa bez tworzenia maszyny wirtualnej, ponownego łączenia klienta lub naprawy agenta. Jeśli piaskownica nie jest uruchomiona, zgłasza to i kończy działanie pomyślnie. Aby uruchomić go, użyj polecenia winapp run . --on sandbox --detach.

Raport rozróżnia, co obsługuje gość, od tego, co może zrobić bieżący klient; zminimalizowany klient może uniemożliwić wprowadzanie danych wejściowych lub przechwytywanie nawet wtedy, gdy gość obsługuje oba te elementy. Użyj listy okien gościa dla PID-ów interfejsu użytkownika, a nie śledzonego procesu uruchamiającego wdrożenie. Pole JSON workRoot (pokazane jako Work root w danych wyjściowych tekstu) jest bazą bezwzględną dla względnych ścieżek transferu plików, zwykle C:\WinApp\work. Jest on oddzielony od capabilities.managedRoot, zwykle C:\WinAppi jest pomijany, gdy gość nie zgłasza zarządzanego katalogu głównego. Jeśli kilka okien klienckich zapobiega jednoznacznemu przechwytywaniu, błąd wyświetla listę kandydatów; zdecyduj, które należy zamknąć przed ponowną próbą.

Uruchamianie poleceń i kopiowanie plików

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 służy do konfiguracji i diagnostyki. Jest on uruchamiany jako użytkownik-gość, przekazuje standardowe strumienie i zwraca kod zakończenia polecenia. Nie jest to pełny interaktywny terminal; Aplikacje konsolowe widzą przekierowane potoki. --json formatuje błędy winapp, a nie stdout polecenia podrzędnego.

Dla push i workRoot, pull. Bezwzględne, zakotwiczone i docelowe ścieżki UNC są odrzucane. Pojedynczy plik trafia dokładnie do wskazanego miejsca docelowego; katalog zachowuje swoją strukturę w jego obrębie. Użyj rozpoznanej ścieżki gościa wydrukowanej po wypchnięciu (JSON targetPath), aby wybrać następne polecenie --cwd; dla pojedynczego pliku użyj jego katalogu nadrzędnego. Jeśli gość nie zgłosi zarządzanego katalogu głównego, przesyłanie kończy się niepowodzeniem jeszcze przed skopiowaniem; postępuj zgodnie ze wskazówkami aktualizacji podanymi w komunikacie o błędzie, zamiast zakładać ścieżkę domyślną.

Uruchamiaj tylko zaufane skrypty konfiguracji. W przykładzie użyto -ExecutionPolicy Bypass o zakresie procesu, ponieważ nowe środowisko Sandbox zwykle odrzuca skrypty zgodnie ze swoimi zasadami Restricted.

Transfery pomijają niezmienione pliki i weryfikują zamiany przed ich opublikowaniem. Łącza symboliczne i punkty połączenia nie są obsługiwane: proces wdrażania je odrzuca, a kopiowanie katalogów pomija elementy będące dowiązaniami. Odrzucono źródło wskazane bezpośrednio przez łącze lub ścieżkę docelową wskazaną przez łącze. Zamiast tego skopiuj prawdziwe pliki lub katalogi.

Usuwanie aplikacji i wyłączanie trybu piaskownicy

winapp unregister --on sandbox --manifest .\Package.appxmanifest

Jeśli w bieżącym katalogu znajduje się manifest, można pominąć --manifest. Spowoduje to usunięcie tylko odpowiadającego pakietu programistycznego zarejestrowanego przez winapp w bieżącym środowisku Sandbox. Pakiet zainstalowany zewnętrznie pozostawia się bez zmian, nawet jeśli ma ten sam identyfikator. --force nie jest obsługiwane z --on; nie może ominąć sprawdzania własności. Jest to czyszczenie pakietów na podstawie manifestu, a nie polecenie wyrejestrowania aplikacji bezpakietowych ani danych wejściowych .cs.

Sandbox nadal działa. Zarządzaj jego cyklem życia za pomocą własnego interfejsu wiersza polecenia (CLI) Windows Sandbox:

wsb list
wsb connect --id <id>
wsb stop --id <id>

Zatrzymanie odrzuca gościa i jego pracę. Najpierw zapisz potrzebne dowody i uzyskaj zgodę użytkownika, zanim zatrzymasz instancję, z której może korzystać. Kolejne polecenia winapp mogą utworzyć nowe izolowane środowisko; następnie ponownie wykryj wszystkie obiekty docelowe aplikacji.

Troubleshooting

Postępuj zgodnie z userAction błędu; zalecenie nextCommand jest sugestią, a nie pozwoleniem na jego automatyczne uruchomienie. W automatyzacji sprawdź ustrukturyzowaną strukturę error.code. Awarie infrastruktury mogą zakończyć się kodem 70, ale jakakolwiek aplikacja może również zwrócić wartość 70; sam numeryczny kod zakończenia nie pozwala ich odróżnić.

Polecenia odzyskiwania sugerowane przez operacje kierowanego interfejsu użytkownika zachowują wartość --on <target>, dlatego kopiowanie sugestii utrzymuje je w tym samym obiekcie docelowym wykonywania.

Błąd lub objaw Co zrobić
sandbox_unsupported Sprawdź edycję i wersję systemu Windows oraz wirtualizację w oprogramowaniu układowym
sandbox_setup_required Włącz piaskownicę Windows, korzystając z powyższych instrukcji, a następnie uruchom ponownie, gdy wszystko będzie gotowe
sandbox_setup_requires_restart Windows zgłasza oczekujące ponowne uruchomienie; zapisz pracę i uruchom ponownie, gdy wszystko będzie gotowe, a następnie ponów próbę
sandbox_setup_incomplete Otwórz piaskownicę Windows od początku i zakończ instalację/aktualizację klienta, a następnie ponów próbę
sandbox_unmanaged_instance, sandbox_target_ambiguous Sprawdź zgłoszone wystąpienia/okna; nie przerywaj niepowiązanej pracy, aby rozwiązać niejednoznaczność
sandbox_input_not_ready, sandbox_no_interactive_session Przywróć istniejącego klienta lub ponownie połącz się zgodnie z instrukcjami, a następnie ponów próbę
sandbox_agent_incompatible Postępuj zgodnie z komunikatem o błędzie wersji; jeśli pojawi się taka prośba, zaktualizuj zainstalowane CLI, używając właściwej dla niego metody instalacji, a następnie zamknij aplikację lub ponów próbę wyłącznie za zgodą
sandbox_agent_busy Poczekaj na zakończenie innego polecenia, a następnie ponów próbę
sandbox_terminated, sandbox_target_stale, sandbox_stale_handle Uruchom ponownie aplikację i ponownie odnajduj identyfikatory PID gościa/okna
sandbox_state_unavailable Upewnij się, że można zapisywać do %USERPROFILE%\.winapp\state, lub popraw WINAPP_TARGET_STATE_ROOT, jeśli jest ustawiony.
sandbox_deployment_dirty, sandbox_transfer_interrupted Ponów próbę wdrożenia lub przeniesienia
sandbox_runtime_provision_failed Rozwiąż nazwaną zależność lub nieobsługiwaną konfigurację środowiska uruchomieniowego; zobacz Udostępnione środowiska uruchomieniowe
sandbox_package_conflict, sandbox_provisioned_package_conflict Postępuj zgodnie z działaniem właściwym dla pakietu; nie usuwaj niepowiązanych pakietów ani pakietów ze skrzynki odbiorczej
sandbox_artifact_failed Sprawdź zaraportowane wyniki i gotowość klienta; zachowaj wszelkie częściowe dowody
target_invalid, target_invalid_arguments Popraw element docelowy lub opcje wyświetlane w błędzie

winapp update aktualizuje zależności SDK projektu, a nie zainstalowane CLI. Nie jest to poprawka niezgodności interfejsu wiersza polecenia hosta/gościa.

Udostępnianie obiektów docelowych w piaskownicy kompilacji 28000

Testowana kompilacja 28000 Sandbox nie może wyświetlić miejsc docelowych udostępniania. Przetestuj inne funkcje aplikacji w środowisku Sandbox, ale przepływy udostępniania od źródła do miejsca docelowego weryfikuj poza nim.

Zobacz także

  • Last updated on