Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
What is the reflection?
- Thread starter ronenhm
- Start date
It's a mechanism where any .NET application/assembly can interrogate the internal workings of another application/assembly to find out what classes, methods, properties etc that class has.
It has enourmous benefits in enabling a program to dynamically create classes in other assemblies which before it had no knowledge about when it was compiled (within reason of course).
I use reflection in one of my apps as a way of providing a plugin facility.
It has enourmous benefits in enabling a program to dynamically create classes in other assemblies which before it had no knowledge about when it was compiled (within reason of course).
I use reflection in one of my apps as a way of providing a plugin facility.
Hi, everybody!
sjc, I have studied reflection lately and I don't understand all its uses. I really wanted to talk to somebody that used reflection.
I understand that you can read the metadata from an assembly, that you can call functions from an assembly loaded at run-time. But why would you use reflection and not a dll?
Also, it would be nice if you could explain how you used reflection to make a plugin.
Thanks a lot.
sjc, I have studied reflection lately and I don't understand all its uses. I really wanted to talk to somebody that used reflection.
I understand that you can read the metadata from an assembly, that you can call functions from an assembly loaded at run-time. But why would you use reflection and not a dll?
Also, it would be nice if you could explain how you used reflection to make a plugin.
Thanks a lot.
ok here goes....
My app is very focused in what it does so it doesn't provide plugins in the Photoshop way of plugins in a way of it altering menu structures, buttons on toolbars etc although of course this would be easy enough to do.
Basically with the main app is an assembly which litterally only houses the plugin interface (it's 1k or something). The plugin assembly references this interface assembly when being created to create the class (obviously conforming to the interface). Now the finished plugin assembly whatever it is is placed in the apps plugin directory.
On App startup, it moves through every file in that directory. Here comes the reflection bit
Using Reflection I scan the potential plugin assembly for any classes that descend from the Interface class.
Once I've found one of those, I call one of the Interface functions (so it has to be there to conform to the interface as you know) which tells the app what capabilities the plugin is capable of performing (ie what sort of event should start this plugin) which I store in my main app.
It's in this function and how you store the details that you could add toolbars, menus etc.
So whenever a plugin needs to be invoked, I check my list of external plugins, open the appropriate assembly and create the necessary class and then run the appropriate method of that class to satisfy the app request.
I'm not so sure this mechanism would work for all types of plugin scenarios but for mine it works perfectly.
I wrote this same app in C++ and again in Delphi and in those instance of course Refelection wasn't possible so I had to use DLL's. It worked fine but having to create handles, function pointers, callbacks, loading and freeing the library was a lot more work. Also in the Dll scenario I was hitting every dll in the plugin directory with my 'are you a plugin?' query function which worked most times but of course you had to handle some exceptions for a non-plugin dll..not tough but again more work.
Also in the Reflection scenario I can query for exactly the class I'm interested in and because it's implmenting an interface I know exactly what it can and can't do and even if I had decided not to use an interface, I could have used reflection again to determine exactly what the plugin could do or not do...that's the beauty of it.
HTH
My app is very focused in what it does so it doesn't provide plugins in the Photoshop way of plugins in a way of it altering menu structures, buttons on toolbars etc although of course this would be easy enough to do.
Basically with the main app is an assembly which litterally only houses the plugin interface (it's 1k or something). The plugin assembly references this interface assembly when being created to create the class (obviously conforming to the interface). Now the finished plugin assembly whatever it is is placed in the apps plugin directory.
On App startup, it moves through every file in that directory. Here comes the reflection bit
Using Reflection I scan the potential plugin assembly for any classes that descend from the Interface class.
Once I've found one of those, I call one of the Interface functions (so it has to be there to conform to the interface as you know) which tells the app what capabilities the plugin is capable of performing (ie what sort of event should start this plugin) which I store in my main app.
It's in this function and how you store the details that you could add toolbars, menus etc.
So whenever a plugin needs to be invoked, I check my list of external plugins, open the appropriate assembly and create the necessary class and then run the appropriate method of that class to satisfy the app request.
I'm not so sure this mechanism would work for all types of plugin scenarios but for mine it works perfectly.
I wrote this same app in C++ and again in Delphi and in those instance of course Refelection wasn't possible so I had to use DLL's. It worked fine but having to create handles, function pointers, callbacks, loading and freeing the library was a lot more work. Also in the Dll scenario I was hitting every dll in the plugin directory with my 'are you a plugin?' query function which worked most times but of course you had to handle some exceptions for a non-plugin dll..not tough but again more work.
Also in the Reflection scenario I can query for exactly the class I'm interested in and because it's implmenting an interface I know exactly what it can and can't do and even if I had decided not to use an interface, I could have used reflection again to determine exactly what the plugin could do or not do...that's the beauty of it.
HTH
Thank you sjc for your answer. I understood from it that what you did is really nothing new, except that is much easier to use reflection in place of dll's.
I understand also that you could use custom metadata attributes in the plugin assembly that could say "I am a plugin of the type XXX". In this way, you could replace the search for a class derived from Interface with a query for the presence of this attribute. (I am only trying to imagine some other uses for reflection, in this particular case.)
Well, that is interesting. Thank you again for your answer.
I would try another question, though, and this time to anyone who sees this post. Have you ever used the Reflection Emit capability? (basically it means that you can generate assemblies or assemblies parts at run-time). I have only seen one example of it and it seemed very difficult to master. Besides, I was not able to see its uses...
I understand also that you could use custom metadata attributes in the plugin assembly that could say "I am a plugin of the type XXX". In this way, you could replace the search for a class derived from Interface with a query for the presence of this attribute. (I am only trying to imagine some other uses for reflection, in this particular case.)
Well, that is interesting. Thank you again for your answer.
I would try another question, though, and this time to anyone who sees this post. Have you ever used the Reflection Emit capability? (basically it means that you can generate assemblies or assemblies parts at run-time). I have only seen one example of it and it seemed very difficult to master. Besides, I was not able to see its uses...
- Thread starter
- #6
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
- Locked
- Question