Practical Reflection in .NET

Dynamic Loading with Configuration
Now that we've seen a bit about what Reflection can do, let's take a look at how we can make practical use of it in our applications. We'll see how we can very easily create classes dynamically by loading assemblies at Runtime. This is all possible because of the features that Reflection offers us. Reflection has several drawbacks that we've already seen primarily around speed and safety. We'll mitigate these issues by limiting our user Reflection to only the areas where we actually need it. For everything else, we'll simply use the best practices that we should already be incorporating into our applications. On this part of the journey, we'll look a scenario where we dynamically load types based on configuration and once we've done that, we'll add some generic type parameters to see how that impacts our Reflection code.

Discovering Types in Assemblies
We've seen how we can use Reflection to create classes dynamically based on an assembly-qualified name. This assumes that we know the name of the type that we're looking for, but what if we don't know the name of the type? We can actually use Reflection to discover the types that are available in an assembly, and that's what we'll look at here. You might be wondering why we would want to do something like this. One scenario is to make it very easy to extend our application. In fact, our scenario will show how our clients can add functionality to our application without recompiling the application itself. We'll learn a few more features that Reflection offers. We'll use these in combination with the features we've already learned about, to create an extensible, dynamic application. We'll start by looking at a scenario that will benefit from type discovery. Then, we'll look at the features of Reflection that will help us implement the behavior. Then we'll jump right into the code and see all of these features working together.

Should I Be Worried?
We've only looked at a few features of Reflection, but some of these features leave us a bit worried. Reflection makes it very easy to get information out of our assemblies, even things that we have marked as private. Does this mean we really shouldn't be using. NET? Absolutely not. Reflection does make it easy to look inside. NET assemblies, but this is really no different than what a determined hacker can do with programs in other environments. It just means that we need to take a bit of care regarding where we put our confidential information and this is something that we should be doing anyway. This is the last stop on our journey. We'll take a look at a few things that will probably scare us, such as when we see how easy it is to access a password that is compiled into our code and we should be scared a little bit. This will make use more vigilant and we will think more carefully about where we keep our sensitive information. By the time we're done, we'll have some good strategies for making sure our confidential information stays confidential.