[C#] Embedded Resource benaderen op basis van URI

[Mephix]

Ik heb een configuratie bestand met een stapel URI's naar embedded resource bestanden, dus in de vorm:

<RootNamespace>.<SubNamespace>.<SubNamespace>.<Filename>.<Extension>

Normaal gesproken zou je met Assembly.GetExecutingAssembly en vervolgens met GetManifestResourceStream de embedded resource kunnen benaderen. In deze situatie kan de embedded resource file echter ook in een andere assembly zitten.

Ik zal die dus waarsch. moeten openen met Assembly.Load("AssemblyName"), maar ik heb de assembly naam niet tot mijn beschikking.

Ik mag er vanuitgaan in deze situatie dat de root namespace hetzelfde is als de assembly naam, maar ook daarmee ben ik er nog niet. Ik weet namelijk niet welk deel van de totale URI ik kan gebruiken als naam van de assembly... Splitten op "." en dan het eerste veld pakken is niet in alle gevallen juist, aangezien sommige assembly's zelf al een punt in de naam hebben.

Een mogelijke oplossing zou zijn door de AppDomain.CurrentDomain.GetAssemblies heen te fietsen, elke afzonderlijke assembly open te trekken en op zoek te gaan naar de opgegeven resource. Dit lijkt me alleen niet de meest efficiente manier, dus ben ik op zoek naar een manier waarop dit anders kan.

Is er een functionaliteit waarbij ik de resource rechtstreeks op URI benaderen, of de assembly naam op basis van de URI kan achterhalen ?

[Niemand_Anders]

Maar wat ik niet begrijp is dat een object uit assembly A probeert een resource te lezen uit assembly B.
Maar misschien is de volgende workaround iets?

Schrijf alle embedded resources naar een bepaalde directory. In die directory moet je dan de volledige naam aanhouden. Dit path kun je instellen in (web|app).config.

Op het moment dat je de resource dan nodig hebt, haal je hem niet uit de assembly, maar uit die directory.

Het enigste wat je eigenlijk hoeft te doen als je een update hebt geinstalleerd is de resources opnieuw te 'extracten'. Een andere oplossing kan ik zo snel ook niet bedenken.

[ Voor 10% gewijzigd door Niemand_Anders op 06-03-2008 11:47 ]

[Woy]

AppDomain.CurrentDomain.GetAssemblies geeft toch alleen de geladen assemblies weer. Dus dan heb je er nog niet zoveel aan als je de assembly nog moet loaden.

Verder kan je het denk bijna nooit zeker weten in welke assembly het thuis hoort. Bij bijvoorbeeld het volgende voorbeeld

Assembly A: (Bevat de volgende namespaces)
A
A.B
A.C

Assembly A.B: (Bevat de volgende namespaces)
A.B
A.B.D

Nu heb je de volgende uri A.B.MyResouce.ext

Hoe wil je aan de hand van de uri dan bepalen uit welke assembly hij moet komen. Een namespace kan tenslotte in meerder assemblys voorkomen.

[Mephix]

rwb schreef op donderdag 06 maart 2008 @ 12:15:
AppDomain.CurrentDomain.GetAssemblies geeft toch alleen de geladen assemblies weer. Dus dan heb je er nog niet zoveel aan als je de assembly nog moet loaden.

Assembly.Load kan wellicht een verkeerde benadering zijn... de assemblies zijn in ieder geval @ runtime allemaal geladen, dus de resource file die ik nodig heb zit zeker weten in 1 van de assemblies die ik terug krijg van GetAssemblies(); Ik gebruikte Load alleen als alternatief op GetExecutingAssembly om een andere assembly te benaderen.

rwb schreef op donderdag 06 maart 2008 @ 12:15:
Hoe wil je aan de hand van de uri dan bepalen uit welke assembly hij moet komen. Een namespace kan tenslotte in meerder assemblys voorkomen.

Dit vroeg ik mij al af.. of zo'n constructie niet een namespace conflict oid zou opleveren.

Op het moment zien de assembly's er als volgt uit:

Klant.Project.Assembly1
Klant.Project.Assembly2
Klant.Project.Assembly3

En de root namespaces zijn gelijk aan de assembly namen. Er is dus in dit geval geen mogelijkheid dat een bepaalde namespace in meerdere assembly's voorkomt.

Maargoed, ik denk dat het inderdaad lastig wordt, omdat namespace en assembly naam niet per definitie (gedeeltelijk) overeen komen, ookal is dat in ons geval wel zo.

[ Voor 27% gewijzigd door Mephix op 06-03-2008 12:41 ]

[Woy]

Dan zou ik het toch gewoon door de GetAssemblies heenlopen en voordat je de resource probeert te openenn eerst checken of je resource uri start met de AssemblyName.

Ik ga ervanuit dat GetAssemblies en daar de AssemblyName van opvragen niet echt veel overhead heeft, maar anders zou je tijdens het opstarten van je app nog een lijst kunnen maken van AssemblyName, Assembly KeyValue pairs.

Maar als je de uri's toch in een config file hebt zitten, waarom sla je de AssemblyName daar dan niet gewoon bij op. Dan hoef je helemaal niet moeilijk te doen.

[ Voor 17% gewijzigd door Woy op 06-03-2008 12:50 ]

[Mephix]

rwb schreef op donderdag 06 maart 2008 @ 12:48:
Dan zou ik het toch gewoon door de GetAssemblies heenlopen en voordat je de resource probeert te openenn eerst checken of je resource uri start met de AssemblyName.

Ik ga ervanuit dat GetAssemblies en daar de AssemblyName van opvragen niet echt veel overhead heeft, maar anders zou je tijdens het opstarten van je app nog een lijst kunnen maken van AssemblyName, Assembly KeyValue pairs.

Ja, dit is voor nu op de oplossing die ik heb gebruikt.. dus door de GetAssemblies heen loopen (zijn natuurlijk ook de assemblies van het framework zelf, dus wordt al snel een aardige lijst) en dan met een indexof kijken of de naam van de assembly in de namespace van de embedded resource file terugkomt. Dit is niet waterdicht, aangezien een namespace dus nog kan verschillen van de assembly name. Misschien is het dan nog beter om per assembly te kijken of daarin de file bestaat.. maargoed, wellicht dat ik dat nog aanpas.

rwb schreef op donderdag 06 maart 2008 @ 12:48:
Maar als je de uri's toch in een config file hebt zitten, waarom sla je de AssemblyName daar dan niet gewoon bij op. Dan hoef je helemaal niet moeilijk te doen.

Die config file komt weer uit een ander systeem rollen.. valt natuurlijk ook wel aan te passen, maar valt niet onder mijn afdeling, dus moet dan apart weer aangevraagd worden.. en waarschijnlijk zal die aanpassen meer tijd kosten.

[Woy]

Mephix schreef op donderdag 06 maart 2008 @ 14:38:
[...]
Ja, dit is voor nu op de oplossing die ik heb gebruikt.. dus door de GetAssemblies heen loopen (zijn natuurlijk ook de assemblies van het framework zelf, dus wordt al snel een aardige lijst) en dan met een indexof kijken of de naam van de assembly in de namespace van de embedded resource file terugkomt. Dit is niet waterdicht, aangezien een namespace dus nog kan verschillen van de assembly name. Misschien is het dan nog beter om per assembly te kijken of daarin de file bestaat.. maargoed, wellicht dat ik dat nog aanpas.

Dat het een aardige lijst is is natuurlijk niet zo belangrijk, zeker niet zolang je niet tegen performance problemen oploopt.

Die config file komt weer uit een ander systeem rollen.. valt natuurlijk ook wel aan te passen, maar valt niet onder mijn afdeling, dus moet dan apart weer aangevraagd worden.. en waarschijnlijk zal die aanpassen meer tijd kosten.

Toch is dat IMHO de enige juiste oplossing. In assembly A zou theoretisch ook Resource B.File.Ext kunnen zitten. Mischien zou het zelfs kunnen dat er 2 assemblies zijn met dezelfde resource ( Weet niet zeker of dat mag, en het zal waarschijnlijk ook niet voorkoment maar toch )

[ Voor 47% gewijzigd door Woy op 06-03-2008 15:16 ]

[DrDelete]

met reflector kun je de gecompileerde assembly analyseren, je ziet dan gelijk onder welke namespace je de load moet uitvoeren.