As a quick answer, I would answer: better forget it.
However, there are couple of remote possibilities related to
System.Reflection.Emit. You can generate (emit) a whole assembly during runtime and use it. Alternatively, you can add a separate method during run-time, convert it to a delegate instance and call during runtime. Please see:
http://msdn.microsoft.com/en-us/library/system.reflection.emit.aspx[
^],
http://msdn.microsoft.com/en-us/library/system.reflection.emit.dynamicmethod.aspx[
^].
Those approaches are very advanced and are used in some very special cases. One of such models is
serialization, which is agnostic to the data types. If the code always uses
System.Reflection to dig into each type and serialize it, it results in low performance, only acceptable for pretty small object graphs and volume of data. With
System.Reflection.Emit, the reflection is performed only once per type, to serialization code is created on the fly and later reused.
In all those techniques, just the debugging of emitted code is a problem. And the emitting of the code… as a bare minimum, it requires good knowledge of CIL and good understanding of CLR functioning.
So, I would not give you more detail before I can understand your goals and see that you can go this way. Chances are, you can devise much simpler architecture. Something tells me that you don't yet have the elaborate conception of adding the code dynamically and its purpose.
—SA
Submit an article or tip