AppDomain communication and performance

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:

1. is this an insane idea?
2. should the process should run fine with ~100 assemblies in memory?
3. communication with appdomains would presumably come at some cost (via rem开发者_运维百科oting / named pipes): does this disqualify the idea?
4. creating an appdomain to basically service one type of .dll would involve many appdomains; is this a bad idea?

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.

If you have the memory available and want better performance, you can either wait until the first call is made and the assemblies will be loaded lazily (subsequent calls will be faster), or if you don't want any slow calls made, then you could eager load the assemblies when the service starts. I don't see a reason to load/unload the assemblies on each call when memory is cheap. If you notice a performance problem, then I'd say think about unloading the assemblies when they're not being used.

This is essentially what IIS App Pools and Worker Processes do. Probably not insane, but there's a lot of room for implementation here that could lead to happy or unhappy results.