In the current project I'm working on, some of the C# classes are being stored as source code in SQL Server database records, and executed as needed using CSScript. This is being done so that the server doesn't have to be taken down to replace the assembly in which these classes reside.
While this seemed like a good idea in principle, the costs of this scheme have exceeded the benefits on a number of levels, and I am now pursuing other possible remedies.
In the past, when I've needed this kind of "late binding," I've simply used
Activator.CreateInstance() to instantiate and use the types I need. I will typically hide this functionality behind a factory method which uses an XML configuration file to wire up the proper assemblies.
So in my perfect world, when I want to hot patch the server, I will copy the assembly to the server, edit the XML file to refer to the new assembly, and then the next time instances of those types are requested via the factory method, the server will automagically receive instances from the new assembly instead of the old one.
That said, I've never tried this with a running system. I've always used it with a program that is not running, as a sort of poor-man's plugin system. I am aware of things like MEF, but I don't know how MEF applies here, since I've never had to use it.
My question is a simple one: what am I missing? Is this not as simple as I think it is? Will this fail because I haven't unloaded the app domain that the original DLL from which the original type was loaded? Will my algorithm suddenly become Skynet without warning?
In short, is there a better way?