5

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?

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673

1 Answers1

3

Depending on what you're trying to do, it's simpler.

IIS will automagically restart its app pool when it sees that a file has changed. If all you're looking to do is patch a running server, just push a new dll and let the app pool cycle.

Will this fail because I haven't unloaded the app domain that the original DLL from which the original type was loaded?

If your old DLL and your new DLL have the same version, I am pretty sure they will do very bad things. While I thought that types with the same fully qualified name but different versions would play nice - it looks as though that is not the case.

what am I missing?

One thing to be concerned with is that loading from configuration tends to be an expensive operation - one that is cached, either by your code or by some underlying API. Relying on the factory to see the new target is likely a quick and easy source of subtle bugs. There's also concurrency issues where your code may assume that consecutive calls to Factory.Create returns the same concrete type.

But in the end, it will boil down to Activator.CreateInstance.

Community
  • 1
Telastyn
  • 108,850
  • 29
  • 239
  • 365