Standardsökning

Instansen AssemblyLoadContext.Default ansvarar för att hitta en sammansättnings beroenden. Den här artikeln beskriver instansens AssemblyLoadContext.Default avsökningslogik.

Värdens konfigurerade avsökningsegenskaper

När körningen startas tillhandahåller runtime-värden en uppsättning namngivna avsökningsegenskaper som konfigurerar AssemblyLoadContext.Default avsökningssökvägar.

Varje avsökningsegenskap är valfri. Om den finns är varje egenskap ett strängvärde som innehåller en avgränsad lista över absoluta sökvägar. Avgränsare är ';' på Windows och ':' på alla andra plattformar.

Egenskapsnamn	beskrivning
TRUSTED_PLATFORM_ASSEMBLIES	Lista över filsökvägar för plattforms- och programsammansättning.
PLATFORM_RESOURCE_ROOTS	Lista över katalogsökvägar för att söka efter satellitresurssammansättningar.
NATIVE_DLL_SEARCH_DIRECTORIES	Lista över katalogsökvägar för att söka efter ohanterade (interna) bibliotek.
APP_PATHS	Lista över katalogsökvägar för att söka efter hanterade sammansättningar.

Hur fylls egenskaperna i?

Det finns två huvudsakliga scenarier för att fylla i egenskaperna beroende på om <filen myapp>.deps.json finns.

• När filen *.deps.json finns parsas den för att fylla i avsökningsegenskaperna.
• När filen *.deps.json inte finns antas programmets katalog innehålla alla beroenden. Katalogens innehåll används för att fylla i avsökningsegenskaperna.

Dessutom parsas *.deps.json-filerna för alla refererade ramverk på samma sätt.

Miljövariabeln DOTNET_ADDITIONAL_DEPS kan användas för att lägga till ytterligare beroenden. dotnet.exe innehåller också en valfri --additional-deps parameter för att ange det här värdet vid programstart.

Egenskapen APP_PATHS fylls inte i som standard och utelämnas för de flesta program.

Listan över alla *.deps.json filer som används av programmet kan nås via System.AppContext.GetData("APP_CONTEXT_DEPS_FILES").

Hur gör jag för att se avsökningsegenskaperna från hanterad kod?

Varje egenskap är tillgänglig genom att anropa AppContext.GetData(String) funktionen med egenskapsnamnet från tabellen ovan.

Hur gör jag för att felsöka avsökningsegenskapernas konstruktion?

.NET Core-runtime-värden matar ut användbara spårningsmeddelanden när vissa miljövariabler är aktiverade:

Miljövariabel	beskrivning
COREHOST_TRACE=1	Aktiverar spårning.
COREHOST_TRACEFILE=<path>	Spårar till en filsökväg i stället för standardinställningen stderr.
COREHOST_TRACE_VERBOSITY	Anger verbositeten från 1 (lägst) till 4 (högsta).

Standardsökning för hanterad sammansättning

Vid avsökning för att hitta en hanterad sammansättning, AssemblyLoadContext.Default söker i ordning på:

• Filer som AssemblyName.Name matchar i TRUSTED_PLATFORM_ASSEMBLIES (efter att filnamnstilläggen har tagits bort).
• Sammansättningsfiler i APP_PATHS med vanliga filnamnstillägg.

Avsökning av satellitsammansättning (resurs)

Om du vill hitta en satellitsammansättning för en specifik kultur skapar du en uppsättning filsökvägar.

För varje sökväg i PLATFORM_RESOURCE_ROOTS och sedan APP_PATHSlägger du till strängen CultureInfo.Name , en katalogavgränsare, strängen AssemblyName.Name och tillägget ".dll".

Om det finns någon matchande fil försöker du läsa in och returnera den.

Ohanterad (intern) avsökning av bibliotek

Körningens ohanterade avsökningsalgoritm för bibliotek är identisk på alla plattformar. Men eftersom den faktiska belastningen för det ohanterade biblioteket utförs av den underliggande plattformen kan det observerade beteendet vara något annorlunda.

1. Kontrollera om det angivna biblioteksnamnet representerar en absolut eller relativ sökväg.

2. Om namnet representerar en absolut sökväg använder du namnet direkt för alla efterföljande åtgärder. Annars kan du använda namnet och skapa plattformsdefinierade kombinationer att tänka på. Kombinationer består av plattformsspecifika prefix (till exempel lib) och/eller suffix (till exempel .dll, .dyliboch .so). Det här är inte en fullständig lista, och den representerar inte den exakta ansträngning som görs på varje plattform. Det är bara ett exempel på vad som beaktas. Mer information finns i inläsning av inbyggda bibliotek.

3. Namnet och, om sökvägen är relativ, används varje kombination i följande steg. Det första lyckade inläsningsförsöket returnerar omedelbart handtaget till det inlästa biblioteket.

   • Lägg till den i varje sökväg som anges i NATIVE_DLL_SEARCH_DIRECTORIES egenskapen och försök att läsa in den.

   • Om DefaultDllImportSearchPathsAttribute antingen inte har definierats för den anropande sammansättningen eller p/invoke eller har definierats och innehåller DllImportSearchPath.AssemblyDirectorylägger du till namnet eller kombinationen i den anropande sammansättningens katalog och försöker läsa in.

   • Använd det direkt för att läsa in biblioteket.

4. Ange att biblioteket inte kunde läsas in.