Ik keek naar de msdn-documentatie en ik ben nog steeds een beetje in de war over wat precies het verschil is tussen het gebruik van LoadFileen LoadFrombij het laden van een assembly. Kan iemand een voorbeeld of een analogie geven om het beter te beschrijven. De MSDN-documentatie bracht me meer in verwarring. Is ReflectionOnlyLoadFromhetzelfde als LoadFrombehalve dat het de assembly alleen in de reflectiemodus laadt.
Aangezien mijn .NET-ervaring niet de beste is, volgen hier enkele vragen over de MSDN-documentatie met LoadFile:
1) Wat betekent het dat LoadFileassemblages onderzoekt die dezelfde identiteit hebben, maar zich op verschillende paden bevinden? Wat is de identiteit (voorbeeld)?
2) Er staat dat het LoadFilegeen bestanden in de ‘LoadFrom Context’ laadt en afhankelijkheden niet oplost met behulp van het laadpad. Wat betekent dit, kan iemand een voorbeeld geven?
3) Ten slotte stelt het dat LoadFilenuttig is in dit beperkte scenario omdat LoadFrom geen assembly’s kan laden die dezelfde identiteit hebben maar verschillende paden; het laadt alleen de eerste dergelijke assembly, wat me weer bij dezelfde vraag brengt, wat is de identiteit van de assembly?
Antwoord 1, autoriteit 100%
Verduidelijkt dit het?
// path1 and path2 point to different copies of the same assembly on disk:
Assembly assembly1 = Assembly.LoadFrom(path1);
Assembly assembly2 = Assembly.LoadFrom(path2);
// These both point to the assembly from path1, so this is true
Console.WriteLine(assembly1.CodeBase == assembly2.CodeBase);
assembly1 = Assembly.LoadFile(path1);
assembly2 = Assembly.LoadFile(path2);
// These point to different assemblies now, so this is false
Console.WriteLine(assembly1.CodeBase == assembly2.CodeBase);
Bewerken: om de vragen te beantwoorden die je in je herziene vraag hebt gesteld, wil je zeker Suzanne Cook over assemblage-identiteit.
Er zijn veel regels die bepalen hoe assembly’s worden geladen, en sommige hebben te maken met hoe ze afhankelijkheden oplossen – als uw AssemblyA afhankelijk is van AssemblyB, waar moet .NET dan zoeken om AssemblyB te vinden? In de Global Assembly Cache, dezelfde directory als AssemblyA, of ergens anders helemaal? Bovendien, als het meerdere exemplaren van die assembly vindt, hoe moet het dan kiezen welke te gebruiken?
LoadFromheeft één set regels, terwijl LoadFileeen andere set regels heeft. Het is moeilijk om veel redenen voor te stellen om LoadFilete gebruiken, maar als je reflectie op verschillende exemplaren van dezelfde assembly moet gebruiken, is het er voor jou.
Antwoord 2, autoriteit 63%
Van Suzanne Cook’s blog:
LoadFile vs. LoadFrom
Pas op – deze zijn niet hetzelfde
ding.LoadFrom() gaat door Fusion en kan worden omgeleid naar een andere
montage op een ander pad maar met
diezelfde identiteit als die er al is
geladen in de LoadFrom-context.LoadFile() bindt helemaal niet via Fusion – de lader gaat gewoon
vooruit en laadt precies* wat de
beller gevraagd. Het gebruikt niet
ofwel de Load of de LoadFrom
context.Dus, LoadFrom() geeft je meestal wat
waar je om vroeg, maar niet noodzakelijk.
LoadFile() is voor degenen die echt,
wil echt precies wat er gevraagd wordt.
(*Vanaf v2 zal het beleid echter
worden toegepast op zowel LoadFrom() als
LoadFile(), dus LoadFile() niet
noodzakelijkerwijs precies zijn wat was
aangevraagd. Ook, beginnend in v2, als een
assemblage met zijn identiteit is in de
GAC, de GAC-kopie wordt gebruikt
in plaats van. Gebruik ReflectionOnlyLoadFrom()
om precies te laden wat u wilt – maar,
merk op dat assemblages op die manier worden geladen
kan niet worden uitgevoerd.)LoadFile() heeft een addertje onder het gras. Sinds het
gebruikt geen bindende context, het is
afhankelijkheden zijn niet automatisch
gevonden in zijn directory. Als ze dat niet zijn
beschikbaar in de laadcontext, u
zou moeten abonneren op de
AssemblyResolve gebeurtenis om te binden
voor hen.
Zie hier.
Zie ook Een bindende context kiezenartikel op dezelfde blog.
Antwoord 3, autoriteit 46%
Na veel hoofdbrekens heb ik vanmiddag zelf een verschil ontdekt.
Ik wilde een DLL laden tijdens runtime, en de DLL stond in een andere map. Die DLL had zijn eigen afhankelijkheden (DLL’s) die ook in diezelfde map leefden.
LoadFile(): Laad de specifieke DLL, maar niet de afhankelijkheden. Dus toen de eerste oproep werd gedaan vanuit de DLL naar een van die andere DLL’s, gooide het een FileNotFoundException.
LoadFrom(): Laad de DLL die ik heb opgegeven en ook alle afhankelijkheden die in die map stonden.
Antwoord 4, autoriteit 4%
Opmerking: als een assembly wordt geladen met een 8.3-pad en vervolgens vanuit een niet-8.3-pad, worden ze gezien als verschillende assembly’s, ook al zijn het dezelfde fysieke DLL.
Antwoord 5
.NET heeft een andere laadcontext. Suzanne Cook schreef er hier over: https:/ /docs.microsoft.com/en-us/archive/blogs/suzcook/choosing-a-binding-context
Dit is de manier waarop .NET in quarantaine gaat dat referenties niet door elkaar worden gehaald.
Antwoord 6
een verschil dat me is opgevallen is:
Assembly.LoadFile– Laadt assembly in verschillende AppDomain met beperkte gebruikersrechten (principe verschil). bewerkingen zoals serilisatie/deserilisatie konden niet worden uitgevoerd.
Assembly.LoadFrom– Laadt assembly in hetzelfde AppDomain met dezelfde gebruikersrechten (zelfde principe).
Antwoord 7
In mijn geval moest ik gewoon de cache van de ASP-toepassing verwijderen die zich op @ C:\Windows\Microsoft.NET\Framework\[asp version]\Temporary ASP.NET Filesbevindt. Het wordt opnieuw opgebouwd wanneer de site voor het eerst wordt gebruikt. Zorg ervoor dat u IIS eerst stopt.
Ik hoop dat dit iemand helpt zoals het voor mij heeft gedaan.