Condividi tramite


Introduzione a Package Support Framework

Package Support Framework è un kit open source che consente di applicare correzioni all'applicazione desktop esistente (senza modificare il codice) in modo che possa essere eseguita in un contenitore MSIX. Il Package Support Framework aiuta la tua applicazione a seguire le migliori pratiche degli ambienti di runtime moderni.

Questo articolo fornisce un'analisi indepth di ogni componente di Package Support Framework e guida dettagliata all'uso.

Capire cosa contiene un Package Support Framework

Package Support Framework contiene un eseguibile, una DLL di gestore runtime e un set di correzioni di runtime.

Framework di supporto dei pacchetti

Ecco il processo:

  1. Creare un file di configurazione che specifica le correzioni da applicare all'applicazione.
  2. Modifica il tuo pacchetto per puntare al file eseguibile del launcher del Package Support Framework (PSF).

Quando utenti avviano la tua applicazione, il programma di avvio di Package Support Framework è il primo eseguibile ad avviarsi. Legge il file di configurazione e inserisce le correzioni di runtime e la DLL di Gestione runtime nel processo dell'applicazione. Gestione runtime applica la correzione quando è necessaria per l'esecuzione dell'applicazione all'interno di un contenitore MSIX.

Iniezione DLL del Framework di Supporto dei Pacchetti

Passaggio 1: Identificare i problemi di compatibilità delle applicazioni in pacchetto

Creare prima di tutto un pacchetto per l'applicazione. Quindi, installare, eseguire e osservarne il comportamento. È possibile che vengano visualizzati messaggi di errore che consentono di identificare un problema di compatibilità. È anche possibile usare Monitoraggio processi per identificare i problemi. I problemi comuni si riferiscono ai presupposti dell'applicazione riguardanti le autorizzazioni sia per la directory di lavoro che per il percorso del programma.

Uso del Monitoraggio Processi per identificare un problema

Monitoraggio processi è un'utilità potente per osservare le operazioni di file e registro di un'app e i relativi risultati. Ciò consente di comprendere i problemi di compatibilità delle applicazioni. Dopo aver aperto Process Monitor, aggiungere un filtro (Filtro > Filtro...) per includere solo gli eventi dell'eseguibile dell'applicazione.

Filtro app ProcMon

Verrà visualizzato un elenco di eventi. Per molti di questi eventi, la parola SUCCESS verrà visualizzata nella colonna Risultato .

Eventi ProcMon

Facoltativamente, è possibile filtrare gli eventi in modo da visualizzare solo gli errori.

ProcMon Exclude Success

Se si sospetta un errore di accesso al file system, cercare gli eventi non riusciti che si trovano nel percorso System32/SysWOW64 o del file del pacchetto. Anche i filtri possono essere utili anche qui. Iniziare nella parte inferiore dell'elenco e scorrere verso l'alto. Gli errori visualizzati nella parte inferiore di questo elenco si sono verificati più di recente. Prestare la maggior parte dell'attenzione agli errori che contengono stringhe come "accesso negato" e "percorso/nome non trovato" e ignorare gli elementi che non sembrano sospetti. PSFSample presenta due problemi. È possibile visualizzare questi problemi nell'elenco visualizzato nell'immagine seguente.

ProcMon Config.txt

Nel primo problema visualizzato in questa immagine, l'applicazione non riesce a leggere dal file "Config.txt" che si trova nel percorso "C:\Windows\SysWOW64". È improbabile che l'applicazione stia tentando di fare riferimento direttamente a tale percorso. È molto probabile che stia tentando di leggere da tale file usando un percorso relativo e, per impostazione predefinita, "System32/SysWOW64" è la directory di lavoro dell'applicazione. Ciò suggerisce che l'applicazione prevede che la directory di lavoro corrente sia impostata su un punto qualsiasi del pacchetto. Guardando all'interno dell'appx, è possibile vedere che il file esiste nella stessa directory del file eseguibile.

Config.txtdell'app

Il secondo problema viene visualizzato nell'immagine seguente.

File di log ProcMon

In questo problema, l'applicazione non riesce a scrivere un file .log nel percorso del pacchetto. Ciò suggerisce che una correzione del reindirizzamento di file potrebbe essere utile.

Passaggio 2: Trovare una correzione di runtime

Psf contiene correzioni di runtime che è possibile usare in questo momento, ad esempio la correzione del reindirizzamento dei file.

Correzione del reindirizzamento dei file

È possibile usare l'opzione Correzione reindirizzamento file per reindirizzare i tentativi di scrivere o leggere dati in una directory che non è accessibile da un'applicazione eseguita in un contenitore MSIX.

Ad esempio, se l'applicazione scrive in un file di log che si trova nella stessa directory del file eseguibile dell'applicazione, puoi usare la Correzione di reindirizzamento file per creare tale file di log in un'altra posizione, ad esempio nell'archivio dati dell'app locale.

Correzioni di runtime dalla community

Assicurarsi di esaminare i contributi della community alla pagina GitHub . È possibile che altri sviluppatori abbiano risolto un problema simile al proprio e abbiano condiviso una correzione di runtime.

Passaggio 3: Applicare una correzione di runtime

È possibile applicare una correzione di runtime esistente con alcuni semplici strumenti di Windows SDK e seguendo questa procedura.

  • Creare una cartella di layout del pacchetto
  • Ottenere i file di Package Support Framework
  • Aggiungerli al pacchetto
  • Modificare il manifesto del pacchetto
  • Creare un file di configurazione

Esaminiamo ogni attività.

Creare la cartella di layout del pacchetto

Se si dispone già di un file con estensione msix (o .appx), è possibile decomprimerne il contenuto in una cartella di layout che fungerà da area di gestione temporanea per il pacchetto. Puoi farlo da un prompt dei comandi usando lo strumento MakeAppx, in base al percorso di installazione dell'SDK, qui troverai lo strumento makeappx.exe nel PC Windows 10: x86: C:\Program Files (x86)\Windows Kits\10\bin\x86\makeappx.exe x64: C:\Program Files (x86)\Windows Kits\10\bin\x64\makeappx.exe

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

In questo modo verrà visualizzato un aspetto simile al seguente.

Layout del pacchetto

Se non si ha un file con estensione msix (o .appx) da cui iniziare, è possibile creare la cartella e i file del pacchetto da zero.

Ottenere i file di Package Support Framework

È possibile ottenere il pacchetto NuGet PSF usando lo strumento da riga di comando Nuget autonomo o tramite Visual Studio.

Usa lo strumento da riga di comando per ottenere il pacchetto

Installare lo strumento da riga di comando NuGet da questo percorso: https://www.nuget.org/downloads. Quindi, dalla riga di comando nuget, eseguire questo comando:

nuget install Microsoft.PackageSupportFramework

In alternativa, è possibile rinominare l'estensione del pacchetto in .zip e decomprimerla. Tutti i file necessari si trovano nella cartella /bin.

Ottenere il pacchetto usando Visual Studio

In Visual Studio fare clic con il pulsante destro del mouse sul nodo della soluzione o del progetto e scegliere uno dei comandi Gestisci pacchetti NuGet. Cercare Microsoft.PackageSupportFramework o PSF per trovare il pacchetto in Nuget.org. Quindi, installarlo.

Aggiungere i file di Package Support Framework al pacchetto

Aggiungere le DLL PSF a 32 bit e a 64 bit necessarie e i file eseguibili alla directory del pacchetto. Usare la tabella seguente come guida. È anche necessario includere eventuali correzioni di runtime necessarie. In questo esempio è necessaria la correzione del runtime di reindirizzamento dei file.

L'eseguibile dell'applicazione è x64 L'eseguibile dell'applicazione è x86
PSFLauncher64.exe PSFLauncher32.exe
PSFRuntime64.dll PSFRuntime32.dll
PSFRunDll64.exe PSFRunDll32.exe

Il contenuto del pacchetto dovrebbe ora essere simile al seguente.

File binari del pacchetto

Modificare il manifesto del pacchetto

Aprire il manifesto del pacchetto in un editor di testo e quindi impostare l'attributo Executable dell'elemento Application sul nome del file eseguibile di PSF Launcher. Se si conosce l'architettura dell'applicazione di destinazione, selezionare la versione appropriata, PSFLauncher32.exe o PSFLauncher64.exe. In caso contrario, PSFLauncher32.exe funzionerà in tutti i casi. Ecco un esempio.

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

Creare un file di configurazione

Creare un nome di file config.json e salvarlo nella cartella radice del pacchetto. Modificare l'ID app dichiarato del file config.json in modo che punti all'eseguibile appena sostituito. Usando le conoscenze acquisite utilizzando Process Monitor, è possibile anche impostare la directory di lavoro e utilizzare il meccanismo di reindirizzamento dei file per indirizzare le letture/scritture ai file .log nella directory "PSFSampleApp" relativa al pacchetto.

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

Di seguito è riportata una guida per lo schema config.json:

Array chiave Valore
applicazioni Id Usare il valore dell'attributo Id dell'elemento Application nel manifesto del pacchetto.
applicazioni eseguibile Percorso relativo al pacchetto dell'eseguibile che si desidera avviare. Nella maggior parte dei casi, è possibile ottenere questo valore dal file manifesto del pacchetto prima di modificarlo. È il valore dell'attributo Executable dell'elemento Application .
applicazioni workingDirectory (Facoltativo) Percorso relativo al pacchetto da usare come directory di lavoro dell'applicazione che viene avviata. Se non si imposta questo valore, il sistema operativo usa la System32 directory come directory di lavoro dell'applicazione.
Processi eseguibile Nella maggior parte dei casi, questo sarà il nome dell'oggetto executable configurato in precedenza con il percorso e l'estensione di file rimossi.
aggiustamenti dll Percorso relativo al pacchetto del fixup, .msix/.appx da caricare.
aggiustamenti configurazione (Facoltativo) Controlla il comportamento della dll di correzione. Il formato esatto di questo valore varia in base al fixup per fixup, perché ogni fixup può interpretare questo "blob" come vuole.

Le applicationschiavi , processese fixups sono matrici. Ciò significa che è possibile usare il file config.json per specificare più di un'applicazione, un processo e una DLL di correzione.

Creare un pacchetto e testare l'app

Creare quindi un pacchetto.

makeappx pack /d PackageContents /p PSFSamplePackageFixup.msix

Poi firmalo.

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

Per altre informazioni, vedere come creare un certificato di firma del pacchetto e come firmare un pacchetto usando signtool

Usando PowerShell, installare il pacchetto.

Annotazioni

Ricordarsi di disinstallare prima il pacchetto.

powershell Add-AppPackage .\PSFSamplePackageFixup.msix

Eseguire l'applicazione e osservare il comportamento con correzione di runtime applicata. Ripetere i passaggi di diagnostica e creazione del pacchetto in base alle esigenze.

Verificare se Package Support Framework è in esecuzione

È possibile verificare se la correzione di runtime è in esecuzione. Un modo per eseguire questa operazione consiste nell'aprire Gestione attività e fare clic su Altri dettagli. Trovare l'app a cui è stato applicato il framework di supporto del pacchetto ed espandere i dettagli dell'app per visualizzare altri dettagli. Dovrebbe essere possibile visualizzare che Package Support Framework è in esecuzione.

Usare la correzione della traccia

Una tecnica alternativa per la diagnosi dei problemi di compatibilità delle applicazioni pacchettizzate consiste nell'usare il Trace Fixup. Questa DLL è inclusa in PSF e fornisce una visualizzazione diagnostica dettagliata del comportamento dell'app, simile a Process Monitor. È appositamente progettato per rivelare i problemi di compatibilità delle applicazioni. Per usare Trace Fixup, aggiungere la DLL al pacchetto, aggiungere il frammento seguente al config.jsone quindi creare il pacchetto e installare l'applicazione.

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

Per impostazione predefinita, la correzione della traccia filtra gli errori che potrebbero essere considerati "previsti". Ad esempio, le applicazioni potrebbero provare a eliminare in modo incondizionato un file senza controllare se esiste già, ignorando il risultato. Ciò ha la sfortunata conseguenza che alcuni errori imprevisti potrebbero essere filtrati, quindi nell'esempio precedente si opta per ricevere tutti gli errori dalle funzioni del file system. Questa operazione viene eseguita perché è noto da prima che il tentativo di leggere dal file Config.txt ha esito negativo e viene visualizzato il messaggio "file non trovato". Si tratta di un errore osservato di frequente e non generalmente considerato imprevisto. In pratica è preferibile iniziare a filtrare solo gli errori imprevisti e quindi passare a tutti gli errori se c'è un problema che non è ancora possibile identificare.

Per impostazione predefinita, l'output di Trace Fixup viene inviato al debugger collegato. Per questo esempio, non verrà collegato un debugger e verrà invece usato il programma DebugView da SysInternals per visualizzarne l'output. Dopo aver eseguito l'app, è possibile visualizzare gli stessi errori di prima, che ci inderebbero verso le stesse correzioni di runtime.

File TraceShim non trovato

Accesso negato a TraceShim

Eseguire il debug, estendere o creare una correzione di runtime

È possibile usare Visual Studio per eseguire il debug di una correzione di runtime, estendere una correzione di runtime o crearne una da zero. Dovrai eseguire queste operazioni per avere successo.

  • Aggiungere un progetto di pacchetti
  • Aggiungere un progetto per la correzione di runtime
  • Aggiungi un progetto che avvia l'eseguibile PSF Launcher
  • Configurare il progetto del pacchetto

Al termine, la soluzione avrà un aspetto simile al seguente.

Soluzione completata

Esaminiamo ogni progetto in questo esempio.

Progetto Scopo
DesktopApplicationPackage Questo progetto si basa sul progetto Di creazione pacchetti di applicazioni Windows e restituisce il pacchetto MSIX.
Correzione di runtime Si tratta di un progetto libreria di Dynamic-Linked C++ che contiene una o più funzioni di sostituzione che fungono da correzione di runtime.
PSFLauncher Si tratta di un progetto vuoto C++. Questo progetto è un luogo in cui raccogliere i file distribuibili di runtime di Package Support Framework. Restituisce un file eseguibile. Il file eseguibile è la prima cosa che viene eseguita all'avvio della soluzione.
WinFormsDesktopApplication Questo progetto contiene il codice sorgente di un'applicazione desktop.

Per esaminare un esempio completo che contiene tutti questi tipi di progetti, vedere PSFSample.

Verranno ora illustrati i passaggi per creare e configurare ognuno di questi progetti nella soluzione.

Creare una soluzione di pacchetto

Se non hai già una soluzione per la tua applicazione desktop, crea una nuova Soluzione Vuota in Visual Studio.

Soluzione vuota

È anche possibile aggiungere tutti i progetti di applicazione disponibili.

Aggiungere un progetto di pacchetti

Se non si ha già un progetto di creazione pacchetti di applicazioni Windows, crearne uno e aggiungerlo alla soluzione.

Modello di progetto del pacchetto

Per altre informazioni sul progetto di creazione pacchetti di applicazioni Windows, vedere Creare un pacchetto dell'applicazione usando Visual Studio.

In Esplora soluzioni fare clic con il pulsante destro del mouse sul progetto di creazione del pacchetto, scegliere Modifica e quindi aggiungerlo nella parte inferiore del file di progetto:

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

Aggiungere un progetto per la correzione di runtime

Aggiungere un progetto C++ Dynamic-Link Library (DLL) alla soluzione.

Libreria di correzioni di runtime

Fare clic con il pulsante destro del mouse sul progetto e scegliere Proprietà.

Nelle pagine delle proprietà individuare il campo Standard del linguaggio C++ e quindi nell'elenco a discesa accanto a tale campo selezionare l'opzione ISO C++17 Standard (/std:c++17).

Opzione ISO 17

Fare clic con il pulsante destro del mouse sul progetto e scegliere l'opzione Gestisci pacchetti NuGet dal menu di scelta rapida. Assicurarsi che l'opzione Origine pacchetto sia impostata su Tutti o nuget.org.

Fare clic sull'icona delle impostazioni accanto a tale campo.

Cercare il pacchetto NuGet PSF* e quindi installarlo per questo progetto.

Pacchetto NuGet

Se si vuole eseguire il debug o estendere una correzione di runtime esistente, aggiungere i file di correzione di runtime ottenuti usando le indicazioni descritte nella sezione Trovare una correzione di runtime di questa guida.

Se si intende creare una nuova correzione, non aggiungere ancora nulla a questo progetto. Più avanti in questa guida ti aiuteremo ad aggiungere i file giusti a questo progetto. Per il momento, si continuerà a configurare la soluzione.

Aggiungi un progetto che avvia l'eseguibile PSF Launcher

Aggiungere un progetto vuoto C++ alla soluzione.

Progetto vuoto

Aggiungere il pacchetto NuGet PSF a questo progetto usando le stesse indicazioni descritte nella sezione precedente.

Aprire le pagine delle proprietà per il progetto e nella pagina Impostazioni generali impostare la proprietà Nome destinazione su PSFLauncher32 o PSFLauncher64 a seconda dell'architettura dell'applicazione.

Informazioni di riferimento sul launcher PSF

Aggiungere un riferimento al progetto di correzione del runtime nella soluzione.

Riferimento alla correzione del runtime

Fare clic con il pulsante destro del mouse sul riferimento e quindi nella finestra Proprietà applicare questi valori.

Proprietà Valore
Copiare localmente Vero
Copiare componenti satellite locali Vero
Output dell'assembly di riferimento Vero
Dipendenze della libreria di collegamenti Falso
Input delle dipendenze della libreria di collegamenti Falso

Configurare il progetto del pacchetto

Nel progetto di creazione del pacchetto fare clic con il pulsante destro del mouse sulla cartella Applicazioni e quindi scegliere Aggiungi riferimento.

Aggiungere riferimenti al progetto

Scegliere il progetto PSF Launcher e il progetto di applicazione desktop, quindi scegliere il pulsante OK.

Progetto desktop

Annotazioni

Se non si dispone del codice sorgente della tua applicazione, è sufficiente scegliere il progetto PSF Launcher. Verrà illustrato come fare riferimento al file eseguibile quando si crea un file di configurazione.

Nel nodo Applicazioni fare clic con il pulsante destro del mouse sull'applicazione Launcher PSF e quindi scegliere Imposta come punto di ingresso.

Impostare il punto di ingresso

Aggiungere un file denominato config.json al progetto di creazione del pacchetto, quindi copiare e incollare il testo JSON seguente nel file. Impostare la proprietà Azione pacchetto su Contenuto.

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

Specificare un valore per ogni chiave. Usare questa tabella come riferimento.

Array chiave Valore
applicazioni Id Usare il valore dell'attributo Id dell'elemento Application nel manifesto del pacchetto.
applicazioni eseguibile Percorso relativo al pacchetto dell'eseguibile che si desidera avviare. Nella maggior parte dei casi, è possibile ottenere questo valore dal file manifesto del pacchetto prima di modificarlo. È il valore dell'attributo Executable dell'elemento Application .
applicazioni workingDirectory (Facoltativo) Percorso relativo al pacchetto da usare come directory di lavoro dell'applicazione che viene avviata. Se non si imposta questo valore, il sistema operativo usa la System32 directory come directory di lavoro dell'applicazione.
Processi eseguibile Nella maggior parte dei casi, questo sarà il nome dell'oggetto executable configurato in precedenza con il percorso e l'estensione di file rimossi.
aggiustamenti dll Percorso relativo al pacchetto della DLL di correzione da caricare.
aggiustamenti configurazione (Facoltativo) Controlla il comportamento della DLL di correzione. Il formato esatto di questo valore varia in base al fixup per fixup, perché ogni fixup può interpretare questo "blob" come vuole.

Al termine, il config.json file avrà un aspetto simile al seguente.

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

Annotazioni

Le applicationschiavi , processese fixups sono matrici. Ciò significa che è possibile usare il file config.json per specificare più di un'applicazione, un processo e una DLL di correzione.

Eseguire il debug di una correzione di runtime

In Visual Studio premere F5 per avviare il debugger. La prima cosa che viene avviata è l'applicazione Launcher PSF, che a sua volta avvia l'applicazione desktop di destinazione. Per eseguire il debug dell'applicazione desktop di destinazione, è necessario collegarsi manualmente al processo dell'applicazione desktop scegliendo Debug-Collega> a processo e quindi selezionando il processo dell'applicazione. Per consentire il debug di un'applicazione .NET con una DLL di correzione del runtime nativo, selezionare tipi di codice gestiti e nativi (debug in modalità mista).

Dopo aver configurato questa impostazione, è possibile impostare punti di interruzione accanto a righe di codice nel codice dell'applicazione desktop e nel progetto di correzione del runtime. Se non si dispone del codice sorgente per l'applicazione, sarà possibile impostare punti di interruzione solo accanto a righe di codice nel progetto di correzione del runtime.

Poiché il debug F5 esegue l'applicazione distribuendo file separati dal percorso della cartella del layout del pacchetto, anziché eseguire l'installazione da un pacchetto con estensione msix/.appx, la cartella di layout in genere non presenta le stesse restrizioni di sicurezza di una cartella del pacchetto installata. Di conseguenza, potrebbe non essere possibile riprodurre gli errori di negazione dell'accesso al percorso del pacchetto prima di applicare una correzione di runtime.

Per risolvere questo problema, utilizzare la distribuzione del pacchetto .msix / .appx anziché la distribuzione di file non confezionati tramite F5. Per creare un file di pacchetto con estensione msix/.appx, usare l'utilità MakeAppx di Windows SDK, come descritto in precedenza. In alternativa, dall'interno di Visual Studio fare clic con il pulsante destro del mouse sul nodo del progetto dell'applicazione e selezionare Store - Create App Packages (Store -> Crea pacchetti app).

Un altro problema con Visual Studio è che non dispone del supporto predefinito per il collegamento a processi figlio avviati dal debugger. Ciò rende difficile eseguire il debug della logica nel percorso di avvio dell'applicazione di destinazione, che deve essere collegato manualmente da Visual Studio dopo l'avvio.

Per risolvere questo problema, utilizzare un debugger che supporti l'aggancio di processi figlio. Si noti che in genere non è possibile collegare un debugger JIT (Just-In-Time) all'applicazione di destinazione. Ciò è dovuto al fatto che la maggior parte delle tecniche JIT implica l'avvio del debugger al posto dell'app di destinazione, tramite la chiave del Registro di sistema ImageFileExecutionOptions. In questo modo neutralizza il meccanismo di deviazione usato da PSFLauncher.exe per inserire FixupRuntime.dll nell'app di destinazione. WinDbg, incluso negli strumenti di debug per Windows e ottenuto da Windows SDK, supporta il collegamento di processi figlio. Ora supporta anche l'avvio diretto e il debug di un'app UWP.

Per eseguire il debug dell'avvio dell'applicazione di destinazione come processo figlio, avviare WinDbg.

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

Al prompt WinDbg, abilita il debugging dei figli e imposta i punti di interruzione appropriati.

.childdbg 1
g

(eseguire fino all'avvio dell'applicazione di destinazione e alla sua interruzione nel debugger)

sxe ld fixup.dll
g

(eseguire fino al caricamento della DLL di fixup)

bp ...

Annotazioni

PLMDebug può essere utilizzato anche per collegare un debugger a un'app al momento dell'avvio ed è incluso anche nei Strumenti di debug per Windows. Tuttavia, è più complesso usare rispetto al supporto diretto ora fornito da WinDbg.

Assistenza

Hai domande? Chiedici nello spazio di conversazione Package Support Framework nel sito della community tecnica MSIX.