[.NET] Controleren of assembly kan worden geladen

[bgever]

Ik wil graag weten of een assembly kan worden geladen door het framework. Van de assembly die ik wil laden weet ik alleen de fullname, welke overeenkomt met de AssemblyName.FullName property. Ik weet dus niet of de assembly in de GAC staat, of in een map die doorzocht wordt op assemblies.

Nu heb ik nergens kunnen vinden of dit gaat. Ik heb wel een oplossing bedacht, maar deze vind ik ronduit omschachtig en vies:
Middels Assembly.Load() de assembly proberen te laden in een eigen AppDomain. Als er geen FileNotFoundException optreedt dan kan de assembly geladen worden. Om de assembly weer uit het geheugen te halen unload ik dan het AppDomain.

Bestaat er een mooie manier om te achterhalen of een assemby (middels de fullname) geladen kan worden?

[bgever]

*kick*

[gorgi_19]

En dmv. File.Exists?

[whoami]

Als het framework jouw assembly niet kan laden, omdat hij de assembly bv niet kan vinden, dan kan je een bepaalde event gaan overriden waarin je dan zelf eea kunt doen...

* whoami ff zoeken...

[whoami]

AssemblyResolve is het event.

[bgever]

Het probleem steekt zo in elkaar: ik moet vóór dat ik een assemby ga laden weten of deze problemen gaat opleveren, omdat referenties naar andere assemblies niet gevonden kunnen worden.

Ik ben namelijk een module framework aan het bouwen, waarbij assemblies in een ZIP archief worden opgeslagen, welke ik packages noem. Zo'n package wordt dus runtime (late binding) geladen middels Reflection. Maar omdat een package afhankelijk kan zijn van een assembly, wil ik dit graag van te voren weten. Dit zal namelijk bepalend zijn voor de laad procedure, die dan de package zal weigeren.

Nu kan ik dus wel middels Reflection er achter komen welke referenties een assembly heeft:

C#:

//Assembly class member:
public AssemblyName[] GetReferencedAssemblies();

Het resultaat hiervan bewaar ik in een metadata bestand die uit de package is op te halen. Hierdoor hoef ik dus niet de assemblies te laden om te achterhalen wat de referenties zijn.

Daarom wil ik dus weten, aan de hand van een AssemblyName, of een assembly geladen kan worden.

Met het AssembyResolve event van AppDomain kan ik enkel een fout opvangen als de package al geladen is en aan het functioneren is.

Ik kan ook niet handmatig alle bestanden gaan nalopen, omdat ik enkel een AssembyName weet. Ik zou anders alle bestanden moeten laden, en de AssembyName controleren, wat dus niet te doen is gezien de performance. Ook moet ik een lastige procedure uitvoeren om te controleren of de assembly in de GAC bestaat.

De vraag is dus; neem ik het voor lief dat de gebruiker een onverwachte onderbreking kan krijgen in het programma doordat er assemblies ontbreken?

Ik heb overigens wel een mogelijkheid om extra ondersteunende assemblies in een package op te nemen die ook geladen worden als de package wordt geladen. Hierdoor kan het probleem al verminderd worden. Echter vind ik het mooier als er een harde check kan plaatsvinden, en hierdoor eventueel kwaad al van te voren vermeden kan worden.

[whoami]

Ik zou zeggen:

als er assemblies ontbreken, is dat een 'onverwachte situatie die normaal gezien niet mag voorkomen'.
Maw: een exceptie.

[bgever]

Ik denk dat ik het daar ook maar op houd. Het was alleen mooi geweest als ik van te voren al deze uitzondering kon opvangen...

Achja, nu maar gewoon hopen dat er fatsoenlijke pluginbuilders zijn.

[bgever]

Zoals je in deze discussie in de microsoft.public.dotnet.framework.clr nieuwsgroep kunt lezen, probeer ik in mijn gebrekig Engels uit te leggen dat ik een oplossing heb gevonden voor mijn probleem.
Om de GoTers hier niet tekort te doen, zal ik het daarom hier ook uitleggen.

Dankzij een url naar een wrapper voor de GAC interfaces van William DePalo, heb ik een mogelijkheid om de GAC te doorzoeken naar een assembly. Ik had zelf ook al wrappers gevonden, maar deze is van betere kwaliteit.

Ik ben zelf tot de ontdekking gekomen dat je met de statische methode AssemblyName.GetAssemblyName() van een .NET assembly de AssemblyName kunt achterhalen daar deze methode een filename string verwacht als argument. Verder wordt de assembly ook niet in het AppDomain geladen.

Nu moet ik nog weten welke assemblies in het bestandssysteem (niet de GAC) de CLR zou proberen te laden. Ik dacht de map die de CLR doorzoekt gevonden te hebben in de AppDomain.BaseDirectory property.
Met al deze gegevens kan ik dus de directory doorzoeken op .dll bestanden, en hiervan de AssemblyName proberen te achterhalen.

Mijn vraag is echter, of dit inderdaad zo is - heb ik dus de juiste map te pakken - en of de CLR de map recursief doorzoekt; dus ook in alle onderliggende mappen?
Als iemand dit kan bevestigen, dan zou dat heel prettig zijn...