Erste Schritte mit Dem Paketsupportframework
Das Paketunterstützungsframework ist ein Open Source Kit, das Ihnen hilft, Korrekturen auf Ihre vorhandene Desktopanwendung anzuwenden (ohne den Code zu ändern), damit es 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.
Dieser Artikel enthält eine ausführliche Übersicht über die einzelnen Komponenten des Paketsupportframeworks und schrittweise Anleitungen zur Verwendung.
Verstehen, was in einem Paketunterstützungsframework enthalten ist
Das Package Support Framework umfasst eine ausführbare Datei, eine Runtime-Manager-DLL und eine Reihe von Runtimekorrekturen.
Hier ist der Prozess:
- Erstellen Sie eine Konfigurationsdatei, die die Korrekturen angibt, die Sie auf Ihre Anwendung anwenden möchten.
- Ändern Sie Das Paket so, dass es auf die ausführbare Datei des Paketsupportframeworks (PSF)-Startfelds verweist.
Wenn Benutzer Ihre Anwendung starten, ist das Paketunterstützungsframework-Startprogramm 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.
Schritt 1: Identifizieren von Kompatibilitätsproblemen mit verpackten Anwendungen
Erstellen Sie zunächst ein Paket für Ihre Anwendung. Installieren Sie sie dann, führen Sie sie aus, und beobachten Sie das 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. Häufige Probleme beziehen sich auf Anwendungsannahmen hinsichtlich der Arbeitsverzeichnis- und Programmpfadberechtigungen.
Verwenden des Prozessmonitors zum Identifizieren eines Problems
Process Monitor ist ein leistungsstarkes Hilfsprogramm zum Beobachten 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.
Eine Liste der Ereignisse wird angezeigt. Für viele dieser Ereignisse wird das Wort ERFOLG in der Spalte "Ergebnis" angezeigt.
Optional können Sie Ereignisse filtern, um nur Fehler anzuzeigen.
Wenn Sie vermuten, dass ein Dateisystemzugriffsfehler auftritt, suchen Sie nach fehlgeschlagenen Ereignissen, die sich entweder unter System32/SysWOW64 oder dem Paketdateipfad befinden. Filter können auch hier hilfreich sein. Beginnen Sie am Ende dieser Liste, und scrollen Sie nach oben. Fehler, die am Ende 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ächtig aussehen. Das PSFSample hat zwei Probleme. Sie können diese Probleme in der Liste sehen, die in der folgenden Abbildung angezeigt wird.
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. Höchstwahrscheinlich versucht es, mithilfe eines relativen Pfads aus dieser Datei zu lesen, und standardmäßig ist "System32/SysWOW64" das Arbeitsverzeichnis der Anwendung. Dies deutet darauf hin, dass die Anwendung erwartet, dass das aktuelle Arbeitsverzeichnis an einer beliebigen Stelle im Paket festgelegt wird. Im Blick auf das appx-Element können wir sehen, dass die Datei im selben Verzeichnis wie die ausführbare Datei vorhanden ist.
Das zweite Problem wird in der folgenden Abbildung angezeigt.
In diesem Problem kann die Anwendung keine PROTOKOLLDATEI in den Paketpfad schreiben. Dies würde vorschlagen, dass eine Dateiumleitungskorrektur hilfreich sein könnte.
Schritt 2: Suchen eines Laufzeitfixes
Die PSF enthält Laufzeitfixes, die Sie zurzeit verwenden können, z. B. die Dateiumleitungskorrektur.
Dateiumleitungskorrektur
Sie können die Dateiumleitungskorrektur verwenden, um Versuche zum Schreiben oder Lesen von Daten in einem Verzeichnis umzuleiten, auf das nicht über eine Anwendung zugegriffen werden kann, die in einem MSIX-Container ausgeführt wird.
Wenn Ihre Anwendung beispielsweise in eine Protokolldatei schreibt, die sich im selben Verzeichnis wie ihre ausführbare Anwendung befindet, können Sie die Dateiumleitungskorrektur verwenden, um diese Protokolldatei an einem anderen Speicherort zu erstellen, z. B. den lokalen App-Datenspeicher.
Laufzeitfixes aus der Community
Überprüfen Sie unbedingt die Community-Beiträge auf unserer GitHub-Seite. Es ist möglich, dass andere Entwickler ein Problem behoben haben, das Ihren ähnelt und einen Laufzeit-Fix freigegeben hat.
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 Paketsupportframework-Dateien
- Hinzufügen zu Ihrem Paket
- Ändern des Paketmanifests
- Erstellen einer Konfigurationsdatei
Lassen Sie uns jede Aufgabe durchgehen.
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 über eine Eingabeaufforderung mit dem MakeAppx-Tool tun, basierend auf Ihrem Installationspfad des SDK finden Sie das tool makeappx.exe auf Ihrem Windows 10-PC: x86: C:\Programme (x86)\Windows Kits\10\bin\x86\makeappx.exe x64: C:\Programme (x86)\Windows Kits\10\bin\x64\makeappx.exe
makeappx unpack /p PSFSamplePackage_1.0.60.0_AnyCPU_Debug.msix /d PackageContents
Dadurch erhalten Sie etwas, das wie folgt aussieht.
Wenn Sie nicht über eine MSIX-Datei (oder APPX-Datei) verfügen, mit der Sie beginnen möchten, können Sie den Paketordner und die Dateien von Grund auf neu erstellen.
Abrufen der Paketsupportframework-Dateien
Sie können das PSF Nuget-Paket über das eigenständige Nuget-Befehlszeilentool oder über Visual Studio abrufen.
Abrufen des Pakets mithilfe des Befehlszeilentools
Installieren Sie das Befehlszeilentool Nuget von diesem Speicherort: https://www.nuget.org/downloads. Führen Sie dann über die Nuget-Befehlszeile den folgenden Befehl aus:
nuget install Microsoft.PackageSupportFramework
Alternativ können Sie die Paketerweiterung in ZIP umbenennen und entzippen. 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 Projektmappen- 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 sie dann.
Hinzufügen der Paketsupportframework-Dateien 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. Außerdem sollten Sie alle benötigten Laufzeitfixes einschließen. In unserem Beispiel benötigen wir den Runtime-Fix für die Dateiumleitung.
| Ausführbare Anwendung ist x64 | Ausführbare Anwendung ist x86 |
|---|---|
| PSF Startprogramm 64.exe | PSF Startprogramm 32.exe |
| PSFRuntime64.dll | PSFRuntime32.dll |
| PSFRunDll64.exe | PSFRunDll32.exe |
Ihr Paketinhalt sollte nun etwa wie folgt aussehen.
Ändern des Paketmanifests
Öffnen Sie das Paketmanifest in einem Text-Editor, und legen Sie dann das Executable Attribut des Application Elements auf den Namen der PSF-Startprogramm ausführbare Datei fest. Wenn Sie die Architektur Ihrer Zielanwendung kennen, wählen Sie die entsprechende Version, PSF Startprogramm 32.exe oder PSF Startprogramm 64.exe aus. Ist dies nicht der Fall, funktioniert PSF Startprogramm 32.exe in allen Fällen. Im Folgenden sehen 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 so, dass sie auf die ausführbare Datei verweist, die Sie soeben ersetzt haben. Mit dem Wissen, das Sie über die Verwendung von Process Monitor gewonnen haben, können Sie auch das Arbeitsverzeichnis festlegen und die Dateiumleitungskorrektur verwenden, um Lese-/Schreibvorgänge in PROTOKOLLDATEIen unter dem paketrelativen "PSFSampleApp"-Verzeichnis umzuleiten.
{
"applications": [
{
"id": "PSFSample",
"executable": "PSFSampleApp/PSFSample.exe",
"workingDirectory": "PSFSampleApp/"
}
],
"processes": [
{
"executable": "PSFSample",
"fixups": [
{
"dll": "FileRedirectionFixup.dll",
"config": {
"redirectedPaths": {
"packageRelative": [
{
"base": "PSFSampleApp/",
"patterns": [
".*\\.log"
]
}
]
}
}
}
]
}
]
}
Es folgt ein Leitfaden für das Config.json-Schema:
| Array | Schlüssel | Wert |
|---|---|---|
| applications | id | Verwenden Sie den Wert des Attributs Id 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. |
| vorgänge | executable | In den meisten Fällen ist dies der Name des executable oben konfigurierten Pfads und der Dateierweiterung entfernt. |
| Fixups | dll | Paketrelativer Pfad zum Fixup, .msix/.appx zum Laden. |
| 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 die Schlüssel sind Arrays. Dies 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 unter Erstellen eines Paketsignaturzertifikats und zum Signieren eines Pakets mit signtool
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 Paketsupportframework ausgeführt wird
Sie können überprüfen, ob der Laufzeit-Fix 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 die App-Details, um weitere Details anzuzeigen. Sie sollten in der Lage sein, anzuzeigen, dass das Paketunterstützungsframework 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 den Trace Fixup zu verwenden, fügen Sie die DLL zum Paket hinzu, fügen Sie das folgende Fragment zu Ihrer config.json hinzu, und packen Und installieren Sie die Anwendung.
{
"dll": "TraceFixup.dll",
"config": {
"traceLevels": {
"filesystem": "allFailures"
}
}
}
Standardmäßig filtert die Ablaufverfolgungskorrektur Fehler, 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, ohne das Ergebnis zu ignorieren. Dies hat die unglückliche Folge, dass einige unerwartete Fehler möglicherweise herausgefiltert werden, daher entscheiden wir uns im obigen Beispiel dafür, alle Fehler von Dateisystemfunktionen zu erhalten. Dies geschieht, da wir vorher wissen, dass der Versuch, aus der Datei Config.txt zu lesen, mit der Meldung "Datei nicht gefunden" fehlschlägt. Dies ist ein Fehler, der häufig beobachtet wird und in der Regel nicht als unerwartet angenommen wird. In der Praxis ist es wahrscheinlich am besten, nur nach unerwarteten Fehlern zu filtern, und dann auf alle Fehler zurückfallen, wenn ein Problem auftritt, das immer noch nicht identifiziert werden kann.
Standardmäßig wird die Ausgabe des Trace Fixups an den angefügten Debugger gesendet. In diesem Beispiel werden wir keinen Debugger anfügen und verwenden stattdessen das DebugView-Programm von SysInternals, um die Ausgabe anzuzeigen. Nach dem Ausführen der App können dieselben Fehler wie zuvor angezeigt werden, was uns auf die gleichen Laufzeitfixes verweist.
Debuggen, Erweitern oder Erstellen eines Laufzeitfixes
Sie können Visual Studio verwenden, um einen Runtime-Fix zu debuggen, einen Laufzeitfix zu erweitern oder von Grund auf neu zu erstellen. Sie müssen diese Dinge tun, um erfolgreich zu sein.
- Hinzufügen eines Verpackungsprojekts
- Hinzufügen eines Projekts für den Laufzeitfix
- Hinzufügen eines Projekts, das das PSF-Startprogramm ausführbare Datei startet
- Konfigurieren des Paketprojekts
Wenn Sie fertig sind, sieht Ihre Lösung ungefähr wie folgt aus.
Sehen wir uns jedes Projekt in diesem Beispiel an.
| Projekt | Zweck |
|---|---|
| DesktopApplicationPackage | Dieses Projekt basiert auf dem Windows Application Packaging-Projekt und gibt das MSIX-Paket aus. |
| Runtimefix | Dies ist ein C++-Projekt mit dynamic-Linked Library, das mindestens eine Ersetzungsfunktion enthält, die als Laufzeitkorrektur dient. |
| PSF Startprogramm | Dies ist C++ Leeres Projekt. Dieses Projekt ist ein Ort zum Sammeln der laufzeitverteilbaren Dateien des Paketsupportframeworks. Sie gibt eine ausführbare Datei aus. Diese ausführbare Datei ist das erste, was beim Starten der Lösung ausgeführt wird. |
| WinFormsDesktopApplication | Dieses Projekt enthält den Quellcode einer Desktopanwendung. |
Ein vollständiges Beispiel, das alle diese Projekttypen enthält, finden Sie unter PSFSample.
Sehen wir uns die Schritte zum Erstellen und Konfigurieren der einzelnen Projekte in Ihrer Lösung an.
Erstellen einer Paketlösung
Wenn Sie noch keine Lösung für Ihre Desktopanwendung haben, erstellen Sie eine neue leere Projektmappe in Visual Studio.
Sie können auch beliebige Anwendungsprojekte hinzufügen, die Sie haben.
Hinzufügen eines Verpackungsprojekts
Wenn Sie noch nicht über ein Windows Application Packaging-Projekt verfügen, erstellen Sie ein Projekt, und fügen Sie es Zu Ihrer Lösung hinzu.
Weitere Informationen zum Windows Application Packaging-Projekt finden Sie unter Packen Ihrer Anwendung mithilfe von Visual Studio.
Klicken Sie in Projektmappen-Explorer mit der rechten Maustaste auf das Paketprojekt, wählen Sie "Bearbeiten" aus, und fügen Sie dies am Ende 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>
Hinzufügen eines Projekts für den Laufzeitfix
Fügen Sie der Lösung ein C++ -Projekt (Dynamic Link Library, DLL) hinzu.
Klicken Sie mit der rechten Maustaste auf das Projekt, und wählen Sie dann "Eigenschaften" aus.
Suchen Sie auf den Eigenschaftenseiten das Feld "C++-Sprachstandard ", und wählen Sie dann in der Dropdownliste neben diesem Feld die Option ISO C++17 Standard (/std:c++17) aus.
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.
Wenn Sie einen vorhandenen Laufzeitfix debuggen oder erweitern möchten, fügen Sie die Laufzeit-Fixdateien hinzu, die Sie mithilfe der im Abschnitt "Suchen einer Laufzeitkorrektur " dieses Handbuchs beschriebenen Anleitungen erhalten haben.
Wenn Sie einen völlig neuen Fix erstellen möchten, fügen Sie diesem Projekt noch nichts hinzu. Wir helfen Ihnen, die richtigen Dateien zu diesem Projekt weiter unten in diesem Leitfaden hinzuzufügen. Jetzt werden wir Ihre Lösung weiterhin einrichten.
Hinzufügen eines Projekts, das das PSF-Startprogramm ausführbare Datei startet
Fügen Sie der Projektmappe ein leeres C++ -Projekt hinzu.
Fügen Sie das PSF Nuget-Paket zu diesem Projekt hinzu, indem Sie die im vorherigen Abschnitt beschriebenen Anleitungen verwenden.
Ö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.
Fügen Sie einen Projektverweis zum Laufzeitkorrekturprojekt in Ihrer Projektmappe hinzu.
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 | False |
| Verknüpfungsbibliotheksabhängigkeitseingaben | False |
Konfigurieren des Paketprojekts
Klicken Sie im Paketprojekt mit der rechten Maustaste auf den Ordner "Anwendungen ", und wählen Sie dann "Verweis hinzufügen" aus.
Wählen Sie das PSF-Startprogramm Projekt und Ihr Desktopanwendungsprojekt aus, und klicken Sie dann auf die Schaltfläche "OK".
Hinweis
Wenn Sie nicht über den Quellcode für Ihre Anwendung verfügen, wählen Sie einfach das PSF-Startprogramm Projekt 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-Startprogramm Anwendung, und wählen Sie dann "Als Einstiegspunkt festlegen" aus.
Fügen Sie ihrem Paketprojekt eine Datei mit dem Namen config.json hinzu, kopieren Sie dann den folgenden JSON-Text, und fügen Sie ihn 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 | Schlüssel | Wert |
|---|---|---|
| applications | id | Verwenden Sie den Wert des Attributs Id 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. |
| vorgänge | executable | In den meisten Fällen ist dies der Name des executable oben konfigurierten Pfads und der Dateierweiterung entfernt. |
| Fixups | dll | Paketrelativer Pfad zur zu ladenden Fixup-DLL. |
| 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 ungefähr wie folgt aus.
{
"applications": [
{
"id": "DesktopApplication",
"executable": "DesktopApplication/WinFormsDesktopApplication.exe",
"workingDirectory": "WinFormsDesktopApplication"
}
],
"processes": [
{
"executable": ".*App.*",
"fixups": [ { "dll": "RuntimeFix.dll" } ]
}
]
}
Hinweis
Die applications, processesund fixups die Schlüssel sind Arrays. Dies bedeutet, dass Sie die Datei config.json verwenden können, um mehrere Anwendungen, Prozesse und Fixup-DLL anzugeben.
Debuggen eines Laufzeitfixes
Drücken Sie in Visual Studio F5, um den Debugger zu starten. Das erste, was gestartet wird, ist die PSF-Startprogramm-Anwendung, die wiederum die Zieldesktopanwendung startet. Um die Zieldesktopanwendung zu debuggen, müssen Sie den Desktopanwendungsprozess manuell anfügen, indem Sie "Debuggen> an Prozess anfügen" auswählen und dann den Anwendungsprozess auswählen. Um das Debuggen einer .NET-Anwendung mit einer systemeigenen Laufzeit-Fix-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 Pfad des Paketlayoutordners bereitgestellt werden, anstatt aus einem MSIX/.appx-Paket zu installieren, hat der Layoutordner in der Regel nicht dieselben Sicherheitseinschränkungen wie ein installierter Paketordner. Daher ist es möglicherweise nicht möglich, Denialfehler des Paketpfadzugriffs zu reproduzieren, bevor eine Laufzeitkorrektur angewendet wird.
Um dieses Problem zu beheben, verwenden Sie die Bereitstellung von MSIX/APPX-Paketen anstelle der Bereitstellung loser Dateien F5. 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 werden. Dadurch ist es schwierig, logik im Startpfad der Zielanwendung zu debuggen, die nach dem Start manuell von Visual Studio angefügt werden muss.
Um dieses Problem zu beheben, verwenden Sie einen Debugger, der untergeordnete Prozessanfügungen unterstützt. Beachten Sie, dass es im Allgemeinen nicht möglich ist, einen JIT-Debugger (Just-in-Time) an die Zielanwendung anzufügen. Dies liegt daran, dass die meisten JIT-Techniken das Starten des Debuggers anstelle der Ziel-App über den ImageFileExecutionOptions-Registrierungsschlüssel umfassen. Dadurch wird der Umwegmechanismus von PSF Startprogramm.exe zum Einfügen von FixupRuntime.dll in die Ziel-App besiegt. WinDbg, das in den Debugtools für Windows enthalten ist und aus dem Windows SDK abgerufen wurde, unterstützt untergeordnete Prozessanfügung. 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 an der Eingabeaufforderung das WinDbg untergeordnete Debuggen, und legen Sie entsprechende Haltepunkte fest.
.childdbg 1
g
(ausführen, bis die Zielanwendung gestartet wird und in den Debugger wechselt)
sxe ld fixup.dll
g
(ausführen, 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 Debugtools für Windows enthalten. Es ist jedoch komplexer zu verwenden als die direkte Unterstützung, die jetzt von WinDbg bereitgestellt wird.
Support
Haben Sie Fragen? Fragen Sie uns auf der MSIX Tech Community-Website im Unterhaltungsbereich des Paketsupportframeworks .