System.Runtime.Loader.AssemblyLoadContext-klass

Den AssemblyLoadContext representerar en laddningskontext. Konceptuellt skapar en inläsningskontext ett omfång för att läsa in, matcha och eventuellt ta bort en uppsättning sammansättningar.

AssemblyLoadContext finns främst för att ge isolering vid inläsning av sammanställningar. Det gör att flera versioner av samma sammansättning kan läsas in i en enda process. Den ersätter de isoleringsmekanismer som tillhandahålls av flera AppDomain instanser i .NET Framework.

Användning vid körtid

Körningen implementerar två sammansättningsbelastningskontexter:

• AssemblyLoadContext.Default representerar körningens standardkontext, som används för programmets huvudsammansättning och dess statiska beroenden.
• Metoden Assembly.LoadFile(String) isolerar de sammansättningar som den läser in genom att instansiera den mest grundläggande AssemblyLoadContext. Den har ett förenklat isoleringsschema som läser in varje sammansättning på egen hand AssemblyLoadContext utan beroendematchning.

Programanvändning

Ett program kan skapa en egen AssemblyLoadContext för att skapa en anpassad lösning för avancerade scenarier. Anpassningen fokuserar på att definiera beroendelösningsmekanismer.

AssemblyLoadContext tillhandahåller två tilläggspunkter för att implementera hanterad sammansättningslösning:

1. Metoden AssemblyLoadContext.Load(AssemblyName) ger den första chansen för AssemblyLoadContext att lösa, läsa in och returnera sammansättningen. AssemblyLoadContext.Load(AssemblyName) Om metoden returnerar nullförsöker inläsaren läsa in sammansättningen i AssemblyLoadContext.Default.
2. Om det AssemblyLoadContext.Default inte går att lösa sammansättningen får originalet AssemblyLoadContext en andra chans att lösa sammansättningen. Körningen genererar Resolving händelsen.

Dessutom tillåter den AssemblyLoadContext.LoadUnmanagedDll(String) virtuella metoden anpassning av standardlösningen för ohanterad sammansättning. Standardimplementeringen returnerar null, vilket gör att runtime-sökningen använder sin standardpolicy för sökning. Standardsökprincipen räcker för de flesta scenarier.

Tekniska utmaningar

• Det är inte möjligt att läsa in flera versioner av körmiljön i en enda process.

  Försiktighet

  Inläsning av flera kopior eller olika versioner av ramverkssammansättningar kan leda till oväntat och svårdiagnostiserande beteende.

  Tips/Råd

  Använd processgränser med fjärrkommunikation eller kommunikation mellan processer för att lösa det här isoleringsproblemet.

• Tidpunkten för laddning av sammanställningar kan göra tester och felsökning svåra. Sammansättningar läses vanligtvis in utan att deras beroenden omedelbart löses. Beroendena läses in när de behövs:

  • När kod förgrenas till en beroende sammansättning.
  • När koden läser in resurser.
  • När koden explicit läser in sammansättningar.

• Implementeringen av AssemblyLoadContext.Load(AssemblyName) kan lägga till nya beroenden som kan behöva isoleras för att tillåta att olika versioner finns. Den mest naturliga implementeringen skulle placera dessa beroenden i standardkontexten. Noggrann design kan isolera de nya beroendena.

• Samma sammansättning läses in flera gånger i olika kontexter.

  • Detta kan leda till förvirrande felmeddelanden, till exempel "Det går inte att casta objekt av typen "Sample.Plugin" för att skriva "Sample.Plugin".
  • Marshalering över isoleringsgränser är inte enkelt. En vanlig lösning är att använda ett gränssnitt som definierats i en sammansättning som bara läses in i standardinläsningskontexten.