Is it possible to add an interface implementation to precompiled types at runtime?
-
Hi, This very long post consists of a relatively short question and a lot of background information. Please read at least the question before deciding this isn't worth your time! Question Does anyone know if it's feasible to inject code into a precompiled object at runtime? I suppose it would be quite tricky, but I am not sure since the .NET Framework has surprised me many times by providing easy ways to do previously difficult things! What I want is to have a bunch of objects implement an interface by generating this implementation at run-time. Existing instances (at the time of generating the implementation) of the type would have to be replaced by the generated type, and still be "seen" as the same type (I don't know much about how type checking is implemented in the runtime) by all the other precompiled code. Is this possible? If so, and if anyone knows how to do it, or more likely where I can find the information I need to figure out how to do it, I'd very much appreciate the help. Background If anyone thinks what I am trying to do seems very odd and find themselves thinking there must be better ways to achieve the same, here's that background. The following doesn't really add to my question, although it's possible of course that there is some other way of achieving the result I desire, so I think it's worth including it. I'm toying around with making a fairly general data access framework intended for rapid prototyping purposes. The emphasis is therefore on minimal programming and configuration (for the user of the framework), and sensible default behaviors that would work in most if not all situations but need not be optimal in terms of performance or scalability. However, I find myself thinking if I can achieve this and also get good performance, that would be pretty awesome and make the framework into something far more valuable than just a prototyping tool. I want to completely encapsulate the storage system so it's essentially reduced to exposing just two operations: Load and Save. (Some other types would also be exposed, such as attributes to override default behaviors, a Selection type to specify a subset of objects to load at once, interfaces the entity objects may implement to optimize performance by letting the storage system ask the object if it has changed since it was loaded, and more. But only two operations: Load and Save.) When saving and loading objects I want to do so based on fields, not properties, since the fields always contain th
-
Hi, This very long post consists of a relatively short question and a lot of background information. Please read at least the question before deciding this isn't worth your time! Question Does anyone know if it's feasible to inject code into a precompiled object at runtime? I suppose it would be quite tricky, but I am not sure since the .NET Framework has surprised me many times by providing easy ways to do previously difficult things! What I want is to have a bunch of objects implement an interface by generating this implementation at run-time. Existing instances (at the time of generating the implementation) of the type would have to be replaced by the generated type, and still be "seen" as the same type (I don't know much about how type checking is implemented in the runtime) by all the other precompiled code. Is this possible? If so, and if anyone knows how to do it, or more likely where I can find the information I need to figure out how to do it, I'd very much appreciate the help. Background If anyone thinks what I am trying to do seems very odd and find themselves thinking there must be better ways to achieve the same, here's that background. The following doesn't really add to my question, although it's possible of course that there is some other way of achieving the result I desire, so I think it's worth including it. I'm toying around with making a fairly general data access framework intended for rapid prototyping purposes. The emphasis is therefore on minimal programming and configuration (for the user of the framework), and sensible default behaviors that would work in most if not all situations but need not be optimal in terms of performance or scalability. However, I find myself thinking if I can achieve this and also get good performance, that would be pretty awesome and make the framework into something far more valuable than just a prototyping tool. I want to completely encapsulate the storage system so it's essentially reduced to exposing just two operations: Load and Save. (Some other types would also be exposed, such as attributes to override default behaviors, a Selection type to specify a subset of objects to load at once, interfaces the entity objects may implement to optimize performance by letting the storage system ask the object if it has changed since it was loaded, and more. But only two operations: Load and Save.) When saving and loading objects I want to do so based on fields, not properties, since the fields always contain th
No, you can't; yes, a workable solution could be found, probably with Reflection. If you are talking about encapsulating a database, how will you specify the details of that?
dojohansen wrote:
I want to do so based on fields, not properties, since the fields always contain the true state of the object
That would needlessly limit which types you could use. You also need to understand more about generics -- you don't need the objectManagers Dictionary.
-
No, you can't; yes, a workable solution could be found, probably with Reflection. If you are talking about encapsulating a database, how will you specify the details of that?
dojohansen wrote:
I want to do so based on fields, not properties, since the fields always contain the true state of the object
That would needlessly limit which types you could use. You also need to understand more about generics -- you don't need the objectManagers Dictionary.
Thanks for trying. Unfortunately I disagree with what little you had to contribute. Basing it on fields doesn't in any way constrain what types can be used. Fields *are* the entire state of any object. Properties often reflect state, but far from always, and they need not be writeable and indeed often should not be. As for reflection, that would be easy, but not performant. The point of my post was I already know how to do this with reflection, but I want to avoid it and do something fast instead. I'm now wondering if I can use dynamc methods built using reflection.emit. Then I would not need to modify any existing type, merely to generate a type which accesses the private fields of another type. It must be possible some way or another, since FieldInfo.GetValue can do it...! Don't know what IL to emit though. Perhaps if I cache the fieldinfo instances performance won't suffer too much and reflection alone will do..?
-
Thanks for trying. Unfortunately I disagree with what little you had to contribute. Basing it on fields doesn't in any way constrain what types can be used. Fields *are* the entire state of any object. Properties often reflect state, but far from always, and they need not be writeable and indeed often should not be. As for reflection, that would be easy, but not performant. The point of my post was I already know how to do this with reflection, but I want to avoid it and do something fast instead. I'm now wondering if I can use dynamc methods built using reflection.emit. Then I would not need to modify any existing type, merely to generate a type which accesses the private fields of another type. It must be possible some way or another, since FieldInfo.GetValue can do it...! Don't know what IL to emit though. Perhaps if I cache the fieldinfo instances performance won't suffer too much and reflection alone will do..?
-
Thanks for trying. Unfortunately I disagree with what little you had to contribute. Basing it on fields doesn't in any way constrain what types can be used. Fields *are* the entire state of any object. Properties often reflect state, but far from always, and they need not be writeable and indeed often should not be. As for reflection, that would be easy, but not performant. The point of my post was I already know how to do this with reflection, but I want to avoid it and do something fast instead. I'm now wondering if I can use dynamc methods built using reflection.emit. Then I would not need to modify any existing type, merely to generate a type which accesses the private fields of another type. It must be possible some way or another, since FieldInfo.GetValue can do it...! Don't know what IL to emit though. Perhaps if I cache the fieldinfo instances performance won't suffer too much and reflection alone will do..?
dojohansen wrote:
need not be writeable
Fields may not be writable either (or even readable), and indeed often should not be. My point is that if you support both fields and properties, you support a greater number of types.
dojohansen wrote:
As for reflection, that would be easy, but not performant
If it's the only way, then it's the fastest way.
dojohansen wrote:
cache the fieldinfo instances
That's what I would do.
-
dojohansen wrote:
need not be writeable
Fields may not be writable either (or even readable), and indeed often should not be. My point is that if you support both fields and properties, you support a greater number of types.
dojohansen wrote:
As for reflection, that would be easy, but not performant
If it's the only way, then it's the fastest way.
dojohansen wrote:
cache the fieldinfo instances
That's what I would do.
Fields being nothing more than a portion of memory corresponding to a part of a type value, it is *always* writeable. A constant (literal) isn't writeable, but a field ultimately is. At least I believe readonly fields is nothing more than a compile-time check, and not some run-time check of whether the code attempting to access a field is allowed to do so.
-
Fields being nothing more than a portion of memory corresponding to a part of a type value, it is *always* writeable. A constant (literal) isn't writeable, but a field ultimately is. At least I believe readonly fields is nothing more than a compile-time check, and not some run-time check of whether the code attempting to access a field is allowed to do so.
dojohansen wrote:
it is *always* writeable
Nope. And are you planning to write to private fields? I don't recommend that.
dojohansen wrote:
At least I believe readonly fields is nothing more than a compile-time check
Try it. P.S. I just tried it and it worked! :wtf:
modified on Wednesday, November 4, 2009 9:47 PM