Windows Sandkastenausführung

Erstellen Sie die App auf Ihrem Computer und führen Sie sie dann in Windows Sandbox aus und automatisieren Sie sie:

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

Ersetzen Sie MyApp durch den Namen Ihrer App oder die Gast-PID, die von run ausgegeben wird. --detach kehrt nach dem Start zurück, damit der nächste Befehl die App prüfen kann; ohne dies wartet run, bis die App beendet ist. Die Sandbox bleibt zwischen Befehlen und Neu-Builds aktiv.

Bevor du anfängst

  • Verwenden Sie Windows 11 24H2 oder höher in einer unterstützten Edition, mit aktivierter Hardwarevirtualisierung.
  • Gast-Winapp unterstützt x64 und Arm64. Eine x86-App erfordert Gastunterstützung für die Ausführung und übereinstimmende x86-Abhängigkeiten. eine x64-Laufzeit erfüllt keine x86-App.
  • Halten Sie die Hostsitzung für echte Eingaben und Bildschirmaufnahmen entsperrt.

Aktivieren Sie Windows Sandbox im Aktivieren oder Deaktivieren Windows Features, oder führen Sie dies über ein Administratorterminal aus:

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

Speichern Sie Ihre Arbeit, und starten Sie Windows neu, wenn sie bereit sind. Öffnen Sie dann Windows Sandbox aus dem Startmenü, und schließen Sie alle Clientinstallationen oder -updates ab. winapp aktiviert weder die Funktion, noch installiert es den Client, fordert eine Rechteerweiterung an oder startet Windows neu. Wenn Voraussetzungen fehlen, wird der Vorgang mit Einrichtungsanweisungen angehalten; ein erkannter ausstehender Windows-Neustart wird separat gemeldet.

Eine kalte Verbindung oder eine erneute Verbindung kann den Fokus kurz wegnehmen. Nach dem Verbinden hält winapp sein eigenes Clientfenster außerhalb des sichtbaren Bereichs, ohne es zu aktivieren. Ein Sandkastenfenster, das Sie selbst geöffnet haben, bleibt vorhanden.

Important

Builds werden weiterhin auf Ihrem Computer ausgeführt. Projektbewertung, Wiederherstellung und Kompilierung sind nicht isoliert. --on sandbox sorgt nicht dafür, dass ein nicht vertrauenswürdiges Projekt sicher erstellt werden kann.

Eine Sandbox ist eine gemeinsame Umgebung. Apps und Workflows in ihr teilen den Benutzer, Desktop, Registrierung, Pakete, Laufzeiten und Netzwerkzugriff. Sie können einander beobachten oder stören. Verwenden Sie separate Computer für sich gegenseitig nicht vertrauenswürdige Workflows.

Windows erlaubt jeweils nur eine Sandbox gleichzeitig. winapp verwendet eine ausgeführte Instanz, einschließlich einer Instanz, die Sie selbst geöffnet haben. Bei der Vorbereitung werden freigegebene Bootstrap-Ordner von winapp sowie der Gast-Agent, der Entwicklermodus und eine eingehende Firewallregel hinzugefügt. winapp beendet keine angenommene Instanz oder entfernt nicht verknüpfte Apps. Es gibt keinen stillschweigenden Host-Fallback: Ein Befehl, der die Sandbox anfordert, wird dort ausgeführt oder schlägt fehl.

Ausführen und erneutes Erstellen

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

Build-Optionen wie --configuration, --arch, --framework, --property, --no-build und --no-restore gelten auf dem Host. Registrierung, Start und Debugging erfolgen im Gast; die App ist auf Ihrem Computer nicht registriert.

Auswahl Effekt im Sandkasten
--detach Nach dem Start zurückkehren, anstatt auf die Beendigung zu warten
--no-launch Bereitstellen und Registrieren ohne Starten
--clean Diese Bereitstellung erneut installieren und ihre Anwendungsdaten löschen
--unregister-on-exit Entfernen Sie diese Paketregistrierung, nachdem die App beendet wurde.
--with-alias Starten des Gastausführungsalias mit weitergeleiteten Datenströmen
--debug-output Debugausgabe des Gasts streamen; nur für verpackte Apps

Entpackte Apps starten ihre ausführbare Datei aus dem bereitgestellten Ordner. Sie haben kein Paket zu registrieren. --debug-output wird für nicht paketierte Sandbox-Ausführungen zurückgewiesen.

Beim erneuten Ausführen werden geänderte Dateien übertragen und aus der Buildausgabe gelöschte Dateien entfernt. Anwendungsdaten bleiben erhalten, es sei denn, Sie fordern --clean an. Eine unvollständige Bereitstellung wird nicht gestartet; beim Wiederholversuch wird die Gastkopie neu erstellt. Wenn sich Builddateien ändern, während sie von winapp vorbereitet werden, beenden Sie den Build, und wiederholen Sie den Vorgang.

Warm UI-Befehle melden nur ihr Ergebnis, ohne eine Sandkastenvorbereitungsnachricht zu wiederholen. Die Sandkastenstart- und Verbindungswiederherstellung melden weiterhin den Fortschritt. Verwenden Sie --verbose für Zeitangaben zur Verbindung und Diagnosedetails; --quiet und --json unterdrücken die Fortschrittsanzeige. JSON-Ausführungen umfassen eine Gastprozess-ID und einen Zielbereich:

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

Dies sind zusätzliche Felder im Ausführungsergebnis, kein separates Dokument. Kopieren Sie den gesamten UiTargetArgs Wert beim Prüfen der App: winapp ui inspect --on sandbox -a 4212. PIDs und Fenster-Handles erneut ermitteln, nachdem die Sandbox neu erstellt wurde; sie gehören zu dieser Sandbox-Generation, nicht zum Host oder zu einem zukünftigen Gast.

Getrennte Apps und die Lebensdauer des Agents

Eine gelöste nicht paketierte App wird beendet, wenn der Gast-Agent stoppt, auch während einer Reparatur des Agents. Wenn es zwischen Befehlen verschwindet, führen Sie den Befehl erneut mit --detach aus und ermitteln Sie sein UI-Ziel neu. Wenn man auf die App wartet, anstatt sie zu trennen, kann man ihr Beenden beobachten; dadurch wird die App jedoch nicht vor dem Verlust des Agents geschützt. Verpackte Apps verwenden die Windows-Aktivierung anstelle der Prozesslaufzeit des Agents. Durch das Schließen oder Neustarten der Sandbox werden alle Darin enthaltenen Apps beendet.

Gemeinsame Laufzeiten

winapp überprüft die Paketabhängigkeiten der App, Windows App SDK Anforderungen und *.runtimeconfig.json vor dem Start. Es verwendet Host-Caches oder lädt die erforderlichen Payloads herunter und installiert dann fehlende unterstützte Laufzeitumgebungen im Gast, nicht auf Ihrem Computer.

Paketanforderungen umfassen Herausgeber, Version und Architektur. Die freigegebene .NET Laufzeitauswahl berücksichtigt die konfigurierte Roll-Forward-Richtlinie und -Architektur der Anwendung. Gehen Sie nicht davon aus, dass eine neuere Laufzeit in derselben Hauptversion funktioniert.

Wenn ein Framework, eine Laufzeitkonfiguration oder Abhängigkeit nicht unterstützt werden kann, schlägt der Befehl vor dem Start explizit fehl und identifiziert die Anforderung. Folgen Sie der Aktion dieses Fehlers. Sofern Ihr Projekt dies unterstützt, entfällt bei einer eigenständigen Veröffentlichung die Notwendigkeit der entsprechenden gemeinsamen Runtime; nicht damit zusammenhängende Paketabhängigkeiten werden dadurch jedoch nicht entfernt.

Automatisieren der Benutzeroberfläche

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

Jedes ui Verb akzeptiert --on sandbox. App-Namen, PIDs, Fenster-Handles und Selektoren werden im Gastsystem aufgelöst. Verwenden Sie -a/--app oder -w/--window für app-spezifische Befehle; winapp erschließt nicht automatisch, welche App zuletzt gestartet wurde. Wenn Sie --on sandbox weglassen, wird stattdessen Ihr Host-Desktop ausgewählt.

Echte Eingaben und Aufzeichnungen erfordern einen verbundenen, nichtminimisierten Sandbox-Client. Eine schreibgeschützte Inspektion kann weiterhin funktionieren, wenn Eingaben nicht möglich sind. winapp kann einen eigenen minimierten Client ohne Aktivierung wiederherstellen; Ein minimierter manuell geöffneter Client muss von Ihnen wiederhergestellt werden. Wenn die Eingabe nach der erneuten Verbindung nicht mehr verfügbar ist, schlägt der Befehl fehl, anstatt die übermittelte Eingabe anzufordern. Verwenden Sie den Befehl "Erneut verbinden" im Fehler, und versuchen Sie es erneut.

Verwenden Sie winapp target snapshot sandbox --json, um zu überprüfen, ob der Desktop bereit ist, ohne die Sandbox zu starten oder erneut zu verbinden. Erkannte Fenster mit Terminalfehlern gelten nicht als Remote-Desktops. Wenn winapp den ausgewählten Desktop nicht überprüfen kann, weil noch eine Verbindung hergestellt wird oder er nicht geprüft werden kann, bleibt der Bereitschaftsstatus nicht verfügbar; warten Sie und versuchen Sie es erneut. Mehrere Remotedesktops können weiterhin mehrdeutig sein. Snapshot schließt keine Fenster oder behebt deren Fehler für Sie.

Siehe Benutzeroberflächenautomatisierung für Selektoren, Eingabemethoden und Assertionen.

Koordinieren von UI-Workflows im Sandkasten

Verwenden Sie ein WINAPP_UI_WORKFLOW_ID für zusammenarbeitende Befehle und einen anderen Wert für jeden unabhängigen Workflow. Legen Sie sie für jeden Aufruf fest, insbesondere, wenn Ihr Agent für jeden Toolaufruf eine neue Shell startet. winapp leitet eine gehashte, sandbox-generierungsspezifische Identität weiter; der rohe Hostwert wird nicht an den Gast gesendet.

Zeichnen Sie beispielsweise in zwei Terminals auf, und interagieren Sie dort unter Verwendung desselben Werts. Wählen Sie für jeden neuen Workflow einen neuen Wert aus.

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, während die Aufzeichnung ausgeführt wird:

$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

Sobald die Aufzeichnung und die Aktionen abgeschlossen sind:

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

Ein benannter Workflow behält seinen UI-Durchgang nach dem letzten Befehl vier Sekunden lang bei; yield gibt ihn sofort frei. Ohne ID gibt jeder Befehl nach Abschluss seinen Durchgang frei. Eine No-ID-Aufzeichnung blockiert daher für ihre gesamte Dauer andere Workflows, die den Desktop ändern. Eine schreibgeschützte Inspektion wartet nicht. Die UI-Interaktionen von Host und Gast sind getrennt.

Überprüfen Sie nach einer Pause erneut, und öffnen Sie alle benötigten Menüs oder Dialogfelder erneut: Möglicherweise hat ein anderer Workflow den Gastdesktop verwendet. Kooperative Wendungen isolieren Apps nicht voneinander.

Screenshots und Aufzeichnungen

Verwenden Sie ui zum Erfassen des Fensters einer App oder target zum Erfassen des gesamten nativen Gastdesktops, einschließlich der Shell- und Installationsdialogfelder:

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

Ausgaben landen auf dem Host, auch wenn Sie -o weglassen. Screenshots verwenden standardmäßig screenshot.png; Aufzeichnungen verwenden recording-<timestamp>-<guid>.mp4. Für Aufzeichnungen --frames liefert auch das <output-name>.frames Verzeichnis mit JPEGs, frames.ndjsonund manifest.json. Hostpfade für Ergebnisberichte. Zielaufzeichnungen werden im Gast ausgeführt. Ihre Hostdateien werden verfügbar, nachdem die Aufzeichnung und Übermittlung abgeschlossen sind.

target screenshot wartet auf den UI-Durchgang des Gasts, ohne ein Fenster zu aktivieren. Es schließt die Titelleiste und den Rahmen des Host-Sandboxfensters aus. Die PNG-Datei ist nicht skaliert: Bei Ursprung des Gastbildschirms (0,0) können Bildkoordinaten mit Verben zur Koordinateneingabe wie ui drag oder ui touch --at direkt verwendet werden, zusammen mit --on sandbox. Fügen Sie den gemeldeten Ursprung für einen Desktop mit einem negativen Ursprung hinzu. Verwenden Sie --json, um coordinates.contentRect und coordinates.sourceBounds zu lesen; beide verwenden physische Pixel und exklusive rechte/untere Kanten.

Zielaufzeichnungen melden dieselben Felder in JSON und im Framemanifest. MP4- und JPEG-Frames verwenden dieselbe Zuordnung, einschließlich der Skalierung mit --max-edge und des Paddings des Encoders. Um Bildpixel (x,y)zuzuordnen, lehnen Sie zuerst Punkte außerhalb contentRectab, und berechnen Sie dann jede Quellkoordinate als sourceStart + floor((pixel - contentStart + 0.5) * sourceSize / contentSize). Die Abskalierung verliert Genauigkeit; Verwenden Sie ein natives PNG, wenn genaue Koordinaten wichtig sind. Eine Änderung an den Abmessungen des Gastdesktops stoppt die Aufzeichnung mit display_changed, wobei nur die Frames vor der Änderung erhalten bleiben und das Frame-Manifest als unvollständig gekennzeichnet wird.

Standardmäßig wird ein vorhandenes MP4- oder gekoppeltes .frames Verzeichnis abgelehnt. Verwenden Sie einen neuen Pfad, oder übergeben Sie --overwrite, um sie nach Abschluss der neuen Aufnahme zu ersetzen. Vorherige Frame-Bundles werden als <output-name>.frames.previous-<id> beibehalten, auch wenn die Ersetzung --frames auslässt. Bei einer fehlgeschlagenen Aufzeichnung bleibt die alte Aufzeichnung erhalten.

Bevorzugen Sie ein positives --duration-sec für Skripte und Agenten. Die npm-uiRecord- und targetRecord-Hilfsprogramme erfordern durationSec; ihr Abbruchsignal bewirkt einen erzwungenen Abbruch, kein ordnungsgemäßes Beenden. Siehe ui record für unterstützte Werte. Wenn keine Dauer per CLI angegeben ist, wartet die Aufzeichnung auf ein Stoppsignal.

Mit STRG+C kann nach Beginn der Aufzeichnung eine Aufzeichnung erfolgreich abgeschlossen und mit stopReason: cancelled zurückgegeben werden. Andere Unterbrechungen können nützliche Videos oder Frames beibehalten. Lesen Sie stopReason, partialOutput und recoveryHint, wenn vorhanden, und verwenden Sie die angegebenen Nachweispfade, anstatt von einem normalen Abschluss auszugehen. Wenn die Aufnahme des gesamten Desktops während einer Aufnahme nicht mehr verfügbar ist, wird sie mit capture_unavailable beendet, anstatt einen nicht verfügbaren Desktop weiter aufzuzeichnen. Dies bringt die Sandbox nicht in den Vordergrund, um einen Frame wiederherzustellen. Die Erfassung kann fehlschlagen, bevor verwendbare Nachweise verfügbar sind.

Bei einer fehlgeschlagenen Gastaufzeichnung werden wiederhergestellte Nachweise in einem eindeutigen <output>.partial-<id> Verzeichnis auf dem Host abgelegt. Wenn die Übertragung fehlschlägt, bleiben empfangene Dateien unter dem angegebenen Wiederherstellungspfad, z. B. <output>.recovery-<id>, und die ursprünglichen Gastdateien bleiben erhalten. Lassen Sie die Sandbox weiterlaufen, und führen Sie die Wiederherstellungsmaßnahme für den Fehler aus, bevor Sie den Vorgang wiederholen oder sie schließen. Eine beibehaltene Teildatei ist nicht unbedingt ein abspielbares Video.

Screenshots und Videos enthalten möglicherweise vertrauliche Informationen. Behandeln Sie das Frameverzeichnis mit der gleichen Sorgfalt wie die MP4-Datei. Siehe ui record zu Aufzeichnungsoptionen und Ergebnisfeldern.

Überprüfen des Sandkastens

winapp target snapshot sandbox
winapp target snapshot sandbox --json

Dies meldet Bereitschaft, aktuelle Bereitstellungen und Gastfenster, ohne einen virtuellen Computer zu erstellen, den Client erneut zu verbinden oder den Agent zu reparieren. Wenn keine Sandbox läuft, meldet es dies und wird erfolgreich beendet. Um eins zu starten, verwenden Sie winapp run . --on sandbox --detach.

Der Bericht unterscheidet, was der Gast von dem unterstützt, was der aktuelle Client tun kann; Ein minimierter Client kann Eingaben oder Aufzeichnungen auch dann verhindern, wenn der Gast beides unterstützt. Verwenden Sie für die PIDs der Benutzeroberfläche die Liste der Gastfenster, nicht den vom Deployment erfassten Launcher-Prozess. Das JSON-Feld workRoot (wie Work root in der Textausgabe dargestellt) ist die absolute Basis für relative Dateiübertragungspfade, normalerweise C:\WinApp\work. Sie ist getrennt von capabilities.managedRoot, normalerweise C:\WinApp, und wird weggelassen, wenn der Gast seinen verwalteten Stamm nicht meldet. Wenn mehrere Clientfenster eine eindeutige Erfassung verhindern, führt die Fehlermeldung die möglichen Kandidaten auf; entscheiden Sie, welches Fenster Sie schließen, bevor Sie es erneut versuchen.

Ausführen von Befehlen und Kopieren von Dateien

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 für Einrichtung und Diagnose verwenden. Sie wird als Gastbenutzer ausgeführt, leitet Standarddatenströme weiter und gibt den Beendigungscode des Befehls zurück. Es handelt sich um kein vollständiges interaktives Terminal; Konsolenanwendungen sehen umgeleitete Pipes. --json formatiert Winapp-Fehler, nicht das Stdout des untergeordneten Befehls.

Für push und pull sind Zielpfade relativ zu dem von target snapshot gemeldeten workRoot. Absolute, Root- und UNC-Zielpfade werden abgelehnt. Eine einzelne Datei landet genau am Ziel, das Sie nennen; ein Verzeichnis behält seine Struktur unter diesem Ziel bei. Verwenden Sie den nach einem Push ausgegebenen aufgelösten Gastpfad (JSON targetPath), um --cwd des nächsten Befehls auszuwählen. Verwenden Sie bei einer einzelnen Datei deren übergeordnetes Verzeichnis. Wenn der Gast seinen verwalteten Stamm nicht meldet, schlägt der Push-Vorgang vor dem Kopieren fehl. Folgen Sie den Aktualisierungshinweisen in der Fehlermeldung, anstatt einen Standardpfad anzunehmen.

Führen Sie Setupskripts nur aus, denen Sie vertrauen. Im Beispiel wird -ExecutionPolicy Bypass mit Prozessbereich verwendet, da eine neue Sandbox Skripte gemäß ihrer Restricted-Richtlinie normalerweise ablehnt.

Übertragungen überspringen unveränderte Dateien und überprüfen Ersetzungen vor der Veröffentlichung. Symbolische Verknüpfungen und Verknüpfungen werden nicht befolgt: Die Bereitstellung lehnt sie ab, während Verzeichniskopien verknüpfte Einträge überspringen. Eine direkt benannte verknüpfte Quelle oder ein Zielpfad über einen Link wird abgelehnt. Kopieren Sie stattdessen die realen Dateien oder Verzeichnisse.

Entfernen einer App und Beenden der Sandbox

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

Mit einem Manifest im aktuellen Verzeichnis können Sie --manifest weglassen. Dadurch wird nur das übereinstimmende Entwicklungspaket entfernt, das von winapp im aktuellen Sandkasten registriert wurde. Ein extern installiertes Paket bleibt allein gelassen, auch wenn seine Identität übereinstimmt. --force wird mit --on nicht unterstützt; es kann Eigentumsprüfungen nicht umgehen. Dies ist eine manifestbasierte Paketbereinigung, kein Befehl zum Aufheben der Registrierung für entpackte Apps oder eine .cs Eingabe.

Die Sandbox läuft weiterhin. Verwalten Sie deren Lebensdauer mit der eigenen CLI von Windows Sandbox:

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

Durch Beenden wird der Gast mit seiner Arbeit verworfen. Speichern Sie zuerst die erforderlichen Nachweise, und rufen Sie die Zustimmung des Benutzers ab, bevor Sie eine Instanz beenden, die sie verwenden können. Später können Winapp-Befehle einen neuen Sandkasten erstellen. Entdecken Sie danach alle App-Ziele wieder.

Troubleshooting

Befolgen Sie die userAction des Fehlers; eine empfohlener nextCommand ist ein Vorschlag, keine Erlaubnis, ihn automatisch auszuführen. Überprüfen Sie in der Automatisierung das strukturierte error.code. Infrastrukturfehler können mit 70 enden, aber auch eine beliebige Anwendung kann 70 zurückgeben; der numerische Exit-Status allein reicht nicht aus, um zwischen beiden zu unterscheiden.

Wiederherstellungsbefehle, die von durch die UI weitergeleiteten Vorgängen vorgeschlagen werden, behalten --on <target> bei, sodass ein kopierter Vorschlag dasselbe Ausführungsziel beibehält.

Fehler oder Symptom Was zu tun ist
sandbox_unsupported Überprüfen Windows Edition/Version und Firmwarevirtualisierung
sandbox_setup_required Aktivieren Sie Windows Sandbox mithilfe der obigen Anweisungen, und starten Sie dann nach Bedarf neu.
sandbox_setup_requires_restart Windows meldet, dass ein Neustart aussteht; speichern Sie Ihre Arbeit und starten Sie neu, wenn Sie bereit sind, und versuchen Sie es dann erneut.
sandbox_setup_incomplete Öffnen Sie Windows Sandbox über Start und schließen Sie die Clienteinrichtung/das Clientupdate ab, und versuchen Sie es dann erneut.
sandbox_unmanaged_instance, sandbox_target_ambiguous Überprüfen Sie die gemeldeten Instanzen/Fenster; beenden Sie keine anderen, nicht damit zusammenhängenden Arbeiten, um Mehrdeutigkeiten zu beseitigen.
sandbox_input_not_ready, sandbox_no_interactive_session Stellen Sie den vorhandenen Client wieder her, oder stellen Sie eine erneute Verbindung her, und versuchen Sie es dann erneut.
sandbox_agent_incompatible Beachten Sie die Versionsfehlermeldung; aktualisieren Sie die installierte CLI über die verwendete Installationsmethode, falls Sie dazu aufgefordert werden, und schließen Sie sie bzw. versuchen Sie es nur nach Zustimmung erneut
sandbox_agent_busy Warten Sie, bis ein anderer Befehl abgeschlossen ist, und versuchen Sie es dann erneut.
sandbox_terminated, sandbox_target_stalesandbox_stale_handle App erneut ausführen und Gast-PIDs und -Fenster erneut erkennen
sandbox_state_unavailable Stellen Sie sicher, dass %USERPROFILE%\.winapp\state beschreibbar ist, oder korrigieren Sie WINAPP_TARGET_STATE_ROOT, falls festgelegt.
sandbox_deployment_dirty, sandbox_transfer_interrupted Bereitstellung oder Übertragung wiederholen
sandbox_runtime_provision_failed Auflösen der benannten Abhängigkeit oder der nicht unterstützten Laufzeitkonfiguration; Anzeigen freigegebener Laufzeiten
sandbox_package_conflict, sandbox_provisioned_package_conflict Führen Sie die paketspezifische Aktion aus; entfernen Sie keine nicht zugehörigen Pakete oder Pakete im Posteingang.
sandbox_artifact_failed Überprüfen Sie die gemeldete Ausgabe und die Bereitschaft des Clients; bewahren Sie teilweise Belege auf.
target_invalid, target_invalid_arguments Korrigieren der im Fehler angezeigten Ziel- oder Optionen

winapp update aktualisiert Projekt-SDK-Abhängigkeiten, nicht die installierte CLI. Es ist kein Fix für Host-/Gast-CLI-Inkompatibilität.

Freigeben von Zielen im Build 28000-Sandbox

Die Sandbox im getesteten Build 28000 kann keine Freigabeziele auflisten. Testen Sie andere App-Funktionen in der Sandbox, aber validieren Sie Share-Quell-zu-Ziel-Abläufe außerhalb der Sandbox.

Siehe auch

  • Last updated on