I am hosting a WCF service where the requirements are that an object, of a type the WCF service is not directly referenced, is invoked and some (common) methods run on it. The type is created via reflection and AssemblyResolve: this is OK.
I then got to thinking -- we are expecting maybe 50 - 100 of these assemblies / types to arrive, especially when we are versioning them. This should presumably bloat (still on theory here rather than practice) the memory and performance of the service host application due all these assemblies being referenced in mem.
As a result, we should unload -- but the only way to do this is via an appdomain. The thinking is that each assembly would somehow run in its own appdomain and the WCF service is actually just passing messages to the appropriate appdomain. If the appdomain is not used for some_period_of_time, then we simply unload the appdomain.
Some guidance would be useful on:
I have no experience in this area. My worries are the size and the performance of the app if I don't do something like this. However, with the app domain idea, this basically sounds like massive over-engineering. The requirement to host this unknown .dlls is not something I can change.
Is this idea as bad as it sounds, and what are the pro's / con's associated with it?
should the process run fine with ~100 assemblies in memory?
You'll have to try (it's easy to create a mock-up) but you're only stuck with the code. So at 1 MB a piece you would be using 100MB of discardable memory, I don't expect a problem.
Provided your instances are released and collected.