Not
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
Instansen AssemblyLoadContext.Default ansvarar för att hitta en sammansättnings beroenden. Den här artikeln beskriver AssemblyLoadContext.Default-instansens undersökningslogik.
Värdens inställda probningsegenskaper
När programkörningen startas tillhandahåller körvärden en uppsättning namngivna sökegenskaper som konfigurerar AssemblyLoadContext.Default sö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 | Description |
|---|---|
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 myapp<->.deps.json filen 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.
Anmärkning
Miljövariabeln DOTNET_ADDITIONAL_DEPS och kommandoradsalternativet --additional-deps gäller endast för ramverksberoende program.
Dessa alternativ ignoreras för fristående program.
Mer information finns i Framework-beroende eller fristående distributioner.
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 ser jag 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 felsöker jag undersökningsattributens konstruktion?
.NET Core-värdprocessen skriver ut användbara spårningsmeddelanden när vissa miljövariabler är aktiverade.
| Miljövariabel | Description |
|---|---|
DOTNET_HOST_TRACE=1 |
Aktiverar spårning. |
DOTNET_HOST_TRACEFILE=<path> |
Spårar till en filsökväg istället för standardvägen stderr. |
DOTNET_HOST_TRACE_VERBOSITY |
Anger verbositeten från 1 (lägst) till 4 (högsta). |
Mer information finns i DOTNET_HOST_TRACE miljövariabler.
Standardavsökning för hanterade assemblyer
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_PATHSmed vanliga filnamnstillägg.
Undersökning av satellitmontering (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.
Ej hanterad (inbyggd) avsökning av bibliotek
Körningsmiljöns ohanterade biblioteksundersökningsalgoritm ä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.
Kontrollera om det angivna biblioteksnamnet representerar en absolut eller relativ sökväg.
Om namnet representerar en absolut sökväg använder du namnet direkt för alla efterföljande åtgärder. Använd annars namnet och skapa plattforms-definierade kombinationer att överväga. 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 avsnittet inläsning av inbyggda bibliotek.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 referensen till det laddade biblioteket.
Lägg till den i varje sökväg som anges i
NATIVE_DLL_SEARCH_DIRECTORIESegenskapen 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.
Ange att det biblioteket misslyckades med att laddas.