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. So the type is created via reflection and AssemblyResolve: this is OK.
but then i got thinking - that 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.
so then we should unload: but the only way to do this is via an appdomain. the thinking is, that each assembly would somehow run in it's 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.
i'll probably get marked down for this, but 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.
i guess my overall question is:
is this idea as idiotic 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 love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With