Erste Schritte mit Package Support Framework

Das Package Support Framework ist ein Open Source Kit, das Ihnen hilft, Korrekturen auf Ihre vorhandene Desktopanwendung anzuwenden (ohne den Code zu ändern), damit sie in einem MSIX-Container ausgeführt werden kann. Durch das Package Support Framework können in Ihrer Anwendung die bewährten Methoden moderner Laufzeitumgebungen angewandt werden.

In diesem Artikel finden Sie einen indepth Blick auf jede Komponente des Package Support Frameworks und schrittweise Anleitungen zur Verwendung.

Verstehen, was sich in einem Paketunterstützungsframework befindet

Das Package Support Framework enthält eine ausführbare Datei, eine Laufzeit-Manager-DLL und eine Reihe von Laufzeitfixes.

Framework zur Paketunterstützung (Package Support Framework, PSF)

Hier ist der Prozess:

  1. Erstellen Sie eine Konfigurationsdatei, die die Korrekturen angibt, die Sie auf Ihre Anwendung anwenden möchten.
  2. Ändern Sie Ihr Paket, um auf die ausführbare Datei "Package Support Framework" (PSF) zu verweisen.

Wenn Benutzer Ihre Anwendung starten, ist das Paketunterstützungsframework-Startfeld die erste ausführbare Datei, die ausgeführt wird. Ihre Konfigurationsdatei wird gelesen, und die Runtimekorrekturen und die Runtime-Manager-DLL werden in den Anwendungsprozess eingefügt. Der Runtime-Manager wendet die Korrektur an, wenn diese erforderlich ist, damit die Anwendung in einem MSIX-Container ausgeführt wird.

Paketunterstützungsframework-DLL-Injektion

Schritt 1: Identifizieren von Problemen mit gepackter Anwendungskompatibilität

Erstellen Sie zunächst ein Paket für Ihre Anwendung. Installieren Sie es dann, führen Sie sie aus, und beobachten Sie ihr Verhalten. Möglicherweise werden Fehlermeldungen angezeigt, anhand derer Sie ein Kompatibilitätsproblem bestimmen können. Zum Identifizieren von Problemen können Sie auch Process Monitor verwenden. Allgemeine Probleme beziehen sich auf Anwendungsannahmen bezüglich der Arbeitsverzeichnis- und Programmpfadberechtigungen.

Verwenden des Prozessmonitors zum Identifizieren eines Problems

Process Monitor ist ein leistungsstarkes Hilfsprogramm für die Beobachtung der Datei- und Registrierungsvorgänge einer App und deren Ergebnisse. Dies kann Ihnen helfen, Anwendungskompatibilitätsprobleme zu verstehen. Fügen Sie nach dem Öffnen des Prozessmonitors einen Filter (Filterfilter > ...) hinzu, um nur Ereignisse aus der ausführbaren Anwendung einzuschließen.

ProcMon-App-Filter

Eine Liste der Ereignisse wird angezeigt. Für viele dieser Ereignisse wird das Wort ERFOLG in der Spalte "Ergebnis " angezeigt.

ProcMon-Ereignisse

Optional können Sie Ereignisse filtern, um nur Fehler anzuzeigen.

ProcMon ausschließen Erfolg

Wenn Sie einen Fehler bei einem Dateisystemzugriff vermuten, suchen Sie nach fehlgeschlagenen Ereignissen, die sich entweder unter system32/SysWOW64 oder dem Paketdateipfad befinden. Filter können auch hier helfen. Beginnen Sie unten in dieser Liste, und scrollen Sie nach oben. Fehler, die am unteren Rand dieser Liste angezeigt werden, sind zuletzt aufgetreten. Achten Sie am meisten auf Fehler, die Zeichenfolgen wie "Zugriff verweigert" und "Pfad/Name nicht gefunden" enthalten, und ignorieren Sie Dinge, die nicht verdächtige aussehen. Die PSFSample hat zwei Probleme. Sie können diese Probleme in der Liste sehen, die in der folgenden Abbildung angezeigt wird.

ProcMon Config.txt

Im ersten Problem, das in diesem Bild angezeigt wird, kann die Anwendung nicht aus der Datei "Config.txt" lesen, die sich im Pfad "C:\Windows\SysWOW64" befindet. Es ist unwahrscheinlich, dass die Anwendung versucht, direkt auf diesen Pfad zu verweisen. Wahrscheinlich versucht es, von dieser Datei mithilfe eines relativen Pfads zu lesen, und standardmäßig ist "System32/SysWOW64" das Arbeitsverzeichnis der Anwendung. Dies schlägt vor, dass die Anwendung erwartet, dass ihr aktuelles Arbeitsverzeichnis irgendwo im Paket festgelegt wird. Im Blick in die Appx können wir sehen, dass die Datei im gleichen Verzeichnis wie die ausführbare Datei vorhanden ist.

App-Config.txt

Das zweite Problem wird in der folgenden Abbildung angezeigt.

ProcMon-Logfile

In diesem Problem kann die Anwendung keine PROTOKOLLDATEI in den Paketpfad schreiben. Dies würde vorschlagen, dass eine Dateiumleitungsfixup helfen kann.

Schritt 2: Suchen eines Laufzeitfixes

Die PSF enthält Laufzeitkorrekturen, die Sie jetzt verwenden können, z. B. die Dateiumleitungskorrektur.

Dateiumleitungsfixup

Sie können die Dateiumleitungsbehebung verwenden, um Versuche zu umleiten, Daten in einem Verzeichnis zu schreiben oder zu lesen, auf das nicht von einer Anwendung zugegriffen werden kann, die in einem MSIX-Container ausgeführt wird.

Wenn Ihre Anwendung beispielsweise in eine Protokolldatei schreibt, die sich in demselben Verzeichnis wie ihre ausführbare Anwendung befindet, können Sie die Dateiumleitungsfixup verwenden, um diese Protokolldatei an einem anderen Speicherort zu erstellen, z. B. den lokalen App-Datenspeicher.

Runtime-Fixes aus der Community

Stellen Sie sicher, dass Sie die Communitybeiträge auf unserer GitHub-Seite überprüfen. Es ist möglich, dass andere Entwickler ein Problem ähnlich wie Ihre behoben haben und eine Laufzeitkorrektur freigegeben haben.

Schritt 3: Anwenden eines Laufzeitfixes

Sie können eine vorhandene Laufzeitkorrektur mit einigen einfachen Tools aus dem Windows SDK anwenden und die folgenden Schritte ausführen.

  • Erstellen eines Paketlayoutordners
  • Abrufen der Paketunterstützungsframeworkdateien
  • Hinzufügen zu Ihrem Paket
  • Ändern des Paketmanifests
  • Erstellen einer Konfigurationsdatei

Lassen Sie uns jede Aufgabe durchlaufen.

Erstellen des Paketlayoutordners

Wenn Sie bereits über eine MSIX-Datei (oder APPX)-Datei verfügen, können Sie den Inhalt in einen Layoutordner entpacken, der als Stagingbereich für Ihr Paket dient. Sie können dies mithilfe eines MakeAppx-Tools ausführen, basierend auf ihrem Installationspfad des SDK, wo Sie das makeappx.exe Tool auf Ihrem Windows 10 PC finden: x86: C:\Programmdateien (x86)\Windows Kits\10\bin\x86\makeappx.exe x64: C:\Programmdateien (x86)\Windows Kits\10\bin\x64\makeappx.exe

makeappx unpack /p PSFSamplePackage_1.0.60.0_AnyCPU_Debug.msix /d PackageContents

Dies gibt Ihnen etwas, das wie folgt aussieht.

Paketlayout

Wenn Sie keine MSIX-Datei (oder .appx) haben, mit der Sie beginnen möchten, können Sie den Paketordner und die Dateien von Grund auf erstellen.

Abrufen der Paketunterstützungsframeworkdateien

Sie können das PSF Nuget-Paket mithilfe des eigenständigen Nuget-Befehlszeilentools oder über Visual Studio abrufen.

Abrufen des Pakets mithilfe des Befehlszeilentools

Installieren Sie das Nuget-Befehlszeilentool an diesem Speicherort: https://www.nuget.org/downloads Führen Sie dann aus der Nuget-Befehlszeile diesen Befehl aus:

nuget install Microsoft.PackageSupportFramework

Alternativ können Sie die Paketerweiterung in .zip umbenennen und es entzipieren. Alle benötigten Dateien befinden sich im Ordner "/bin".

Abrufen des Pakets mithilfe von Visual Studio

Klicken Sie in Visual Studio mit der rechten Maustaste auf Ihren Projektknoten oder Projektknoten, und wählen Sie einen der Befehle "Nuget-Pakete verwalten" aus. Suchen Sie nach Microsoft.PackageSupportFramework oder PSF , um das Paket auf Nuget.org zu finden. Installieren Sie es dann.

Hinzufügen der Paketunterstützungsframeworkdateien zu Ihrem Paket

Fügen Sie die erforderlichen 32-Bit- und 64-Bit-PSF-DLLs und ausführbaren Dateien zum Paketverzeichnis hinzu. Orientieren Sie sich an der folgenden Tabelle. Sie möchten auch alle Laufzeitkorrekturen einschließen, die Sie benötigen. In unserem Beispiel benötigen wir die Dateiumleitungs-Laufzeitkorrektur.

Die ausführbare Anwendung ist x64 Die ausführbare Anwendung ist x86
PSFLauncher64.exe PSFLauncher32.exe
PSFRuntime64.dll PSFRuntime32.dll
PSFRunDll64.exe PSFRunDll32.exe

Ihr Paketinhalt sollte nun wie folgt aussehen.

Paket binärdateien

Ändern des Paketmanifests

Öffnen Sie Das Paketmanifest in einem Text-Editor, und legen Sie dann das Executable Attribut Application des Elements auf den Namen der ausführbaren Datei "PSF Launcher" fest. Wenn Sie die Architektur Ihrer Zielanwendung kennen, wählen Sie die entsprechende Version, PSFLauncher32.exe oder PSFLauncher64.exe aus. Wenn nicht, funktioniert PSFLauncher32.exe in allen Fällen. Hier finden Sie ein Beispiel.

<Package ...>
  ...
  <Applications>
    <Application Id="PSFSample"
                 Executable="PSFLauncher32.exe"
                 EntryPoint="Windows.FullTrustApplication">
      ...
    </Application>
  </Applications>
</Package>

Erstellen einer Konfigurationsdatei

Erstellen Sie einen Dateinamen config.json, und speichern Sie diese Datei im Stammordner Ihres Pakets. Ändern Sie die deklarierte App-ID der datei config.json, um auf die ausführbare Datei zu verweisen, die Sie gerade ersetzt haben. Mithilfe der Kenntnisse, die Sie über die Verwendung von Process Monitor gewonnen haben, können Sie auch das Arbeitsverzeichnis festlegen sowie die Dateiumleitungskorrektur verwenden, um Lese-/Schreibvorgänge in Protokolldateien unter dem paketrelativen Verzeichnis "PSFSampleApp" umzuleiten.

{
    "applications": [
        {
            "id": "PSFSample",
            "executable": "PSFSampleApp/PSFSample.exe",
            "workingDirectory": "PSFSampleApp/"
        }
    ],
    "processes": [
        {
            "executable": "PSFSample",
            "fixups": [
                {
                    "dll": "FileRedirectionFixup.dll",
                    "config": {
                        "redirectedPaths": {
                            "packageRelative": [
                                {
                                    "base": "PSFSampleApp/",
                                    "patterns": [
                                        ".*\\.log"
                                    ]
                                }
                            ]
                        }
                    }
                }
            ]
        }
    ]
}

Nachfolgend finden Sie einen Leitfaden für das config.json-Schema:

Array key Wert
applications id Verwenden Sie den Wert des Id Attributs des Application Elements im Paketmanifest.
applications executable Der paketrelative Pfad zur ausführbaren Datei, die Sie starten möchten. In den meisten Fällen können Sie diesen Wert aus der Paketmanifestdatei abrufen, bevor Sie ihn ändern. Es ist der Wert des Executable Attributs des Application Elements.
applications workingDirectory (Optional) Ein paketrelativer Pfad, der als Arbeitsverzeichnis der anwendung verwendet werden soll, die gestartet wird. Wenn Sie diesen Wert nicht festlegen, verwendet das Betriebssystem das System32 Verzeichnis als Arbeitsverzeichnis der Anwendung.
Prozesse executable In den meisten Fällen ist dies der Name der executable oben konfigurierten Dateierweiterung, wobei der Pfad und die Dateierweiterung entfernt wurden.
Fixups DLL-Datei Paketrelativer Pfad zum Fixup, .msix/.appx, der geladen werden soll.
Fixups config (Optional) Steuert, wie sich die Fixup-DLL verhält. Das genaue Format dieses Werts variiert je nach Fixupbasis, da jedes Fixup dieses "Blob" wie er möchte interpretieren kann.

Die applications, processesund fixups schlüssel sind Arrays. Das bedeutet, dass Sie die datei config.json verwenden können, um mehrere Anwendungen, Prozesse und Fixup-DLL anzugeben.

Packen und Testen der App

Erstellen Sie als Nächstes ein Paket.

makeappx pack /d PackageContents /p PSFSamplePackageFixup.msix

Signieren Sie es dann.

signtool sign /a /v /fd sha256 /f ExportedSigningCertificate.pfx PSFSamplePackageFixup.msix

Weitere Informationen finden Sie im Erstellen eines Paketsignaturzertifikats und zum Signieren eines Pakets mithilfe des Signtools

Installieren Sie das Paket mithilfe von PowerShell.

Hinweis

Denken Sie daran, das Paket zuerst zu deinstallieren.

powershell Add-AppPackage .\PSFSamplePackageFixup.msix

Führen Sie die Anwendung aus, und beobachten Sie das Verhalten mit angewendeter Laufzeitkorrektur. Wiederholen Sie die Diagnose- und Verpackungsschritte nach Bedarf.

Überprüfen, ob das Paketunterstützungsframework ausgeführt wird

Sie können überprüfen, ob ihr Laufzeitkorrektur ausgeführt wird. Eine Möglichkeit hierzu besteht darin, den Task-Manager zu öffnen und auf "Weitere Details" zu klicken. Suchen Sie die App, auf die das Paketunterstützungsframework angewendet wurde, und erweitern Sie das App-Detail, um weitere Details zu erhalten. Sie sollten sehen können, dass das Paketsupportframework ausgeführt wird.

Verwenden der Ablaufverfolgungskorrektur

Eine alternative Methode zum Diagnostizieren verpackter Anwendungskompatibilitätsprobleme besteht darin, die Ablaufverfolgungskorrektur zu verwenden. Diese DLL ist in der PSF enthalten und bietet eine detaillierte Diagnoseansicht des App-Verhaltens, ähnlich dem Prozessmonitor. Es ist speziell darauf ausgelegt, Anwendungskompatibilitätsprobleme aufzudecken. Um die Ablaufverfolgungskorrektur zu verwenden, fügen Sie die DLL dem Paket hinzu, fügen Sie dem Paket das folgende Fragment hinzu, fügen Sie das folgende Fragment zu Ihrer config.json hinzu, und packen Und installieren Sie Ihre Anwendung.

{
    "dll": "TraceFixup.dll",
    "config": {
        "traceLevels": {
            "filesystem": "allFailures"
        }
    }
}

Standardmäßig filtert die Ablaufverfolgungskorrektur Fehler aus, die als "erwartet" betrachtet werden können. Beispielsweise können Anwendungen versuchen, eine Datei bedingungslos zu löschen, ohne zu überprüfen, ob sie bereits vorhanden ist, und das Ergebnis ignorieren. Dies hat die unglückliche Folge, dass einige unerwartete Fehler herausgefiltert werden können, sodass wir im obigen Beispiel alle Fehler von Dateisystemfunktionen erhalten. Dies geschieht, da wir wissen, dass der Versuch, aus der Config.txt-Datei zu lesen, mit der Meldung "Datei nicht gefunden" fehlschlägt. Dies ist ein Fehler, der häufig beobachtet wird und nicht allgemein angenommen wird, dass er unerwartet ist. In der Praxis ist es wahrscheinlich am besten, nur nach unerwarteten Fehlern zu filtern und dann auf alle Fehler zurückzugehen, wenn ein Problem vorhanden ist, das noch nicht identifiziert werden kann.

Standardmäßig wird die Ausgabe aus der Ablaufverfolgungskorrektur an den angefügten Debugger gesendet. In diesem Beispiel werden wir keinen Debugger anfügen und stattdessen das DebugView-Programm von SysInternals verwenden, um die Ausgabe anzuzeigen. Nach dem Ausführen der App können wir dieselben Fehler wie zuvor sehen, was uns auf die gleichen Laufzeitkorrekturen zeigt.

TraceShim-Datei nicht gefunden

TraceShim-Zugriff verweigert

Debuggen, Erweitern oder Erstellen eines Laufzeitfixes

Sie können Visual Studio verwenden, um einen Laufzeitfix zu debuggen, einen Laufzeitkorrekturen zu erweitern oder von Grund auf neu zu erstellen. Sie müssen diese Schritte ausführen, um erfolgreich zu sein.

  • Hinzufügen eines Verpackungsprojekts
  • Projekt für den Laufzeitkorrektur hinzufügen
  • Hinzufügen eines Projekts, das die ausführbare PSF-Startprogrammdatei startet
  • Konfigurieren des Verpackungsprojekts

Wenn Sie fertig sind, sieht Ihre Lösung wie folgt aus.

Fertige Lösung

Sehen wir uns jedes Projekt in diesem Beispiel an.

Project Zweck
DesktopApplicationPackage Dieses Projekt basiert auf dem Windows Application Packaging-Projekt und gibt das MSIX-Paket aus.
Runtimefix Dies ist ein C++-Dynamic-Linked Library-Projekt, das mindestens eine Ersetzungsfunktionen enthält, die als Laufzeitkorrektur dienen.
PSFLauncher Dies ist C++ Empty Project. Dieses Projekt ist ein Ort, an dem die Laufzeit verteilte Dateien des Paketsupportframeworks gesammelt werden. Es gibt eine ausführbare Datei aus. Diese ausführbare Datei ist das erste, was ausgeführt wird, wenn Sie die Lösung starten.
WinFormsDesktopApplication Dieses Projekt enthält den Quellcode einer Desktopanwendung.

Ein vollständiges Beispiel, das alle diese Arten von Projekten enthält, finden Sie unter PSFSample.

Führen Sie die Schritte zum Erstellen und Konfigurieren der einzelnen Projekte in Ihrer Lösung durch.

Erstellen einer Paketlösung

Wenn Sie noch keine Lösung für Ihre Desktopanwendung haben, erstellen Sie eine neue leere Projektmappe in Visual Studio.

Leere Lösung

Möglicherweise möchten Sie auch alle Anwendungsprojekte hinzufügen, die Sie haben.

Hinzufügen eines Verpackungsprojekts

Wenn Sie noch nicht über ein Windows Application Packaging Project verfügen, erstellen Sie ein Projekt, und fügen Sie sie Ihrer Lösung hinzu.

Projektvorlage

Weitere Informationen zum Projekt "Verpacken von Windows-Anwendungen" finden Sie unter "Packen Ihrer Anwendung mithilfe von Visual Studio".

Klicken Sie in Projektmappen-Explorer mit der rechten Maustaste auf das Verpackungsprojekt, wählen Sie "Bearbeiten" aus, und fügen Sie dies dann unten in der Projektdatei hinzu:

<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>

Projekt für den Laufzeitkorrektur hinzufügen

Fügen Sie der Lösung ein C++ -Projekt (Dynamic-Link Library, DLL) hinzu.

Laufzeitkorrekturbibliothek

Klicken Sie mit der rechten Maustaste auf das Projekt, und wählen Sie dann "Eigenschaften" aus.

Suchen Sie auf den Eigenschaftenseiten nach dem C++-Sprachstandardfeld , und wählen Sie dann in der Dropdownliste neben diesem Feld die OPTION ISO C++17 Standard (/std:c++17) aus.

ISO 17-Option

Klicken Sie mit der rechten Maustaste auf dieses Projekt, und wählen Sie dann im Kontextmenü die Option "Nuget-Pakete verwalten" aus. Stellen Sie sicher, dass die Option "Paketquelle " auf "Alle " oder "nuget.org" festgelegt ist.

Klicken Sie auf das Symbol "Einstellungen" neben diesem Feld.

Suchen Sie nach dem PSF* Nuget-Paket, und installieren Sie es dann für dieses Projekt.

Nuget-Paket

Wenn Sie einen vorhandenen Laufzeitfix debuggen oder erweitern möchten, fügen Sie die Laufzeitkorrekturdateien hinzu, die Sie mithilfe der im Abschnitt "Suchen einer Laufzeitkorrektur " dieses Leitfadens beschriebenen Anleitung erhalten haben.

Wenn Sie einen brandneuen Fix erstellen möchten, fügen Sie diesem Projekt noch nichts hinzu. Wir helfen Ihnen, diesem Projekt später in diesem Handbuch die richtigen Dateien hinzuzufügen. Jetzt richten wir Ihre Lösung fort.

Hinzufügen eines Projekts, das die ausführbare PSF-Startprogrammdatei startet

Fügen Sie der Projektmappe ein leeres C++-Projektprojekt hinzu.

Leeres Projekt

Fügen Sie das PSF Nuget-Paket zu diesem Projekt hinzu, indem Sie dieselbe Anleitung verwenden, die im vorherigen Abschnitt beschrieben wird.

Öffnen Sie die Eigenschaftenseiten für das Projekt, und legen Sie auf der Seite "Allgemeine Einstellungen" die Eigenschaft "Zielname " auf PSFLauncher32 oder PSFLauncher64 abhängig von der Architektur Ihrer Anwendung fest.

PSF-Startprogrammreferenz

Fügen Sie in Ihrer Projektmappe einen Projektverweis zum Laufzeitkorrekturprojekt hinzu.

Laufzeitkorrekturreferenz

Klicken Sie mit der rechten Maustaste auf den Verweis, und wenden Sie dann im Eigenschaftenfenster diese Werte an.

Eigenschaft Wert
Lokal kopieren True
Lokale Satellitenassemblys kopieren True
Verweisassemblyausgabe True
Bibliothekabhängigkeiten verknüpfen Falsch
Verknüpfungsbibliotheksabhängigkeitseingaben Falsch

Konfigurieren des Verpackungsprojekts

Klicken Sie im Paketprojekt mit der rechten Maustaste auf den Ordner "Anwendungen ", und wählen Sie dann " Verweis hinzufügen" aus.

Hinzufügen eines Projektverweises

Wählen Sie das PSF-Startprogrammprojekt und Ihr Desktopanwendungsprojekt aus, und wählen Sie dann die Schaltfläche "OK " aus.

Desktopprojekt

Hinweis

Wenn Sie nicht über den Quellcode für Ihre Anwendung verfügen, wählen Sie einfach das PSF-Startprogrammprojekt aus. Wir zeigen Ihnen, wie Sie beim Erstellen einer Konfigurationsdatei auf Ihre ausführbare Datei verweisen.

Klicken Sie im Knoten "Anwendungen " mit der rechten Maustaste auf die PSF-Startprogrammanwendung, und wählen Sie dann " Als Einstiegspunkt festlegen" aus.

Festlegen als Einstiegspunkt

Fügen Sie ihrem Verpackungsprojekt eine Datei hinzu config.json , kopieren Sie den folgenden JSON-Text und fügen Sie sie dann in die Datei ein. Legen Sie die Eigenschaft "Paketaktion" auf "Inhalt" fest.

{
    "applications": [
        {
            "id": "",
            "executable": "",
            "workingDirectory": ""
        }
    ],
    "processes": [
        {
            "executable": "",
            "fixups": [
                {
                    "dll": "",
                    "config": {
                    }
                }
            ]
        }
    ]
}

Geben Sie einen Wert für jeden Schlüssel an. Verwenden Sie diese Tabelle als Richtlinie.

Array key Wert
applications id Verwenden Sie den Wert des Id Attributs des Application Elements im Paketmanifest.
applications executable Der paketrelative Pfad zur ausführbaren Datei, die Sie starten möchten. In den meisten Fällen können Sie diesen Wert aus der Paketmanifestdatei abrufen, bevor Sie ihn ändern. Es ist der Wert des Executable Attributs des Application Elements.
applications workingDirectory (Optional) Ein paketrelativer Pfad, der als Arbeitsverzeichnis der anwendung verwendet werden soll, die gestartet wird. Wenn Sie diesen Wert nicht festlegen, verwendet das Betriebssystem das System32 Verzeichnis als Arbeitsverzeichnis der Anwendung.
Prozesse executable In den meisten Fällen ist dies der Name der executable oben konfigurierten Dateierweiterung, wobei der Pfad und die Dateierweiterung entfernt wurden.
Fixups DLL-Datei Paketrelativer Pfad zur fixup-DLL, die geladen werden soll.
Fixups config (Optional) Steuert, wie sich die Fixup-DLL verhält. Das genaue Format dieses Werts variiert je nach Fixupbasis, da jedes Fixup dieses "Blob" wie er möchte interpretieren kann.

Wenn Sie fertig sind, sieht ihre config.json Datei wie folgt aus.

{
  "applications": [
    {
      "id": "DesktopApplication",
      "executable": "DesktopApplication/WinFormsDesktopApplication.exe",
      "workingDirectory": "WinFormsDesktopApplication"
    }
  ],
  "processes": [
    {
      "executable": ".*App.*",
      "fixups": [ { "dll": "RuntimeFix.dll" } ]
    }
  ]
}

Hinweis

Die applications, processesund fixups schlüssel sind Arrays. Das bedeutet, dass Sie die datei config.json verwenden können, um mehrere Anwendungen, Prozesse und Fixup-DLL anzugeben.

Debuggen einer Laufzeitkorrektur

Drücken Sie in Visual Studio F5, um den Debugger zu starten. Das erste, was gestartet wird, ist die PSF-Startprogrammanwendung, die wiederum Ihre Zieldesktopanwendung startet. Um die Zieldesktopanwendung zu debuggen, müssen Sie manuell an den Desktopanwendungsprozess anhängen, indem Sie "Debug-An> Prozess anfügen" auswählen und dann den Anwendungsprozess auswählen. Um das Debuggen einer .NET-Anwendung mit einer systemeigenen Laufzeitkorrektur-DLL zuzulassen, wählen Sie verwaltete und systemeigene Codetypen (Mixed Mode Debugging) aus.

Nachdem Sie dies eingerichtet haben, können Sie Haltepunkte neben Codezeilen im Desktopanwendungscode und dem Laufzeitkorrekturprojekt festlegen. Wenn Sie nicht über den Quellcode für Ihre Anwendung verfügen, können Sie Haltepunkte nur neben Codezeilen in Ihrem Laufzeitkorrekturprojekt festlegen.

Da das F5-Debuggen die Anwendung ausführt, indem lose Dateien aus dem Ordnerpfad des Paketlayoutordners bereitgestellt werden, anstatt sie aus einem .msix/.appx-Paket zu installieren, verfügt der Layoutordner in der Regel nicht über dieselben Sicherheitsbeschränkungen wie ein installierter Paketordner. Daher ist es möglicherweise nicht möglich, Denialfehler des Paketpfadzugriffs vor dem Anwenden einer Laufzeitkorrektur zu reproduzieren.

Um dieses Problem zu beheben, verwenden Sie die Bereitstellung von .msix / .appx-Paketbereitstellungen anstelle der Bereitstellung loser F5-Dateien. Verwenden Sie zum Erstellen einer .msix/ .appx-Paketdatei das MakeAppx-Dienstprogramm aus dem Windows SDK, wie oben beschrieben. Oder klicken Sie in Visual Studio mit der rechten Maustaste auf Ihren Anwendungsprojektknoten, und wählen Sie "Store –> App-Pakete erstellen" aus.

Ein weiteres Problem mit Visual Studio besteht darin, dass es keine integrierte Unterstützung für das Anfügen an untergeordnete Prozesse hat, die vom Debugger gestartet wurden. Dadurch ist es schwierig, Logik im Startpfad der Zielanwendung zu debuggen, die nach dem Startvorgang manuell von Visual Studio angefügt werden muss.

Um dieses Problem zu beheben, verwenden Sie einen Debugger, der untergeordnete Prozessanfügung unterstützt. Beachten Sie, dass es im Allgemeinen nicht möglich ist, einen Just-in-Time-Debugger (JIT) an die Zielanwendung anzufügen. Dies liegt daran, dass die meisten JIT-Techniken den Debugger anstelle der Ziel-App über den ImageFileExecutionOptions-Registrierungsschlüssel starten. Dadurch wird der Umwegmechanismus, der von PSFLauncher.exe verwendet wird, um FixupRuntime.dll in die Ziel-App einzufügen. WinDbg, in den Debugtools für Windows enthalten und aus dem Windows SDK abgerufen, unterstützt untergeordnete Prozessanfügungen. Sie unterstützt jetzt auch das direkte Starten und Debuggen einer UWP-App.

Um den Start der Zielanwendung als untergeordneter Prozess zu debuggen, starten Sie WinDbg.

windbg.exe -plmPackage PSFSampleWithFixup_1.0.59.0_x86__7s220nvg1hg3m -plmApp PSFSample

Aktivieren Sie bei der WinDbg Eingabeaufforderung das untergeordnete Debuggen, und legen Sie entsprechende Haltepunkte fest.

.childdbg 1
g

(führen Sie aus, bis die Zielanwendung gestartet wird und in den Debugger wechselt)

sxe ld fixup.dll
g

(führen Sie aus, bis die Fixup-DLL geladen wird)

bp ...

Hinweis

PLMDebug kann auch zum Anfügen eines Debuggers an eine App beim Start verwendet werden und ist auch in den Debuggingtools für Windows enthalten. Es ist jedoch komplexer, als die direkte Unterstützung jetzt von WinDbg bereitgestellt zu verwenden.

Support

Haben Sie Fragen? Bitten Sie uns über den Unterhaltungsbereich "Package Support Framework " auf der MSIX Tech Community-Website.