[VB.NET] Dynamisch assemblies laden dmv. AppDomain's

[Mikej0h]

In mijn huidige applicatie wil ik een assembly laden die gebruikt gaat worden voor het vertalen van objecten (zie het als een DTO XLT).
Deze assemblies bevatten de business logica, en de verwerkende engine gaat hiervan gebruik maken.

De mogelijkheid bestaat nu om assemblies die vervangen moeten worden (bijvoorbeeld omdat er een nieuwe versie beschikbaar is) op "IsMaintenance = True" te zetten.
Door de module deze status te geven (via de database) wordt vervolgens die logica uitgeschakeld en niet meer gebruikt.

Om dit te bewerkstelligen, had ik het idee de assemblies te laden dmv. een losse AppDomain.
Tenslotte kan je een assembly niet ontkoppelen op het moment dat deze inmiddels is geladen in de CurrentDomain (de DefaultAppDomain).

Het probleem waar ik tegen aan blijf lopen, is dat na het aanmaken van een nieuwe verse AppDomain en daar vervolgens een assembly in laad, er ook een referentie wordt gemaakt naar de CurrentDomain.
Dat betekend, dat als ik een AppDomain.Unload uitvoer de verse AppDomain wordt verwijderd, maar ik de assembly nog niet kan overschrijven/verwijderen omdat deze nog in gebruik is.

Omdat ik inmiddels toch al bijna 2 dagen hiermee zoet ben, en ik er duidelijk niet uitkom, toch maar besloten het hier te posten op GoT. Ik kan toch niet de enige zijn die tegen dit probleem aanloopt?

Ik maak gebruik van een LoaderClass, die de werkelijke assembly moet gaan laden, en mij het resultaat via een interface te retourneren.
Door middel van de cur & prev variabelen kan ik nu verifieren dat in de CurrentDomain op basis van onderstaande code de referentie van de net geladen assembly staat (loadedAssembly) als in de childDomain.

Visual Basic .NET:

<Serializable()>
Public Class LoaderClass
    Public Function Load(ByVal assemblyLocation As String, _
                         ByVal assemblyName As String) As IMessage
        If assemblyLocation = String.Empty Then
            Throw New NotImplementedException())
        End If

        Dim childDomain As AppDomain = AppDomain.CreateDomain(assemblyName)
        Dim loadedAssembly as Reflection.Assembly = childDomain.Load(Reflection.AssemblyName.GetAssemblyName(assemblyLocation))

        Dim cur() As Assembly = childDomain.GetAssemblies()
        Dim prev() As Assembly = AppDomain.CurrentDomain.GetAssemblies()

        Return Nothing ' (Other logic will be in place later)
    End Function
End Class

In een andere class in de applicatie roep ik vervolgens deze functie aan:

Visual Basic .NET:

Dim loader As New LoaderClass()
Dim loadedAssembly As IMessage = loader.Load(routing.TargetSystem.Assembly, _
                                             routing.TargetSystem.Name)

Wie kan mij een trap in de juiste richting helpen, want ik ben inmiddels het spoor zoek?!

[pedorus]

http://stackoverflow.com/...embly-at-runtime-with-net doorgenomen?

Maar eigenlijk vraag ik me af waarom je dit niet met een meer service-achtige architectuur zou doen

[Mikej0h]

pedorus schreef op woensdag 13 juni 2012 @ 15:36:
http://stackoverflow.com/...embly-at-runtime-with-net doorgenomen?

Maar eigenlijk vraag ik me af waarom je dit niet met een meer service-achtige architectuur zou doen

Dank voor je link (maar had ik al gehad in het afstruinen van Google), er is hier bewust gekozen om MEF niet te gebruiken.
Betreft het gebruik van DoCallback lost het probleem niet op (reeds geprobeerd).

Het probleem is juist dat er een referentie naar de 'parent' AppDomain wordt gelegt, terwijl deze helemaal niet aanwezig zou mogen zijn (ik maak tenslotte een nieuwe aan!).
Wellicht zie ik iets over het hoofd...

Deze applicatie (= Windows Service) doet queuing (via de DB) naar een externe partij. Een aflevergarantie is daarbij dan ook een verplichting.
Om dit alleen met bv. webservices op te lossen dat gaat niet werken (je brengt meer schakels in de keten aan en een hoop latency), ik denk dat de oplossing die we nu gebouwd hebben eigelijk best prima in elkaar zit (op dit stukje na), geld voor een pakket als BizTalk is er binnen de organisatie niet.