Share via


Probe predefinito

L'istanza AssemblyLoadContext.Default è responsabile dell'individuazione delle dipendenze di un assembly. Questo articolo descrive la logica di probe dell'istanza di AssemblyLoadContext.Default.

Host configurato per le proprietà di probe

All'avvio del runtime, l'host di runtime fornisce un set di proprietà di probe denominate che configurano i percorsi probe AssemblyLoadContext.Default.

Ogni proprietà di probe è facoltativa. Se presente, ogni proprietà è un valore stringa che contiene un elenco delimitato di percorsi assoluti. Il delimitatore è ';' in Windows e ':' in tutte le altre piattaforme.

Nome proprietà Descrizione
TRUSTED_PLATFORM_ASSEMBLIES Elenco dei percorsi dei file di assembly della piattaforma e dell'applicazione.
PLATFORM_RESOURCE_ROOTS Elenco dei percorsi di directory in cui cercare gli assembly di risorse satellite.
NATIVE_DLL_SEARCH_DIRECTORIES Elenco dei percorsi di directory in cui cercare librerie non gestite (native).
APP_PATHS Elenco dei percorsi di directory in cui cercare gli assembly gestiti.

Come vengono popolate le proprietà?

Esistono due scenari principali per popolare le proprietà a seconda che il <file myapp>.deps.json esista o meno.

  • Quando il file *.deps.json è presente, viene analizzato per popolare le proprietà di probe.
  • Quando il file *.deps.json non è presente, si presuppone che la directory dell'applicazione contenga tutte le dipendenze. Il contenuto della directory viene usato per popolare le proprietà di probe.

Inoltre, i file *.deps.json per qualsiasi framework a cui si fa riferimento vengono analizzati in modo analogo.

La variabile di ambiente DOTNET_ADDITIONAL_DEPS può essere usata per aggiungere altre dipendenze. dotnet.exe contiene anche un parametro --additional-deps facoltativo per impostare questo valore all'avvio dell'applicazione.

La proprietà APP_PATHS non viene popolata per impostazione predefinita e viene omessa per la maggior parte delle applicazioni.

È possibile accedere all'elenco di tutti i file *.deps.json usati dall'applicazione tramite System.AppContext.GetData("APP_CONTEXT_DEPS_FILES").

Come è possibile visualizzare le proprietà di probe dal codice gestito?

Ogni proprietà è disponibile chiamando la funzione AppContext.GetData(String) con il nome della proprietà della tabella precedente.

Come si esegue il debug della costruzione delle proprietà di probe?

L'host di runtime .NET Core restituirà messaggi di traccia utili quando alcune variabili di ambiente sono abilitate:

Variabile di ambiente Descrizione
COREHOST_TRACE=1 Abilita la traccia.
COREHOST_TRACEFILE=<path> Esegue le tracce a un percorso di file anziché al valore predefinito stderr.
COREHOST_TRACE_VERBOSITY Imposta il livello di dettaglio da 1 (più basso) a 4 (massimo).

Probe predefinito dell'assembly gestito

Quando si esegue il probe per individuare un assembly gestito, AssemblyLoadContext.Default esamina in ordine:

  • File corrispondenti a AssemblyName.Name in TRUSTED_PLATFORM_ASSEMBLIES (dopo la rimozione delle estensioni di file).
  • File di assembly in APP_PATHS con estensioni di file comuni.

Probe di assembly satellite (risorsa)

Per trovare un assembly satellite per impostazioni cultura specifiche, creare un set di percorsi di file.

Per ogni percorso in PLATFORM_RESOURCE_ROOTS e quindi APP_PATHS, aggiungere la stringa CultureInfo.Name, un separatore di directory, la stringa AssemblyName.Name e l'estensione '.dll'.

Se esiste un file corrispondente, tentare di caricarlo e restituirlo.

Probe della libreria non gestita (nativa)

L'algoritmo di probe della libreria non gestita del runtime è identico in tutte le piattaforme. Tuttavia, poiché il carico effettivo della libreria non gestita viene eseguito dalla piattaforma sottostante, il comportamento osservato può essere leggermente diverso.

  1. Controllare se il nome della libreria fornito rappresenta un percorso assoluto o relativo.

  2. Se il nome rappresenta un percorso assoluto, usare direttamente il nome per tutte le operazioni successive. In caso contrario, usare il nome e creare combinazioni definite dalla piattaforma da considerare. Le combinazioni sono costituite da prefissi specifici della piattaforma (ad esempio, lib) e/o suffissi (ad esempio, .dll, .dylib e .so). Questo non è un elenco completo e non rappresenta l'esatto sforzo fatto su ogni piattaforma. È solo un esempio di ciò che viene considerato. Per altre informazioni, vedere caricamento della libreria nativa.

  3. Il nome e, se il percorso è relativo, ogni combinazione viene quindi utilizzata nei passaggi seguenti. Il primo tentativo di caricamento riuscito restituisce immediatamente l'handle alla libreria caricata.

    • Aggiungerlo a ogni percorso fornito nella proprietà NATIVE_DLL_SEARCH_DIRECTORIES e tentare di caricare.

    • Se DefaultDllImportSearchPathsAttribute non è definito nell'assembly chiamante o in p/invoke o è definito e include DllImportSearchPath.AssemblyDirectory, aggiungere il nome o la combinazione alla directory dell'assembly chiamante e tentare di caricare.

    • Usarlo direttamente per caricare la libreria.

  4. Indica che il caricamento della libreria non è riuscito.