Reflection is an extremely powerful feature of .NET. But there is a big difference between what we can do and what we should do. We'll take a quick look at what reflection is capable of and then narrow our focus to practical uses: balancing flexibility, safety, and performance.
Capabilities and Best Practices
Course Overview
Reflection is an extremely powerful feature of .NET, but it's also one of those tools that developers look at and say, when would I ever use that? And I don't disagree with that. When I first saw Reflection, I thought it was really cool and also a bit scary. But I also thought that I would never have a use for it in my applications. It looked like a tool for people who create decompilers and other developer tools. It turned out I was wrong. Even though I don't use many of the features of Reflection, there are several features that I found to be extremely useful and those features are great to have in the toolbox. We'll be focusing on the Practical parts of Reflection, the things that everyday programmers will find useful. Used appropriately, Reflection can add flexibility to our applications fairly easily. But in doing this, we will put an emphasis on safety. With great power comes great responsibility. There are a lot of things we can do with Reflection, a whole lot of things, but many of these things such as manipulating private members are unwise and may cause us pain the future. We'll also be considering Performance. Reflection is extremely slow, compared to making statically bound calls We'll look at some techniques that allow us to get the flexibility of Reflection without sacrificing speed. Everything is give and take and we're looking to find a good balance among the Flexibility, Safety, and Performance. Here's the path that we'll take on our Journey. We'll start with a high-level overview of Reflection. We'll touch on the features and talk about the various capabilities. This will take us into some of the geekier neighborhoods of .NET. Reflection has a lot of very interesting features and for people who want to know how things work internally, it's great to be able to peek inside. These features are extremely powerful and a little bit dangerous. We'll look at the drawbacks to using this functionality and come up with some best practices that will let us use it safely and effectively. We'll put those best practices into action in some sample applications. In the first, we'll use Reflection to load types at runtime. The specific types do not need to be present at complier time and we just need to add some configuration when we want to swap things out. This means that we can have an application that can be easily extended, or customized for our clients. Then we'll add some Generic Types to the application and see how that impacts the way we Reflection. In our next example, we'll take this a step further. Rather than configuring which types to load, our application will look through a folder of assemblies, discover which types are available, and then load up the types that support a specify function. After this, we'll look at some Developer Tools that use Reflection including the Visual Studio Object Browser, disassemblers, and decompilers, mocking libraries, and Dependency Injection Containers. This will help us understand how some of our tools work and this will also show us that there are a lot of great tools already out there. So there's often no need for us to build that functionality ourselves. Finally, we'll alleviate some fears. After seeing what Reflection is capable of, it's easy to become paranoid about our code. Nothing is secret and this may make us want to give up using .NET altogether. But there are some things we can do about this. First, we need to look at things a little more rationally. Things really aren't much more exposed than in other environments and we'll think about some best practices to keep our confidential items confidential. You don't need any previous experience with Reflection or digging into assemblies or intermediate language. We'll cover the things we need, as we go along. This course does assume that you have a good understanding of the basics of C# and .NET including things like Classes, Methods, Properties, Fields, and Access Modifiers. If you've been working with .NET for about a year or so, you'll follow along just fine. The examples we'll show will make use of interfaces. If you're not comfortable with interfaces, you might want to start by viewing the C# Interfaces course, offered by Pluralsight. So let's get started on our journey.
A Bit About .NET Assemblies
We should start out by looking at what Reflection is. Reflection is inspecting the metadata and compiled code inside an assembly. So this leaves us with a few questions. We need to figure out what an assembly is and we need to know what information is contained in the metadata, and we also need to talk a little bit about how .NET code is actually complied. Now, we don't have time to go into all of the details of the .NET assembly infrastructure, but we will take a look at the parts that are relevant to learning about Reflection. An assembly in .NET is a logical unit of deployment, execution, and reuse. This can be either in exe or a dll. If it represents a program that is directly runnable, then it will have the exe extension. If it represents a library that can be used by other programmers, then it will have the dll extension. The term assembly is used to encompass both of these. An assembly consists of one or more independent units called Modules. The main module of an assembly contains the Assembly Manifest. This has things like the assembly name, version, and culture, as well as a catalog of all the Modules contained in the assembly. The Metadata of the Module contains a full description of all of the types exposed including available methods, fields, parameters, constructors and so on. An important part of this Metadata is the IL or Intermediate Language that was compiled from the source code. We'll take a peek at what IL is just a bit. Additionally, assemblies can contain resources. These are things like text files, images, and strings used for localization. Now there is much, much more, we could talk about with regard to .NET assemblies, but that's not why we're here. Reflection works with the Metadata, so we'll concentrate on the Metadata and IL code that is available to us in the assembly. .NET Assemblies are completely self-describing. The assembly has all of the information that the .NET Runtime needs in order to execute the code. This includes information about the assembly itself, other assemblies that have references, all of the types in the assembly, and also the IL code. Here's what the assembly Metadata looks like, well, part of it anyway. Here we can see the Name of the assembly, SampleAssembly and we can also see the Version, which is a rather boring 1.0.0.0. This particular screenshot is taken from IL DASM, which is a tool that's included with the .NET framework. We'll take a closer look at this tool, including how to get this information a little bit later. The Metadata also includes external assembly references. This sample shows a reference to mscorlib, which has the system namespace among others. We can see that in addition to the Name and Version, this also has a Public Key. This is generated when an assembly is strongly named, and we'll talk about strong naming a bit later as well. The Metadata includes type definitions. Here we see a definition for the SampleClass type. Let's drop the original source code in for comparison. The first lines show us the fully qualified name, SampleAssembly.SampleClass. It also tells us that this is a Pubic class and that it descends from the Object type. We also see two Fields listed. The first field is named, dataDate and this is a Private Field of Type DateTime. Wait, did I just say private field, is it really this easy to get to the private members of our classes? The answer is yes. Private fields, methods, and other members are exposed in Metadata and Reflection gives us access to these items. I'm sure that scares you a little bit and it should, but just a little bit. We will spend quite a bit of time talking about the implications of this and some best practices to ensure that our confidential information remains confidential. The Metadata here also shows a second Private Field called cachedItems. This is a generic list and the syntax for the Field Type looks a little strange, but don't worry, we'll be talking about this as we go as well. Probably the most important part of the Metadata is the IL code. The IL is the actual runnable part of the assembly, but what is IL? Here's what a typical property looks like in C#. C# is a high-level language that is designed for humans to read, machines cannot understand it. So C# needs to be complied into something the computer can understand. But .NET takes a step in between. Rather than compiling the source to machine code, the .NET complier generates IL, this is the intermediate language that lives somewhere between human readable code and machine code. If you've worked with Assembly Language or another low level language, this will look familiar. .NET assemblies are complied just in time. This is usually referred to as being JIT compiled. This means that the actual machine code is not generated until we actually run the application. The .NET Runtime takes care of translating the IL into OS method called and ultimately instructions that the CPU can understand. There are a couple advantages to this. Because the code is complied on the machine it is running on, it can be optimized for that particular machine. In addition, only parts of the code that are actually run are complied. So if we end up never loading a particular module, that part of the application just stays in its IL form. IL is definitely one of the geekier parts of .NET. If you like to tinker or look at the insides of things, it's a great place to spend some time and Pluralsight offers a course in MSIL. But most of us are just cranking out applications for our users and this seems like something we would never really want to dive into. But there are useful ways to interact with Metadata through Reflection. Granted there are a lot more features in Reflection that we will use in a normal application, but there are a couple features that are extremely useful. Let's see what Reflection can do with the Metadata that's available in the assemblies.
Features
Based on the Metadata, we can dynamically create types invoke methods, get and set the values of properties and fields, or inspect attributes. The System.Reflection namespace offers classes and methods to perform all of these actions. Here are a few of the major types. Probably the most important is the Type class. This class has over 150 members including, static and instance members and properties. Some of the more common methods include the get methods such as GetType, GetMemberInfo, GetMethodInfo, GetPropertyInfo, and GetFieldInfo. For example, GetMethodInfo returns a MethodInfo object for a particular method. Once we have that, we can reflect further into the method and dynamically invoke it. Another important class is the Activator. Activator has a number of static methods that can be used to dynamically create an instance of a type. Next, we have the Assembly class. We can use this to load an assembly from a file or from the current program context. Once we have an assembly loaded, we can reflect over the types in that assembly to see what types are available. Another interesting class is the ILGenerator. We can use the ILGenerator to create our own IL code. This will give us exactly the IL instructions that we want and we can work with the results in memory or save them off to a file. Now you might be wondering, why would I ever need to generate my own IL? The answer is that you probably won't. There are some specialized cases, but this is generally a feature that we don't have in our day-to-day applications. In fact, many of these features are of limited use unless we're writing developer tools or writing code for extremely specialized scenarios. But there are several features that are useful in our everyday applications and that's where we'll be focusing our efforts. Let's look at a few things that we can do with Reflection and as we'll see, what we can do and what we should do are not always the same thing. For our sample code, we have a class called, SampleClass and this has a Public property called CachedItems. This block of code shows how we can use Reflection to get the value of the CachedItems property. We start by getting a Type object based on our SampleClass. Then we use the GetProperty method to locate CachedItems. This gives us a PropertyInfo object that we can interact with. By using PropertyInfo, we can get information about the property such as the type and attributes and with can also interact with the property by getting or setting the value. Here we called the GetValue method to fetch the value of the CachedItems property. Since this is not a static property, we also need to supply an instance of the SampleClass that has the value that we want. In this case, we have an instance called privateSample and this is what we passed to that method. This seems like a rather convoluted way to get to a property and it is. But there was a time when this was the best way to interact with COM objects. With COM objects, we don't have .NET types that we can refer to directly, so we need to interact with the properties and methods more dynamically. Now, I said there was a time when this was the best way and that's because this is no longer the case. Since we have the dynamic keyword and the DLR, which we got with .NET 4.0, we no longer have to use this type of Reflection to interact with COM objects. It's much easier to use dynamic in those cases. Reflecting on public members doesn't seem very groundbreaking, but we can also reflect on private members as well. Here's an example where we access a private field in a class. Here we get the type for the SampleClass, just like we did before. But now, we're going to interact with the private backing field for the CachedItems property. This is called interalCache. Notice that we call the GetField method and this returns a FieldInfo object. But we've included another parameter on the GetField method. This is a BindingFlags parameter. If we do not include BindingFlags, then we can only see public members. But we can use the BindingFlags, like we do here, to get a non-public member. We also specified that this is an Instance filed as opposed to a static field. After we have the FieldInfo, we can get or set the value. Yes, that is correct. We can directly get the value of a private field and we can update that value as well. Now should we actually do this? Probably not. Interacting with private members is not a good idea and we'll see an example of this in just a bit. Another thing we can do is dynamically run a method. Here's a block of code that shows this. We start by creating a local variable with the type list of integer; this is the instance that we will call the method on. Then we get a type object for the List of int. We'll skip over the parameter types for a moment and go straight to GetMethod. In this case, we want to get the addMethod of the list class. There are actually multiple overloads of add. One takes an object as a parameter and another takes an integer as a parameter. So we need to specify which one we want. This is done with the second parameter of GetMethod. This is a type array that has the types of the parameters for the method that we want to retrieve. Since we want the add method that takes an integer, we need to specify a type array with that one element in it and that is what our parameter's type variable is from the previous line. GetMethod returns a MethodInfo object and once we have this, we can use the Invoke method to dynamically call the method. The parameters of Invoke are the instance that we want to run this on, our list variable, and the parameters for the Add method itself. In this case, we want the call the Add method with a parameter of 7. We'll look at this code a little more closely in upcoming sample. As with properties, using Reflection to dynamically invoke methods is very useful when we're dealing with COM objects in past versions of .NET, but we really should be using the dynamic feature now. Great, so we've seen three really interesting features of Reflection and I've told you not to use them. Now let's look at some features that we can actually use. We can get a CLR type based on a type name. The GetType method on the type class, let's use poke into an assembly and get a type reference. From there, we can interact with the type properties or make any of the calls on the type class, that we've seen so far. This sample here is just the method declaration from the type class. We'll be spending quite a bit of time diving into this code in our upcoming examples, so we'll just stick with the declaration for now. We can also use the Activator class to create an instance of an object based on a type. This is done with the CreateInstance method. This lets us new up an instance of a class even when we do not have a compile time reference to that class. By using these methods, we can dynamically load a type and create an instance of it. Later one, we'll build an application that creates an instance of a specific class, based on configuration. This makes it very easy to swap out functionality without needing to rebuild our application. We'll look at another scenario that will take advantage of some other Reflection features. We can load an assembly based on a file name using the LoadFrom method on the assembly class. This lets use load assembly files from our file system such as loading up all of the dll's in a modules folder. Once we have an assembly loaded, we can use the ExportedTypes property to see all of the public types in the assembly. This is nice and safe since we're only looking at the publicly exposed types and once we have the types, we can look through them to see which ones implement a particular interface. We can use the IsAssignableFrom method on the type class, to check for that. We won't go into specific examples of these just yet. Later on, we'll build an application that dynamically loads business rules from assemblies on the file system. This allows our clients to create custom code that meets their unique business needs. So we've labeled some Reflection features as okay to use and some features as don't use this unless you're really sure what you're doing. Why is this? Well, there are some drawbacks to Reflection. Once we understand those, we can mitigate them in our code. So let's look at some actual Reflection code to see some of the issues that we need to be aware of.
Demo: Drawbacks - Speed
So here we are in Visual Studio and we're going to look at a couple of examples that show the drawbacks to Reflection. For our first example, we're going to do a speed comparison to see if there's difference in performance with Reflection. Here's our application that we'll be doing. Notice we have a couple sets of buttons here. In the first one, we're going to create a List object Normally and that's just by newing up a list. But in the second one, we'll create a List using Reflection by using the Activator class. For our second set of buttons, we're going to call a method. In this case, we'll call the Add method on the list object and again, we'll call it Normally and we'll also use Reflection by using the methodInfo.invoke method. So let's look at the code we have behind before we actually see the performance. And we have this just in the code behind of the Main forum. Inside our events, we have our CreateButtom_Click event handlers. Now in this first method called, StaticCreateButton_Click, we're just going to create a list item the way we normally would and what we're going to do so that we can see time differences, is we're going to do this a lot of times. Normally, this step is happening at the clock cycle level and we wouldn't notice it. So the first thing we do is we get the number of iterations from the textbox in the UI and save it off to a local variable. Then we get the current time. Then we have a for loop and this is going to run this code many, many times. When we look at the code that's inside our loop, we can see that we're just newing up a list of integer and assigning that to a local variable. Once we're done with the for loop, we'll go ahead and capture the endTime so that we can get the difference of how long it takes. In the last line of code, we actually have a method call that will calculate the duration based on the start and end time, and return us a string that we can use in our UI. If we scroll down a little bit to our ReflectButtonCreate_Click, we'll see that we have the same general layout of code, but there are a couple of differences. Notice that we're using the typeof operator to get a type object based on a list of integer. Then, inside of our for loop, we don't new up an instance of list of int, instead we use the Activator to Create an Instance based on the type. So this will actually use Reflection to create an instance of the list. Now we'll do the same DateTime calculations, so we'll be able to tell how long this actually takes. So let's Run our application again and click on our create buttons. If we create the List Normally, you can see that we have about 276 ms and if we actually click this a couple more times, we'll see that number will change just a little bit. The reason we have a little bit of a discrepancy between these is because there's other overhead going on as well. So we don't have a true time of what the actual creation time takes, but we get a general idea based on this. Now notice what happens when we actually create the List using Reflection. We have quite a difference and again, there is a little bit of variation, but there results are fairly consistent. We can see that there's a significant difference in speed between creating objects using Reflection and creating object by simply newing them up directly. What's important to notice is that when we use Reflection, it takes five times longer to create the instances. Now it's true, we are creating 10 million instances here and that's not something we would do in a normal application. In a regular application where we're only creating a handful of instances, the speed differences would be imperceptible. But we always need to be aware of these differences so that we can make sure we're coding appropriately. Since we know that this takes five times longer to do, we probably want to minimize the number of times we do this in our actual code. So now, let's go back to our code and see what it looks like when we want to invoke the members. First, we'll look at our StaticMethodButton_Click. This will just call the Add method normally and again, most of this code looks the same. So we get our iterations from the UI, then we create an instance of a list of integer, then we have our for loop, and inside the for loop we're just going to go ahead and Add the number for whatever item that we're on. So again, in our case, it's actually going to Add 10 million items to our list. Now if we scroll down a bit, we'll see how we call the method with Reflection and this will look very similar to what we saw in our slides earlier. Let's go ahead and walk through this step-by-step. So first, we do create an instance of List of integer and then we'll use the typeof operator to get a type based on that. Now we talked about parameter types before, since the Add method has multiple overloads, we need to tell the system which version we want. So we need to create an array that has the parameter types that we want to use, so it will be able to match it up with the method signature. Now as we noted earlier, Add has two overloads in this case, one that takes an object of parameter and one that take an integer of parameter. So we're going to go ahead and create a parameterTypes variable and this will have typeof int. So that tells us that we want the one with the integer parameter type. Then in the next line of code, we call GetMethod on the type, we pass it in the name of the method that we want, which is Add, along with the parameter types. This will give us a MethodInfo object back and that MethodInfo will be for the Add method that takes an integer as a parameter. Now inside our for loop, we're actually going to call the Invoke method on our method info object. This takes a couple of parameters. The first one is the instance that we want to run this on. So we're using the list object that we created up above. Then we need to pass in the parameters that we want. For this, we're going to pass in an object array and since we just have one parameter it will consist of i, which again is the indexer for our for loop. So this will actually perform exactly the same function as our list.Add method that we have above. But instead of calling it directly on an object, it's going to use Reflection to find and dynamically invoke it. Let's look at the difference in speed on this. Now running our application, if we click Add and just run it normally, it takes about 192 ms and again, if we click this a couple more times, we will see some variation and a lot of that again is just do to other things that are going on, on our system. Now watch what happens when with click Add w/Reflection we're still going to run that add method 10 million times, but this time it takes a lot longer to run. We can see it took 3.5 seconds to actually execute that code; it's 30 times slower to call a method with Reflection, then it is to just call the method normally and again, if we compare this with our List create that we had above, we can see that there are significant differences between making direct calls and using Reflection. Now based on the speed analysis that we have here, and I'm a but reluctant to call it analysis, since we just have a very simple speed test. We can see that Reflection adds quite a bit of overhead and we will want to make sure that we minimize the overhead as much as possible in our applications. Now let's look at another example that shows the dangers of reflecting into private members.
Demo: Drawbacks - Safety
In this scenario, we have a library that we'll reference in our application. Let's pretend that this is a vendor library that we have no control over. Our vendor simply supplies us with the assembly that we can reference in our application. Here's our vendors code. It has a class called SampleClass that has three public members, a constructor, a read-only property containing a list of CachedItems, and a read-only property called dataDate that will tell us how old the data is. Let's walk through this class and see how it works. Now notice, we do have two private fields, one that's dataDate, which is of type DateTime and one to hold our cachedItems, which is a list of string. If we look at our DateTime property, which returns a string, we can see it takes the dataDate field and does ToString on it to return it in a particular format. If we look at our CachedItems property, we see that this is a List of string and what this does is it determines whether it needs to refresh the cache or not. So we can see in the getter that if the cachedItems.count is 0 or our dataDate is more than 5 seconds in the past, we want to actually refresh the cache. Now what happens when we refresh the cache? It's actually fairly simple, we don't really have any real data, we're just storing the current DateTime. So what we do is we update our dataDate field, so that we have an accurate time that tells us how old our data is and then we add the current Time to our cachedItems, the backing field that holds our data. So this means whenever we call cachedItems, the property it will check to see if the data is still valid. If not, it will call RefreshCache and then it will return the cachedItems that we have. Now before we leave this class, let's go ahead and take a look at the constructor and we can see that what it does is initialize our cachedItems backing field that we have, to make sure that it's not null and then it calls RefreshCache, which means when our object gets created, we'll have at least one item in our cachedItems collection. So now that we've seen this, let's flip over to the application that we'll use that will consume this class. Here we have an application that actually uses that SampleClass. If we look in our References, we see we do have a Reference to SampleAssembly. That's the assembly that our vendor provides to us. We don't actually have the source code for it, in this case. Let's run our application to see what we're doing. So here, we can see with have two buttons. In the first one, we're going to interact with this SampleClass by using the Publicly exposed Members. For the second one, we're actually going to use Reflection and we're going to interact with the Private Members. Let's see what the code looks like for this. If we open up the code behind for our form let's take a look at how we're starting up this class. Notice at the top, we have two fields both of type SampleClass, which is the class we're working with. We have one for our publicSample and we have one for our privateSample. This way we can make sure, we have two separate instances of the class so our behavior doesn't overlap. Inside our constructor, we're newing up the instances of the SampleClass and assigning it to both of those private fields. If we scroll down to our Button_Click event handlers, we'll see that our PublicMembersButton_Click interacts with the publicSample field that we have above. The first thing we do is we set the ListBoxes ItemSource to null and that will just clear out the ListBox. Then we reassign that ItemSource to the publicly available CachedItems property that's on our class. So here, we're interacting with the public members just like we normally would and you can see that we also have another textbox filed to hold the DataTime and we're populating that based on our sample classes DataTime property. Finally, we have a CurrentTimeTextBlock and that will just hold whatever time it is right now, so that we can compare it to what's coming back from our class. Now let's contrast this with our PrivateMembersButton_Click event. In this case, the first thing we're doing is we're getting a type based on the SampleClass. So we're using the typeof operator and it's giving us a Type object back. Then, based on that type, we're actually using the GetField method to go in and get the cachedItems, which is that internal backing field and because it's private, we actually need to add the BindingFlags. So again, we have BindingFlags.NonPublic and BindingFlags.Instance. So this says that we want to look for non-public instance members of this class and we would like to get a field back that's named cachedItems. Now this will return to us a FieldInfo object, which we'll call cachedField and then we can call GetValue on that cachedField item. Now we do have to tell GetValue which instance we want to use to get the value from. So we'll pass in that privateSample field that we created in our constructor. So again, what this will do is it will create a type object based on our SampleClass. We'll get the Private field out of that type called cachedItems, then we'll get the value out of our privateSample instance and that will be the value of our cache. Then below that, we're basically performing the same steps that we did above. We're setting the ItemSource to null to clear it out. Then we set the ItemSource to cacheValue, which is the one that we got out of our privateField, and then we're setting the DataTime, as well as the current time. Let's take a look at what this does in our UI. So if we click on Use Public Members, we'll see that we have our current time, as well as the Data Time and since we have a 5 second cache, if we give it a little bit of time and click it again, we'll see that we have another item in our ListBox and our Data Time is updated. If we give it a little bit more time, we'll see that we get another item. But let's compare this to using Reflection. When I click the button the first time, we have the Data Time, but notice that's not the current time. That was actually the time the object was created when we started up this application and if we wait and click the button again, we'll see that this never updates. Why doesn't it update? Well because all of our logic that calculates if we should update our cachedItems, is actually inside of the public properties getter. We're not calling that public property anywhere in this set of code, we're only interacting with the Private Members and this is what happens when we start to rely on non-public members of a class. Because we are interacting with a Private Member, we do not get the behavior that our vendor intends us to have. By accessing the backing field directly, our cache will never be updated. When we do not use the Public Members, we can expect that there may be side effects, but things can get worse. Let's see what happens when our vendor updates the code. For this, we'll flip back to our Sample Assemblies project. So our vendor has decided that they want to make some changes to the code. This could be to optimize performance; it could be to fix bugs, but what they're not doing is changing external interface at all. So if we look at this second version and look at the public members, we see that their almost the same. Now this version no longer has an explicit default constructor, but .NET will generate a default constructor for us and if we look, we still have a public CachedItems and we still have a public DataTime. So to the outside world, this class looks the same as our original version. But the internal functionality has been changed. Notice that the name of our internal backing field has been changed. So it's no longer called cachedItems, now it's called internalCache and some of the code has been moved around as well. Let's take a look at what's happening inside of our CachedItems and our RefreshCache. If we look at our CachedItems property, it's a little bit different. It's checking to see if the internalCache is null. That's a slightly different check then we had before, but it's using the same calculation to see if the current dataDate is more than 5 seconds old. But if we look at our RefreshCache method, we have a little bit of a difference here. In our original class, we were actually creating an instance of our backing field inside the constructor. Since we no longer have that explicit constructor, we need to do is somewhere else. So what our vendor has done is moved it inside of the RefreshCache method. So we can see that part of this checks to see if the internalCache is null, it will go ahead and create a new instance of it. Now the rest of this method is pretty much the same, it will update the dataDate, which is the backing field that shows how old our data is and it will also add the current DateTime to the internalCache. Now even though in our project we're listing this as V2, the version number of the assembly is not actually being updated, it's still 1.0.0.0. Why hasn't our vendor updated the version number? Well the most common practice is to only update version numbers if there are breaking changes or if there's new functionality available. This will let people who are using the existing assembly to simply drop in the replacement dll without making any changes to their code. In our case, the public interface has not changed. The CachedItems property is still there and the dataDate property is still there and technically the default constructor is still there, it's just created automatically by the complier. Since the public functionality has not changed, our vendor has decided to not update the version number. But let's go back to our application and see what happens when we try to use the new assembly. So what we'll do is we'll go to our References and remove the current reference we have the SampleAssmebly and we'll Add in a Reference to the new one and we'll just locate this on the file system. So we'll just go to our SampleAssemblyV2 project and go to the bin Release folder and bring in that dll. So now if we Build our application, we'll see that everything builds just fine, but what happens when we Run our application? Well, if we click the Use Public Members button, everything works exactly the same way it did before. That's because our vendor has not changed the public interface. But what about our code that's accessing the Price Members? Well now, we end up with a Runtime error, why? Because that cachedItems field no longer exists. This cachedItems field has been changed to internalCache, so that means our code broke because it's trying to find a field that doesn't exist. Let's go ahead and update this, and see what happens then. So now, if we run our application again, the button using the Public Members works just fine. But when we use Reflection, we have a 0 value. So we didn't get a Runtime error, but we also don't have any valid data. That's because our vendor has changed how things work internally. RefreshCache is never called the first time. In the version 1, the constructor called RefreshCache so we knew it was called at least 1 time. But because of the internal changes that were made in the second version, that no longer gets called based on the constructor. It gets called when we access the public property for the first time. So again, if we're interacting with the Public Members, as we should, everything continues to work just fine. But when we try to access the Private Members, we may get unexpected results and this is what happens when we start to rely on non-public members of a class. The Private Members should be considered part of the black box. Even though Reflection allows us to see these methods and properties, we should not rely on them. So now that we've seen some of the dangers, let's take a look at some good practices that we can use when incorporating Reflection into our own code.
Best Practices
In the last example, the reason that we ran into unexpected behavior is that we ignored the tenants of Encapsulation. Our classes are black boxes, whatever processes the class uses to accomplish its functions, are encapsulated inside the box. Our classes have clearly defined inputs that are exposed to the outside world. These could be properties or method parameters and they have clearly defined outputs, which could be properties or method return values. As long as we stick with these exposed inputs and outputs, we are just fine. But if we try to dig inside of the black box, we may get unexpected behavior. So we should use the exposed interfaces and not peek inside the box. In the world of Reflection, this means that we should resist any desire to interact with non-public members. We also saw how much slower Reflection can be than direct calls. We can mitigate this issue by referring to one of our best practices, program to an abstraction rather than a concrete type. This often translates into, program to an interface rather than a concrete class. This especially helps us when we're using Reflection. By programming to interfaces, we can have most of our code interacting with the abstraction rather than the dynamically created type and this will help speed things up. Earlier, we saw the features of Reflection that we want to use. Here's the strategy that we'll take in our applications. We want the flexibility to choose functionality at Runtime. So for this we will dynamically load assemblies, but we will make sure that we only load an assembly one time, and we will dynamically load types from those assemblies and again, we want to make sure that we only create these types one time. And here's a really big part of our strategy, once we have a dynamically loaded type, we cast it to an interface that our application already knows about. By doing this, our application makes all method calls through the interface. There are no dynamic calls using MethodInfo.Invoke. This helps us reduce the performance hit that we get from Reflection and since interfaces only have public members, we also avoid interacting with the private members of the class. This makes sure that we avoid the unexpected behavior that we might get from breaking in capsulation. The result is that we limit the use of Reflection to only parts of the application where we absolutely need it. This helps us maximize performance and safety while still maintaining the flexibility that we really want in our application. Now just a quick note about Windows Store Apps. Reflection is quite limited in Windows Store Apps and this makes sense with the philosophy behind them. Windows Store Apps are vetted and sandboxed and the cannot run arbitrary code. Some Reflection features are available, but we are not allowed to access non-public members and as we've noted, this is probably a good thing. Except for very rare cases, we should not be accessing these members anyway. But there's also a limitation in loading assemblies. We cannot load an arbitrary assembly from the file system. All of the assemblies that an application needs have to be included when the package is submitted to the Windows Store. Because of this, it does not really make sense to dynamically load assemblies the way that we're going to do it in our scenarios. We'll implement our scenarios with WPF applications. But these same technologies apply equally well to other client technologies and also to web technologies such as ASP.NET, MVC, and Web Forums.
Summary
We took a bit of a whirlwind tour through the basics of Reflection. We learned a bit about .NET Assemblies including some of the items that are contained at the Metadata and we also saw a little bit of IL code. We'll be exploring this quite a bit more when we look at some developer tools in more detail. We also saw some of the primary features of Reflection. This included some primary classes such as Assembly, Type, Activator, and IL Generator. We saw a couple of examples of how we can use Reflection to dynamically load and create types and also, interact with properties and methods and we looked at some drawbacks as well. Reflection is quite a bit slower than direct calls. In our creation tests, Reflection was five times slower and when we dynamically invoke the method, Reflection was 30 times slower. This gives us some incentive to make sure that we are only using Reflection where we actually need it. We want to make sure our performance does not suffer. Although Reflection gives us the ability to interact with private members, we saw how this is not a very good idea. There may be unexpected behavior and we risk our code breaking if there are any changes to the encapsulated methods or fields. We really want to make sure that we are balancing safety, performance, and flexibility. After reviewing the benefits and drawbacks, we've outlined a basic strategy that limits the use of Reflection while still maintaining the flexibility that we need in our applications. Up next, we'll be putting Reflection to work. We'll look at an application that loads up assemblies at runtime based on configuration. This gives us the flexibility to change functionality of our application, without needing to recompile and we also give our clients only the assemblies that they actually use. So, get ready to look at some code.
Dynamic Loading with Configuration
Overview
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.
Dynamic Loading
I'm a big fan of best practices. This wasn't always the case. As a young developer, I wanted to do things my own way, but now that I'm older and wiser, I like to start by looking at how other developers have been successful. Here's one of my favorite best practices, program to an abstraction rather than a concrete type. In practical terms, this often translates into program to an interface rather than a concrete class. Notice that I did say often, best practices are a great place to start, but we need to understand what's behind them, so that we can make a good decision for the particular problem that we have at hand. If you're not comfortable with interfaces, I recommend the C# Interface course offered by Pluralsight. Our first example is the same one used in the Dynamic Loading section of that course. This time, we're going to focus on the use of Reflection to dynamically create types. Here's our scenario, we have an application that is used by multiple clients. Our clients all have different data sources, these include Relational Databases, NoSQL Databases, Text Files, Services both SOAP and REST, and Cloud Storage and of course, we want to be prepared for other data sources as well. In order to accommodate this, we'll create and abstraction for our application to use. This is the repository, just a way to abstract the data access code from the rest of our application. For our example, we'll have repositories that access a WCF SOAP Service, a CSV File on the local file system, and a SQL Server and the reason that these repositories work with our application is that they adhere to a common interface. This is the abstraction that the application is expecting. As long as the repository implements this interface, it will plug straight into our application. Here's what our repository interface looks like. In this case, we're calling it IPersonRepository and it contains all of the methods that we'll use to interact with our data store. This particular example is known as a CRUD repository, where CRUD stands for Create, Read, Update, and Delete. We have a Create operation in the AddPerson method. We have Read operations in GetPeople, which returns the entire collection. We have Update operations to update an individual or to update the entire collection and we have a Delete operation to delete a particular record from our data store. If you want more information on this repository interface and interfaces in general, you can refer to the C# Interfaces course mentioned earlier. So let's see how the interface is used in our code. Here's what our application code looks like. The important thing here is that we're programming against the interface an abstraction rather than any concrete repository. So we can see that we have a variable that represents an object that implements our interface and since we know that the interface has a method called GetPeople, we can call that method on our local variable. This means that we have no references to concrete repository types in our application code. Instead, we rely on a factor method to supply is with an instance that we can use. That factory method is where we will have the code that uses Reflection. But before we consider using Reflection, we should really ask ourselves if we really need it. As we saw earlier, using Reflection is significantly slower than making direct calls. So we want to see if there are other alternatives that make sense. For our scenario, we're really looking at the difference between compile time binding and Runtime binding for our Repository. Let's take a look at a solution that does not use Reflection. Here's one possibility. We could use configuration to let us know what type of repository we want to create. When we call the Factory method, we pass in this configuration value. Then we use a switch statement to figure out which concrete repository we want to instantiate. The solution works fine, but notice that we have compile time references to all of our repositories. But our clients don't need all of the repositories. Each client only cares about the one repository that they need for their environment. So we would end up distributing more code than we really needed to. In addition, what happens when we want to add a new repository option? We need to recompile this code with the new option and then distribute the new executables. These sound like drawbacks that we want to eliminate based on our scenario. For our scenario, it would make sense if we only shipped the one repository assembly that our client needs. Dynamic loading will allow us to pick up that one assembly at Runtime. In addition, we remove the dependency on concrete repositories from our application code. Our core application can be compiled with no references to concrete repositories and because of this, we're free to build new repository types without needing to recompile our application. So it looks like Reflection makes a lot of sense in this case. let's take a look at the features that we'll be using.
Using Reflection
We'll use a couple of features of Reflection for our application. The first comes from the type class. By using the static GetType method, we can get a CLR type based on a string. GetType has a number of different overloads. This is the signature of the method that we'll be using. This takes a single string parameter and this is the assembly-qualified name of the type that we want. We'll talk about what an assembly-qualified name is in just a bit. This method will reflect into the requested assembly and pull out the information it needs to create a type object. Once we have that CLR type, we can create an instance of it. Another way to get a type is by using typeof. Typeof is a C# keyword and it returns a type object based on whatever type we pass in. In our sample here, we're using typeof to get a type object based on the CSV repository type. So what's the difference in the ways that we get the type? The first option, the static GetType method uses a string to locate a type in an assembly. The second option, the typeof operator, uses a type that we already have referenced in our code. This will make a bit more sense once we start seeing these in our code. Once we have a type object, we can use the Activator class to create an instance of that type. An Activator has an aptly named method, CreateInstance. This method has a number of overloads; this is the one that we'll be using. It takes a single parameter, which is a type, the type that we retrieved with the GetType method. This method will use the default no parameter constructor. The repository objects in our example do not have any constructor parameters, so this will work just fine. There are overloads of create instance that allow us to pass in parameter, but we won't be using these for our examples. The GetType method that we want to use needs an assembly-qualified name of our type. Now we know about the fully qualified name, that includes our type name and the namespace. The assembly-qualified name goes a bit further to include assembly information as well. Here's an example of an assembly-qualified name. I've added line breaks here to make it readable, but this is a single string. It includes 5 pieces of information. The fully qualified name of our type, this is both the TypeName and the namespace. In this case, PersonRepository.SQL.SQLRepository. Next we have the Assembly Name. This is the name of the file without the dll or exe extension. So here we have PersonRepository.SQL as the Assembly Name. Then we have the Assembly Version. One of great features of .NET is that we can run different versions of assemblies side-by-side. This is how we specify which version we want. Next, we have the Culture. When we have localized applications, we can select which Culture we'd like to use. We can also specify neutral further culture to simply use the defaults. Finally, we have the Public Key of the assembly. We need to have the key for strongly named assemblies. We won't go into the details of strong naming here, we just need to know that if we are using assemblies with strong names, we need to include the Public Key. For our examples, we will not have strong names, so we can just leave this value as null. As a starting point, we'll put the assembly-qualified name into our configuration file. But later on, we'll look at some other options. Since we're concerned about performance, we will only be using Reflection to load and create the repository. We will not use Reflection to dynamically invoke members instead; we'll take the instance we created and interact with it through the IPersonRepository interface. This means that we can directly call the GetPeople method. So this gives us enough information to get started. Let's jump into some code. Then we'll loop back around and review the decisions that we've made.
Demo: Repositories
Our application will dynamically load a repository from an assembly, based on configuration. Let's take a look at the Repositories, the types and assemblies that we want to load dynamically and since we need the assembly-qualified name, we'll see how we can get this by simply reflecting over the type in a console application. We have our repositories in a separate solution in order to emphasize the dynamic nature of Reflection. Our application that uses these repositories will not have any references to the source code or the projects themselves. Instead, we'll just have the dll's available at Runtime. Let's start by taking a look at the interface. We have the PersonRepository.Interface project and inside we have IPersonRepository. Now this looks just like what we saw before, so we have the six methods to actually interact with our data, GetPeople, GetPerson, AddPerson, UpdatePerson, DeletePerson, and UpdatePeople. Now our Person object is actually in our PeopleViewer.ShardObjects project. It's a very simple class, that has four public properties, a FirstName, a LastName, a StartDate, and a Rating. So let's take a look at a couple of our repositories. If we come up, we can look at PersonRepository.csv and inside this project, we have this CSV Repository class. Now one thing that's very important to note about this is it does implement IPersonRepository, our common interface. Because of that, it does have those same six methods, GetPeople, GetPerson, AddPerson, UpdatePerson, DeletePerson, and UpdatePeople. This class uses a CSV text file to store data. It retrieves the name of the text file from the application configuration. We won't go into the details of how this particular repository works. If you want a more detailed overview, you can refer to the C# Interface course. If we look at our ServiceRepository, we'll see something similar. So we have a project called PersonRepository.Service and inside here, we have a class called ServiceRepository and this class also implements the IPersonRepository interface. So it has those same six members, GetPeople, GetPerson, AddPerson, UpdatePerson, DeletePerson, and UpdatePeople. This class uses a WCF SOAP service as the data store. This service is actually in the People.Service project. This is a WCF service that supplies the data for this repository, and we also have a PersonRepository.SQL project and in here, we have a SQL Repository. This should start to look familiar. This class implements the IPersonRepository interface and it has those same six data access methods. The difference is, is that this class uses entity framework to access a SQL database. For our sample, it uses a local db file, but it could just as easily connect to a SQL Server somewhere on the network. So these are the repositories that we want to use in our application, but there's one more piece of information that we need. We need the assembly-qualified name for each of these types. For this, we'll use the type class to explore our repositories a little bit. We've setup a console application for this and it's called RepositoryReflector. Let's open up the Program.cs file and see what we have. Right now, we just have a little bit of placeholder code. Let's fill this in some, starting with the CSV repository. So we already have a reference to the CSV repository class and we have a using statement for PersonRepository.csv. So we'll start by getting the type of that particular class and we'll do that with the typeof operator. So we'll say, type = typeof CSVRepository. Then what we'll do is we'll call our ReflectType method and we'll pass it in our CSVRepository type. Now let's go down to our ReflectType method. We can see that this is a bunch of placeholder methods right now. Let's do a little bit of exploring with what we have available in this type object coming in. If we say, type.name, what we see here is that we have a few options to choose from. We have Name, which would simply be the name of the type. We also have FullName, which would be the fully qualified name including the namespace and the type name and we also have the AssemblyQualifiedName available as well. Let's go ahead and output the Name, as well as the AssemblyQualifiedName and when we Run our application, we see that the type name is CSVRepository and that's not a very big surprise and then we also have the AssemblyQualifiedName, that consists of the five parts that we saw earlier. Let's break these five elements down. First, we have the FullName and this includes both the namespace and the name of our type. Then we have the Assembly Name, we can get this by looking at the Assembly property of our type calling GetName on that assembly and then look at the names that we have available. Again, we have Name, FullName, and CultureName. Let's go ahead and just select Name at this point. So now when we Run our application, we'll see the FullName, which is PersonRepository.CSV.CSVRepository and the assembly name which is PersonRepository.CSV. Let's go ahead and get the Version, Culture, and PublicKeyToken information as well. So for the version, again we're looking at the Assembly of the type and this is actually part of the Name. So we can use Assembly.GetName.Version and that will get us the version number and we can do something similar with the Culture. So type.Asembly.GetName.CultureName and then the PublicKeyToken is a little bit more interesting because the PubliKeyToken is actually a byte array, so we need to convert this into something we can use. So for this, I'll use a BitConverter and we'll say, ToString, since we want to output this to our UI, and then we'll say type.Assembly.GetName.GetPublicKeyToken. So that will get us the PublicKey for the assembly. When we Run our application though, we see some strange output. Our version looks okay, 1.0.0.0, but our Culture is empty and our PublicKeyToken is also empty. This is because we have not specified a Culture for our assembly. Because of this, it defaults to the neutral Culture and since our assembly is not strongly named, we do not have a PublicKeyToken, so that just comes up as null. If you want more information on these elements, you can refer to topics on localization and strong naming respectively. So now that we have the assembly-qualified name for the CSV repository, let's go ahead and get it for our other two repositories as well. So we'll just come up and we'll set type = typeof ServiceRepository and then we'll Reflect over that Type and then we'll say, type = typeof SQLRepository and then we'll Reflect over that type as well and then down in our ReflectType method, we'll just go ahead and get rid of some of these details. So I'm just going to use the keyboard shortcut Ctrl+K, Ctrl+C to comment out the block of code and now when we run our application, we'll see the assembly-qualified name for all of our repositories. So again, this is the information that we'll need in order to run our application. Now one last thing, since we're using these repositories in our real application, we want them to be easy to get to. So our projects actually contain a Post-build step. Let's open up the Properties for the CSV Repository project and we see we have a Post-build and what is does is it copies the dll into a LateBindingRepositories folder that we have on our file system. All three of our repository projects have this in them, so this way our dll's will all be in one place and they'll be easy to reference in our other application. Next, we'll take a look at the application that uses these repositories and we'll have the code to dynamically load them with Reflection.
Demo: Activating The Activator
So we've switched solutions at this point. Now we're in the dynamic loading solution and this contains the application, where we're going to dynamically load those repositories that we just looked at. Let's do a quick review the projects that are in this solution. First, we have the PeopleViewer project. This is a WPF application and this actually contains our UI code. Then we have Factory.RepositoryFactory. This contains our dynamic loading code and we'll be filling this in, in just a bit. Then in the Repositories folder, we have some interfaces. Generic.Repository.Interface is something we'll be using in a future project, so we won't worry about it just yet. PersonRepository.Interface is exactly the same interface project that we saw in our other solution. This contains the IPersonRepository interface that we want to reference in our application and that all of our repositories adhere to. People.Service contains the WCF SOAP service used by the service repository. Now, the only reason that we've included that in this solution is so that the service automatically starts when we run our application. Finally, we have PeopleViewer.SharedObjects; this contains the person class and this is exactly the same project we saw in our other solution. Let's start by Running the application. Here we have a button to load our data, a button to Clear Data, and a ListBox. Now, we won't click on the load button just yet because at this point it will only generate an exception. We have some code to write before this application will actually work. So let's look at the code in our application. Now for simplicity, we're simply putting this in the code behind of our form. Let's focus on the button click event handler, FetchButton_click. The first thing we do is we clear out the ListBox. Then we have a variable of type IPersonRepository. This is our interface, the abstraction that all of our repositories share. To populate this variable, we have a factory method called GetPersonRepository. We'll look at this method in just a bit. For this code, we just need to know that GetPersonRepository returns an instance of an object, that implements the IRepository interface and if we hover over the method, we'll see that it does return an IPersonRepository. Our next step is to retrieve some data from our repository. We do this by calling the GetPeople method and using it to populate a people variable. We know that our repository has a method called GetPeople because this is part of the IPersonRepository interface. Then we loop through our people collection and populate our ListBox. Finally, we have a method called ShowRepositoryType. This will output the concrete type of our repository to the screen, so that we can verify which repository we're actually using. So when we look at this code, we can see that we are only programming to an abstraction, IPersonRepository. Because of this, our WPF application does not need any compile time references to any concrete repositories. Another really important thing to note is that we are not using any Reflection here. Since we're getting an instance of an IPersonRepository, we can interact with that interface directly without needing to dynamically invoke methods. If we look at the project References, we see that we do have a Reference to PersonRepository.Interface, but we do not have any references to the concrete repositories, PersonRepository.csv, PersonRepository.service, or PersonRepository.SQL, those are nowhere to be found in our references. So let's go to our factory and dynamically load up an assembly. Inside our Factory.RepositoryFactory project, we have a RepositoryFactory class and we can see right now it has a single static method called GetPersonRepository and it returns something that implements the IPersonRepository. So what we actually want to do here is dynamically load our assembly, instantiate the type, and then return it to our application. But before we add any code, let's look at the References for this project. Just like our WPF application, we have a reference to PersonRepository.Interface, but we do not have any compile time references to the concrete repositories and this makes perfect sense, since we want to load these dynamically. So let's add the dynamic loading code and we'll do this one step at a time. First, we need the assembly-qualified name of the repository that we want to use. We'll get this from configuration. So we'll create a variable called repoTypeName and we'll use the ConfigurationManager to go ahead and get the value from Configuration and this will use a key called RepositoryType. Now that we have the assembly-qualified name, we can go ahead and create a type based on that. So we'll call this repoType and we'll call the static GetType method and pass in the assembly-qualified name for our type. So that will give us an instance of the type class for whatever repository we want to load. Now what GetType will do is it will load up the assembly, reflect into it to locate the repository class that we want, and then generate a type object based on that repository type. Once we have the type, we can use the Activator to create an instance of it. So we'll say, object repoInstance = Activator.CreateInstance and we'll pass in our repoType. Now CreateInstance does return an object and so that's why we've created our repoInstance variable of type object. Now obviously, that's not what we want to return to our application code, so we'll need to cast this to an IPersonRepository. So we'll say, IPersonRepository repo = repoInstance as IPersonRepository. And finally, we'll return our result. So our result will be a dynamically created instance of an object that implements the IPersonRepository interface, and what's really important here is that we are returning an IPersonRepository. Since we are programming to an interface, our application code can use the interface directly. There is no need to use Reflection to call methods on our repository. Now it is possible to collapse this code down quite a bit. We can easily combine several of these statements. I prefer to be a bit more verbose when I'm using Reflection. The reason is that there's a lot of things that can go wrong here. If the assembly-qualified name isn't correct, then we won't be able to locate the type. If we happen to get the wrong type out, the CreateInstance might fail and even if we do create an instance, we might not be able to cast it to an IPersonRepository. So especially during the initial phases when I'm trying to make sure that a block of code works, I like to be a little more verbose, so it's easy to set breakpoints and inspect the intermediate elements before we get to our final return value. Now this is the only code that we actually need to update to get our application to work. Let's go ahead and Build, and make sure that our code compiles. So now, let's flip back to our WPF application and take a look at a few details that we need in order for this code to work. Our repository factory is looking for the assembly-qualified name from configuration. So let's look in our App.config and see what we have here. In our Apps setting section, we see we do have an entry with a key of RepositoryType and the value for this is the assembly-qualified name for our ServiceRepository. The first part is the fully qualified name, PersonRepository.Service.ServiceRepository. Then we have the name of our assembly, PersonRepository.Service, then the Version and the Culture. Notice that we are not including the PublicKeyToken. When we looked at our assembly-qualified name earlier, we saw that the PublicKeyToken was null, since our assembly is not strongly named. Because of this, we can simply omit this value. In addition to the App settings, we also have a system.serviceModel section. This has the information on where to find the WCF service that this particular repository needs. But how does the application actually locate the repository assembly? By default, .NET will look for assemblies in the GAC, the Global Assembly Cache. Now in order to load assemblies into the GAC, they need to be strongly named, so that won't work in our particular case. The other easy place to put the assemblies is in the same folder as the executable. That's what we'll do here and in a later example, we'll see another option. So let's look at the properties for our PeopleViewer project. We'll see that we have a Post-build step and this actually copies the files from the LateBindingRepositories into the same folder as the executable. Now remember from our repository solution, each of those repositories had a step to copy into the LateBindingRepositories folder. So that means this folder will contain those concrete assemblies that we want to load up. So if we Build our application and look at the output folder, we'll actually see these assemblies. So we'll say Open File in File Explorer and we'll go to bin, Release and in here we will see PersonRepository.csv, PersonRepository.Service, and PersonRepository.SQL. Let's go ahead and Run our application from here. So we'll just double click on the PeopleViewer executable and we'll click on our Dynamic Repository button and we see we do have data, and notice at the bottom of the screen we have the fully qualified name of our type, PersonRepository.Service.ServiceRepository that's the type that we requested on our configuration and that's the type that got dynamically loaded. Now let's go to our configuration file and make some changes. So we'll go to PeopleViewer.exe.config and we'll change the language to XML so we get some nice colors here and what I'm going to do is take this section for the Service Repository and comment it out. So now that section is commented out, I'm going to scroll down to a section for our CSV Repository and uncomment this section. So notice we have the same key RepositoryType and then we have the assembly-qualified name, this time, for the CSVRepository and then we also have an additional value that tells our CSVFile repository which file to use. In this case, it'll be called People.txt and it's already in our output folder. So let's go ahead and Save this and if we go back and double click on our executable and click our button, you'll see this time we're getting our data from the CSVRepository. That's showing up as the fully qualified name down at the bottom of the screen and our text file actually has an extra record, so this Jeremy Clark value that we have is coming from that text file and we can do exactly the same thing for SQL Repository. So let's go ahead and open up the configuration file. We'll comment out the section for our CSV file and we'll uncomment the section for our SQL Repository. So again, we have the key RepositoryType and we have the assembly-qualified name for the the SQL Repository. Let's go ahead and Save this and close it and when we double click, we see that we're now hitting the SQLRepository. So our Reflection code is actually working. We're able to dynamically load assemblies, pull types out of them, create instance of them, and then use them in our application. But we do have a little bit of inefficiency at this point. Let's go back to our application and take a look. So here, we are in the RepositoryFactory and I'm just going to set a breakpoint at the beginning of our GetPerson repository method. When we Run our application and click the button, we'll notice that we do hit that breakpoint, I'll go ahead and Run and we'll Clear the Data and click the button again and notice we're back in the this GetPersonRepository method again. What that means is that we're actually using Reflection each time we click the button. As we saw earlier, we really want to minimize our use of Reflection. In this case, we're only using one repository, so we don't need to recreate it each time we click our button. So let's go ahead and change our code a little bit, so that we eliminate this inefficiency. For this, we'll go to the code behind of our form and the offending piece of code is where we're calling GetPersonRepository inside our button click event handler. So all we'll need to do is change this. So instead of calling it each time we click it, we can go ahead and put it in the constructor. So for this, what we'll do is we'll go ahead and create a class level field for our IPersonRepository and then we'll move this code from our button click event handler into our constructor and we'll just initialize that class level field that we have. So now, the instance of our IPersonRepository will only happen one time, when this particular screen is created, when our application starts up. So if we Run our application, we'll see that we do hit the breakpoint at application startup. But if we click our button, we don't actually hit that breakpoint again. Now we've spent quite a bit of time getting to this point, but that's just so that we can have a very good understanding of what's going on. If we look at the actual Reflection in our application, it is isolated to one method GetPersonRepository, just these five lines of code and all we're doing is getting the assembly-qualified name from configuration, generating a type object based on that name, creating an instance based on the type, casting it to our interface, and returning that to our application. Now that we've seen the basics, let's work on expanding this a bit. The next step is to make a factory method that can deal with different types, other than simply IPersonRepository.
Demo: Dynamic Loading
So we have a factory method that can return an IPersonRepository. That's really cool, but it's also a little limited. What if we wanted to dynamically load a different type? We would need to create another method that has almost exactly the same code. Wouldn't it be great if we had a single method that could dynamically load any type? It turns out that we can do that very easily. All we need to do is add generic type parameters to our Factory and change our configuration a little bit. We already have this stubbed out. Inside our Factory.RepositoryFactory, we have a class called GenericFactory. Let's go ahead and put this side-by-side, with our current factory. Now all we're going to do is Replace anywhere that we see IPersonRepository with the generic type parameter T. We already have this in the method signature. Instead of returning IPersonRepository, we're returning a generic type and our method is just named Get. So this will be applicable to any type that we want to retrieve. Our method also has a generic constraint where T is a class. This means that our type will need to be a reference type. Why do we need this? Well, Activator.CreateInstance is looking for a constructor. If we had a value type such as a strut, then Activator.CreateInstance may not work an our as statement that we have a little further down would fail, so we need to have a reference type in order for this code to work. For a deeper dive into Generics, be sure to check out the C# Generics course on Pluralsight. So let's Copy our code over to our Generic method. We'll do this one line at a time so that we can update variable names as appropriate. So we'll start by saying string resolvedTypeName = ConfigurationManager.AppSettings and we have a problem already. In our GetPersonRepository method, our key is RepositoryType. Well, we don't want to use a hardcoded value because it won't be applicable to any type that we pass in. So instead, what we'll do is we'll say, typeof T.ToString and that will get us the fully qualified name for whatever type we're asking for. So in our particular instance, we're looking for an IPersonRepository interface. So this ToString would come out as PersonRepository.Interface.IPersonRepository and this same code will work with whatever type that we request. So based on the assembly-qualified name, we can go ahead and create the Type. So we'll say, resolvedType = Type.GetType and we'll pass in it the resolvedType name. Then we'll have object instance = Activator.CreateInstance and we'll pass in our resolvedType, and then we need to cast it to what type that we want. So we'll say T result = instance as T. So that will cast it to the type that we actually want to return and then we just return the result. So this gives us a Factory method that will work with any type that we can come up with. Let's update our application to use this. There's only two things that we need to update. First, let's go ahead and Build, and make sure that our code compiles. Now we'll go back into our PeopleViewer project and we'll go to our code behind where we're using the Factory. Now instead of using the RepositoryFactory, we want to use the Generic factory, so we'll say, repository = GenericFactory.Get and we'll pass in the type that we want IPersonRepository and the last thing we need to do is update our config file. So we're no longer using this RepositoryType key, instead we need to put in the fully qualified name for our interface. So this will be PersonRepository.Interface.IPersonRepository and we'll use this same value for our other entries as well. So now, if we Run our application, we'll see that we have exactly the same results that we had before. When we click the button, we'll dynamically load the ServiceRepository from the assembly, but this time we're using that GenericFactory that will work with any type we ask for and we can just as easily update our configuration. So we'll come in and comment out the section for the Service Repository and uncomment the section for the CSV Repository. And when we Run our application, we see we dynamically load the ServiceRepository. So if we go back to our GenericFactory we'll see that we're doing exactly the same type of Reflection that we had before. Were loading a type based on an assembly-qualified name that we have in configuration. Then we use an Activator to create the instance. The only difference is that we're using a Generic type parameter now, so that this method will work with any types that we want to use. We'll do one more extension to this application and this will show how to work with types that have generic parameters themselves. Be prepared for some strange looking syntax.
Generic Parameters in Types Names
Here's our current repository interface. This works great for interacting with person objects, but what if we had other classes that need repositories as well, such as orders or products. We could create custom interfaces for each type, but it would make more sense to add generic parameters so we can use this same interface with repositories of any type. We have two pieces to swap out, the type of the objects we're working with and the type of the primary key for those objects. Here, Person is the type of our object and string is the type for our key, which is the lastName property in this example. Then we just need to change the methods name a little bit to make them more applicable to other types. Here's the repository interface we end up, IRepository of T TKey. Instead of GetPeople, we have GetItems and rather then returning an IEnumerable of person, we return an IEnumerable of T. Instead of GetPerson, we have GetItem. This takes a parameter of type TKey rather than string and returns an object of type T instead of Person. What would it look like to use this generic interface with a person repository? Here's an example of a class declaration. We have a class called PersonRepository and this implements the IRepository interface and our generic parameters are Person and string where Person is the class type and string is the type for the key, the lastName property. So this means that our interface type looks like this, IRepository<Person, string. We want to use this type in our configuration. So what does that look like? Here's the fully-qualified name for this type and this looks a bit strange to a C# developer. We have the namespace, GenericRepository.Interface. Then we have the type name IRepository, but then we have a ` and the number 2. This denotes that this type has two Generic type parameters. The types of the parameters themselves are enclosed in square brackets; this is the fully-qualified PeopleViewer.SharedObjects.Person and also System.String. This is what we'll need in our configuration without the extra line breaks, so let's jump into the code and see it in action.
Demo: Generic Parameters in Type Names
So we're back in Visual Studio looking at the repository solution. This is the same solution, we were looking at before with our repositories, but we have another folder in here called Generic Repositories and this is where we'll be spending our time this time. In here, we have a GenericRepository.Interface project and this has the IRepository interface that we looked at earlier, and if we look at our GenericRepository.CSV we have a class called PersonRepository and this implements IRepository of Person string, and we see we have a GetItems method that returns an IEnumerable of Person, and we have a GetItem method that takes a string for the lastName field and returns a Person object. So this implements the IRepository interface with the Generic types filled in. Our other repositories match this same signature. So we have the GenericRepository.Service and GenericRepository.SQL that all follow this same layout and just like with our other repositories, we do have a Post-build step and this copies the dll's to the LateBindingRepositories folder that we looked at earlier. So now, let's go back to our application to see how we can use these repositories. So here, we are back in our dynamic loading solution where our PeopleViewer project is. Now since there's so many changes involved, we'll go ahead and bring in another WPF solution. So we'll go ahead and Add an Existing Project and this will be PeopleViewer.GenericInterface and we'll go ahead and set this as a StartUp Project. Now notice in the references for this, that we do have a reference to GenericRepository.Interface, but like our project, we don't have any references to the concrete repositories themselves and if we open up the code behind, we'll see code that's very similar to our other WPF project. Notice in our constructor we're using the same GenericFacotry that we were using in our other project, but notice the generic type that we're passing into the Get method. Our Get method has a parameter of IRepository of Person string. Now this looks especially odd because we have nested Generic types. But what we're asking is to get an object that implements the IRepository of Person string interface and we can see down below in our click event handler that we're calling the GetItems method on our repository and if we hover over the var of what's coming back from this, we see that this returns an IEnumerable of T where T is a person object. So this is returning IEnumerable of Person, just like our other repositories did. So the rest of this code looks exactly the same as our other application. But we need to figure out the type of this interface so that we can put it into our configuration file. Here's one way that we can do that. For this, we'll open up our GenericFactory and we'll set a breakpoint here and Run our application. Now if we step, what we really want to do is inspect this ToString property on this typeof. Unfortunately, we can't do that here. So let's go ahead and Stop our application and split this up into a couple different lines. So we'll say string requestedType = typeof T. ToString and then we'll just replace this value with requestedType. So now, we can set our breakpoint right below this and we'll be able to see what comes up. So if we look at our requestedType we can actually see that it looks very similar to what we saw earlier. So we have GenericRepository.Interface.IRepository then we have the ` and the number 2 to indicate that we have 2 generic type parameters and then we have the square brackets with PeopleViewer.SharedObjects.Person and System.String. So this is how we translate IRepository of Person String and this is the value that we want to use in our config. So if we go to our App.config file we'll actually see we have exactly that. So we have this all on one line, so it is a little bit hard to read, but we can see we have GenericRepository.Interface.IRepository`2(PeopleViewers.SharedObjects.Person, System.String) that's a mouthful and for the rest of our settings, the value is exactly the same as we had before. Now our namespaces are a little bit different so we have GenericRepository.Service.PersonRepository, but this is the same assembly-qualified names that we we're looking at earlier. So if we Run our application and remove our breakpoint We'll see that we can hit the Service Repository and in this case, our class names are a little bit different, but we can see its GenericRepository.Service.PersonRepository, so that's coming from the Service namespace and we can also update our configuration, so we'll comment out this section and we'll uncomment our CSV section and again, our app settings will look very similar to what we saw earlier and now when we Run, we'll see that we are hitting the CSV Repository that's coming out of GenericRepository.CSV. So this shows how we can create full names for types that have generic type parameters. Many times the easiest thing to do is to use typeof on a particular object and then use the type properties to get the information that we need whether it's the FullName or the assembly-qualified name. We've covered quite a bit of information in these examples, let's review what we've seen, especially in the choices that we made that effect performance.
Maximizing Performance
Performance is a major concern when using Reflection. We did a few things to mitigate this concern in our application. We only have once place in our application where Reflection is used, inside the Get method of our Factory and we only call the Get method one time in the constructor. When we first started, we called Get on every button click, but we really only needed to retrieve the repository one time for this application and the Get method returns and IPersonRepository. This means that all calls on the returned object can go through the interface, no additional Reflection is necessary. We actually used the dynamically created repository in our buttons click event handler and notice that we do not have any Reflection here. All of our method calls are through the IPersonRepository interface. So we can directly call the GetPeople method without dynamic invocation and that's really the key here. We limit the use of Reflection to the places in our code that actually need it, when we dynamically create the instance of a type from an assembly. After we have that instance, we interact with it through an agreed upon interface, we do not need to use methodInfo.invoke to run any methods.
Summary
We use just a few features of Reflection in our examples, but we used those features very effectively. We looked at several methods. By using the GetType method on the Type object, we can dynamically load a Type from an assembly, based only on the assembly-qualified name for that type. In our examples, we got the assembly-qualified name from our configuration file and then used it to dynamically load a type for our repository. The typeof operator will give us a type object based on a type that we have referenced in our code. As we saw in our repository solution, this can be useful for retrieving type properties we may need elsewhere, such as the assembly-qualified name and once we have a type object, we can Create an Instance by using the Activators.CreateInstance method. We also saw several type names that we can use in various scenarios. The Assembly-Qualified name includes the type name plus information about the assembly including the Name, Version, Culture, and PublicKeyToken. We stored this value in our configuration file so that we could use it with the GetType method. We also saw the FullName of our type. This is just the namespace plus the type name and this also happens to be the first element of the assembly-qualified name and we also saw how the FullName changes when we add Generic Type Parameters into the mix. After the Type name we have a ` and the number of generic parameters. Then we have a set of square brackets that contain the full names for the generic parameter types. And we saw some steps we could take to minimize the performance impact that we get from Reflection. We limited our Reflection calls to the dynamic loading and creation of our repository. After that, all method calls are done through an interface. This means that we avoid the extremely slow methodInfo.invoke calls and our application maintains good performance. This is a great start, but we'll take this a bit further. What if we don't know what types are available in an assembly? It turns out that we can open up an assembly, look at the types that are exposed, and then create instances of the ones that we care about. Up next, we'll look at how to incorporate this type discovery into an application.
Discovering Types in Assemblies
Overview
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.
Dynamic Business Rules
In our scenario, we have an application that creates product orders. This is a simple application, that allows for data entry and we want to ship this application to our various clients who sale products. One of the problems though is that each of our clients has different business rules. We can easily incorporate common business rules, but what about the unique rules? In order to allow for maximum flexibility, we're going to all our clients to program their own business rules. All they need to do is create an assembly with a class that adheres to our business rule interface and then drop that assembly into a folder where the application can find it. As far as the application itself is concerned, all of the customers who order products are outer space commanders. Because of this, we will give them a choice of products that they really like. This will include items such as Starships, Universal Translators, Captain's Chairs, Space Suits, Laser Beacons, and Name Badges. We also provide a way to offer discounts on orders. By default, we do not have any business rules in the application. It will be up to our clients to decide how they want to manage discounts, limit quantities, or decide which customers are allowed to order which products. Our Business Rules will adhere to an interface, IOrderRule. This is a fairly simple interface. It only has two members. We have a property called RuleName. This is a human friendly name for the rule and we also have a method called CheckRule. This is the method that will be run by rule checker in the application. This method takes an Order as a parameter. This means that we can look at all of the elements in the order such as the customer, products, quantities, prices, discount, and total, and we can use this to determine whether the rule is broken or not. The return type for this method is OrderRuleResult. This is a class that has two properties, Result and Message. Result is set to true if the rule passes, if false, then the rule is broken. Message gives us a place to put a human readable error message. This can then be displayed to the user, to let them know which items need to be updated. Now that we've seen our interface, we just need to build classes that implement that interface. Let's look at a few of the rules we will build. We'll have a maximum discount based on the Customers Rating. For example, if the customer has a rating of 4 on a 10 point scale, then we will only allow a maximum of a 5% discount. But if the customer has a rating of 9, we will allow up to 20%. We also have a couple of restrictions based on the products ordered. Since Starships are really hard to build and generally have a 3 week lead time, we only want to allow 1 Starship per order. In addition, we offer a variety of Captain's Chairs such as an economy model with vinyl covering or a premium model with Corinthian leather, but regardless of which chair our customer wants, we only allow 1 chair to be ordered. Finally, we offer a series of Name Badges. We want to make sure that a customer orders a Name Badge with the correct name on it. These implementations are all quite simple, so that we show the implementations. But we can come up with quite complex business rules as well. Since we have access to the order object, we can compare it to other orders in the database. If we wanted to limit our customers to one order per day, we could do that. If we wanted to have a maximum number of items across all orders for a customer, we could do that. We could even compare the ordered items against what we have in inventory and disallow items that are out of stock. This type of rule implementation is extremely flexible. Our next step is to take a look at the features of Reflection that we need in order to implement this design.
Discovering Types in Assemblies
It really isn't that hard to discover and load the types that we want. Here are the steps that we'll follow. First, we'll locate all of the assemblies in a "Rules" folder. The name of the folder is configurable and we'll use the .NET directory class to locate all of the dlls in that folder. Once we have a list of assemblies, we'll load each one. With the assembly loaded, we'll enumerate all of the types that are exposed by the assembly. Note that this will only be the public types, we won't be looking for anything that isn't publicly visible. Once we have the public types from the assembly, we'll check to see if a type implements our IOrderRule interface. If a type does implement our interface, we'll use the Activator class to create a instance of that type and then we'll add it to the rule catalog. When we actually check the Rules, the rule check will go through each rule in the catalog and run the check rule method. The rule checker will keep track of any broken rules and we can access those in our application to give appropriate messages to the user. So let's look at the Reflection features that we'll need for this. We'll use a couple of features form the Assembly Class. The Assembly Class has a static LoadFrom method that takes the name of a file. We can use this to load an assembly from the file system. Once we have that assembly loaded, we can look at the ExportedTypes property. This property has all of the public types in the assembly. Since it's an IEnumerable, we can easily iterate over this collection using a for each loop. Once we have the collection of types, we need to figure out which ones we want to keep. For this, we'll use some members of the Type Class. We can us the IsAssignableFrom method to determine if a class implements a particular interface. There's a similar method called IsSubClassOf that can be used to see if a class inherits from a particular type. This would be useful if we used an abstract class rather than an interface, although IsAssignableFrom will work for both interface and abstract classes. We'll also use a property on the type class called IsClass. This tells us whether the type is a class, meaning it is not a value type and it is not an interface. If IsClass is true, then we can use the Activator class to create an instance of the type, just like we did earlier with our repository example and those are all the features we need to implement our scenario. So let's jump into some code and see all of this in action.
Demo: Base Application
So now that we've seen our basic design, it's time to start looking at the code. We have most of our application already in place. Let's walk through the important bits of these projects and we'll see the current functionality along with placeholders for our new functionality. Let's start by Running the application. Now, I'll be first to admit that this is not the greatest UI, but it will get the job done for our purposes. At the top of the screen, we have a Combo Box with our customers. If we change our customer, we'll see that the corresponding Rating and Customer Since dates are updated as well. At the bottom of the screen, we have a Combo Box with our products. If we change the product, we'll see that the Unit Price updates as well. We can entire a quantity and then click Add Item to add the product to our order. These show up in the ListBox in the middle of screen and we can also remove items from the list. On the right, we have fields for the Discount and Total Price for our order. If we update the Discount field, we see that that Total is updated as appropriate and when we click the Submit Order Button, our Order is Submitted. Now we don't have any business rules in place right now, so we can select whatever items we want for the order and we can set the Discount to whatever value we want. So let's take a look at the project that make up this application. The OrderRules.Interface project contains the IOrderRule interface, and the OrderRuleResult class. These are the same ones that we saw earlier. IOrderRule has two members, RuleName and CheckRule and CheckRule returns a type OrderRuleResult. OrderRuleResult has two properties, Result and Message. This defines the interface that our rules will need to adhere too. The OrderRules.RuleChecker project contains our rules engine. Our RulesChecker is actually pretty simple. We have a private field called orderRules that contains our Rules catalog. Notice that this is a of DynamicOrderRule and a DynamicOrderRule is simply a wrapper around an IOrderRule. We see that this has a property called OrderRule, which is an instance of IOrderRule. Then we have several other properties that we can use to display more information in our application. The TypeName holds the fully-qualified name of the rule itself. AssemblyName has the name of the assembly that we loaded this rule from and the Message is just a mirror of the message property from the OrderRuleResult class. We have this extra information so that we'll be able to verify that we're dynamically loading our rules. We wouldn't normally need these in a real application, but here we're learning about Reflection and we want to verify that the results match the expected behavior. So back in our RuleChecker class, we have the OrderRules field that holds the Rules catalog and we also have a public list of the BrokenRules. Since this list is public, it will allow our application code to inspect the broken rules so that we can display appropriate messages to our users. The constructor asks the DynamicOrderRuleLoader to load up our rules. We'll look at this class in just a bit. Notice that the constructor takes a parameter for the rulePath. This is the folder that will contain our rule assemblies, and our application will pick up this path from configuration. Then we have the core functionality of our class, the CheckRules method. This takes the current order as a parameter and will return true if all rules pass, or false if one or more of the rules are broken and we can see that this code is fairly straightforward. We create a new empty List to hold our BrokenRules, then we loop through each of the rules in our rule catalog. For each rule, we call the CheckRule method. If this returns false, meaning the rule is broken, we make a note of the Message and Add the rule to the BrokenRules collection. Finally, we return a true or false value depending on whether any of our rules are broken. So all in all, our RuleChecking mechanism is not very complex. Let's take a look at the DynamicOrderRuleLoader. This class has a single method called LoadRules and right now, it simply returns an empty set of rules. This is where we'll dynamically load our rules from our assemblies, but we'll actually build some rules first and then we'll come back and fill in this code. Moving on in our solution, we actually have some data project. These define the objects that we're actually using in our application. So we can see we have things such as Order, Person, and Product contained in our SharedObjects project and then in our DataProject, we have some classes to provide our data. The People class gives us a list of available customers and the Products class gives us a list of available products. These are just hard coded values for simplicity, but these would reference a service database or other data store in a real application. Finally, we have the OrderTaker project. This is a WPF application, that contains our UI and other code. For simplicity, we've put all of our application code in the code behind of our forum. This is not the recommended way of doing things, but we want to stay focused on our rule engine as much as possible here. Now we won't go through all of the details of the forum, much of it is simply handling the data and the UI elements. We'll just touch on the parts that involve the RuleChecker. The InitializeRuleChecker method is where we create an instance of the RuleChecker class we saw earlier. The constructor needs a path to our rule assemblies, so that's what most of this method is concerned with. It checks the configuration to see if there's a relative path specified. If there's no path in configuration, then it just used the path for the application itself. But if there is a path specified, it appends it to the application path. If we look in our App.config file for this application we see that we have a relative path of OrderRules. This is where we can place all of the assemblies, that we want to load dynamically. So once we have that rule path, we create an instance of our RuleChecker and assign it to the class level field. Now let's look at what happens when we click the Submit button. When we click the Submit button, we want to check all of our rules. If there are any broken rules, we want to display the error messages to the user. If there are no broken rules, we want to Submit the order. The important bit is that we're calling the CheckRules method on the RuleChecker. We supply it with the current order as a parameter. If it returns true, then everything is fine, if it returns false, then we have at least one broken rule. The rest of the method is concerned with manipulating the UI. If we have broken rules then we want to add messages to the UI, to let the user know what's going on. If we have no broken rules, then we simply popup an order submitted message. So these are the basics of our application. The code is not very complex at this point and we still need to add the code to dynamically load the rules, but before we do that, let's create some assemblies that contain those rules.
Demo: Building The Rules
Now that we've seen the application, we'll switch over to how things look from our clients perspective. As a client, I want to create custom rules that meet my business needs and we've been provided with a fairly easy and flexible way of doing this. We just need to create some classes that implement the IOrderRule interface. Our first rule will be the Starship rule. We only want to allow one Starship per order. So let's go ahead and Create a New Project. So we'll just Add a New Project and this will be a Class Library, and we'll call this OrderRule.Quantity because this will hold all of our rules that have to deal with quantity restrictions. Now I want to set this to release builds because that's what we want to use. We need to add a reference to the assemblies that contain the interface and the object definitions. We were given the compiled assemblies for these, so let's navigate to them and Add them to our project. So we have these in a RuleInput folder and we can see we have OrderRules.Interface and OrderTaker.SharedObjects. Let's go ahead and Add both of these to our project and then we'll change the name of our class. So instead of Class1, we'll call this MaxStarShipRule and let's go ahead and add a couple of using statements for the assemblies we brought in. So we'll add OrderRules.Interface and also OrderTaker.SharedObjects and in order for our rule to work, it will need to implement the I interface. So we'll bring that in and notice the blue underline underneath the I, that's Visual Studio offering to help us. If I press Ctrl+., it will offer to implement the interface for us. So if we go ahead and let Visual Studio implement the interface, we can see it gives us both the RuleName, as well as the CheckRule method. Now I'm going to change the order of these so that they'll match what we have in our interface. Visual Studio brings them in alphabetically by default. So for the RuleName this will just be a human readable name so we'll say, return Maximum StarShip Rule and now we just have to implement the CheckRule method. So here, we want to make sure that there is a maximum of 1 Starship on the order. So we'll start out by creating a couple of variables we can use. So we'll create a variable for passed, which we'll set to true by default and we'll create a variable for message and we'll set this to string.Empty by default. So now, let's look at all of the order items. So foreach item in our order, we want to see if the is a Starship. So we'll say, Item.ProductItem.Name = Starship and we also want to see if the Quantity > 1, and if that's the case, our rule is broken. So we want to set passed = to false and we want to set our message = to Maximum of 1 Starship per order and finally, we want to return our result, so this will be a new OrderRuleResult and we'll pass in passed our true false value, and our message. So if our rule is not broken, it will pass a true value for passed and an empty string for the message. Otherwise if it's broken, passed will be false and message will be Maximum of 1 Starship per order. Now one last thing I like to do with all of my classes is I like to organize my assemblies. So I'm going to Right click and say, Organize Usings and Remove and Sort and that will get rid of all the using statements that I'm not actually using. Now doing a search based on the product name is probably not the most robust way checking this rule. We probably want to look at product ID's or categories, but the main take away from this that we can put whatever code we'd like into this CheckRule method. It can be as simple or as complex as we need it to be. Let's build a second rule based on the Captains Chair. This is also a quantity-based rule, so we'll add it to the same assembly. So we'll just right click on our project and we'll say Add Class and we'll call this OneCaptainChairRule. and we'll go ahead and Add the using statements, like we did before. So using OrderRules.Interface and using OrderTaker.SharedObjects. Now, one thing that is very important is that our class needs to be public. When we load up our assemblies we will only look for publicly exposed classes, so if we don't set this to public we won't be able to find it on our application and just like all of our rules, this will need to implement IOrderRule and again we'll do Ctrl+. to implement the interface and we'll set our Name = to One Captain Chair Rule and then, we just need to implement the CheckRule method. Now this rule is a little bit trickier because we do have a Captain Chair that's made out of vinyl, as well as a Captain Chair that's made out of leather and these are two separate products, which means they may be two separate line items on our order. So let's create a variable for the chair count and we'll also create passed and message variables like we had before. So let's loop through our orders. So foreach item in our OrderItems if item.ProductItem.ProductName.Contains Captain and Item.ProdutItem.ProdcutName.Contains then we want to increment our chairCount based on the item quantity. So we'll say += item.Quantity. So now, we just need to check our chairCount. If the chairCount > 1 then we have a failing rule. So we'll set passed = false and we'll set our message = Only one Captain Chair per order and then just like before, we'll return a new OrderRuleResult and we'll pass in the passed variable, as well as the message and in our last step, we'll go ahead and Remove and Sort our using statements and let's go ahead and Build and make sure everything compiles and we can see that making rules is actually pretty easy. Let's bring in some other projects that already contain rules so that we can see some other types. So we'll go to our solution and we'll say Add Existing Project and we'll bring in our NameBadge Rules and then we'll also right click and we'll Add an Existing Project and we'll bring in our DiscountRules So let's start by looking at our NameBadge rule. Now in this case, we want to prevent our customers from ordering a NameBadge that has a name that's different from their own. This is pretty easy to check because our NameBadge ProdcutNames also contain the name that's on the badge itself. So we can see that our CheckRule method has a fairly similar layout to what we saw before. We have two variables for passed and message. Then we loop through our OrderItems and we check to see if we have any NameBadge items in the OrderedItems. If we do, we also want to see if that ProdcutName contains the FirstName of our customer and notice we have a not in from of this. So if we have a NameBadge and it does not contain the FirstName of the customer, our rule is broken. So in that case, we'll go ahead and set passed to false and we'll set a message that says, the customer does not match the Name Badge. Once we have that, we'll return the OrderRuleResult just like we've done with our other rules. Now one that we have on this particular project, since it's already existing, is we have a Post-build event and what this Post-build event does is it copies the assembly into a RuleOutput folder. Now we don't have this on the project that we created ourselves, so I'm going to Copy and Paste this into our OrderQuantityRules. So we'll come to our OrderRuleQuantity and we'll go to the Build Events and we'll add that Post-build event. So it will copy the assembly into the RuleOutput folder that we have in our solution folder. Now finally, let's look at our CustomerDiscountRule. So we brought this in and we have a CustomerDiscountRule and this actually determines the maximum discount based on the Rating of a customer. So the Customer Rating can be anywhere between 0 and 10 and we can see we have a switch statement and this determines if our rules are broken or not. So if the Customer Rating is between 0 and 3, their not allowed a discount. So if the OrderDiscount is > 0, our rule is broken. If we look down below that, if the Customer Rating is 4, 5, or 6 their allowed a maximum discount of 5%. So if it's > 5 the rule us broken and we pass out an appropriate message. We see that if the Customer Rating is 7 or 8 their allowed up to 10% and if it's 9 or 10, their allowed up to 15%. So this rule is a little more complex and it's actually looking at values on the customer, which is part of the order that's passed in. Now one other thing that's interesting is we have another class inside this project called HelperClass. HelperClass is not a rule class; it's simply another class in our library. If we have complex rules, then we may have HelperClasses to call services or interact with databases. When we dynamically load the types from these assemblies, we will look for classes that implement the IOrderRule interface. This HelperClass does not implement that interface, so it will not be picked up by our loader. This just shows that we can have other public classes in our assemblies, as long as we are selective about the classes we actually load, we won't have any problems and we'll see this code in just a bit. Let's go ahead and Build our solution to make sure everything works and then let's check our Output folder to make sure our assemblies are there. So if we go to the RuleOutput folder we see that we do have assemblies for OrderRule.Discount, OrderRule.NameBadge, and OrderRule.Quantity. So we've seen just how easy it is to build these business rules. Let's finish up our application by adding the code that dynamically loads these assemblies.
Demo: Type Discovery with Reflection
So now, we're back in our application code and it's time to add the dynamic loading code. Just like with our repository example, we're going to limit the amount of Reflection that we use and we're going to keep it isolated to just one section of our code. In this case, we have the DynamicOrderRuleLoader class. So if we go to our RuleChecker project, we can open up our loader and this is where we can put our code. Now, we do need to do a little bit of sanity checking here. The parameter that we're getting is the assembly path, which should be a folder that has all of our rules assemblies in it, but we do need to make sure of that directory actually exists. So we'll say, if not Directory.Exists assemblyPath, then we'll just return rules. So we would just return an empty rule collection if we don't actually have anything in that path. So let's see if we can locate all of the dlls that are in that path. So we'll create an IEnumerable of string and we'll call this assemblyFiles and we'll use our Directory object to EnumerateFiles in that Directory. Now we need a few parameters here. The first is the path and that will be our assembly path that we have from our parameters and then we'll add a filter so we'll say, *.dll. So we'll only look for files that have the dll extension. Then, we also have search options and we'll say to just search the TopDirectoryOnly, so if there's any subfolders we're not going to look in them. So now that we have a collection of all of the assemblies in the folder, all we need to do is load up those assemblies and determine if there is any types in them that we want to use. So we'll say foreach string assemblyFile in AssemblyFiles and then we'll start using some Reflection. So what we'll do is we'll create and assembly object and we'll get this by using the LoadFrom method that we saw earlier. So for this, we just need to give it the name of the file which will be assemblyFile and it will load the assembly from the file system and give us this assembly object. So now that we have the assembly object, we can look at the exported types. Now we want to loop through each of the types, so we'll say, foreach Type in assembly.ExportedTypes and then we need to determine if the type in the assembly meets our requirements. Well, what are our requirements? Well first of all, it needs to be a class and second of all it needs to implement the IOrderRule interface. So let's check both of those in a conditional. So we'll say, if type.IsClass and again that's just a property on the type object, and typeof IOrderRule.IsAssignableFrom type. Now that looks a little bit confusing, so let's talk about it a little bit more. So what we're doing is we're getting a type object for IOrderRule and from there we're saying IsAssignableFrom the type that's coming out of our assembly. So what we're asking is, is the type we're looking at assignable to an IOrderRule, meaning does it actually implement this interface? If so, then it meets our criteria. So if it does meet our criteria, we actually want to create an instance of this rule and then add it to our catalog. So for that, we'll create an IOrderRule variable called Rule and we'll say Activator.CreateInstance and we'll pass in the type that's coming from our assembly, and since CreateInstances returns an object, we'll need to cast this and we'll cast this to an IOrderRule. And now that we have the instance of the rule, we just need to add it to our rules collection. So we'll say, rules.Add new DynamicOrderRule and we'll pass it in the Rule and then we want the type name so we'll say type.FullName and then we want the assembly name, so we'll say type.Assembly.GetName.Name and these are things that we were looking at when we were first looking at our repositories and seeing what the FullNames and the assembly-qualified names were. So after we get through looping through all of the items, we return the rules and this will have all of our dynamically loaded rules. So let's Run our application and see what happens and we'll come in here and we'll add 2 Starships, so I'll just click Add Item twice, so now we have 2 Starships and I'll click Submit Order. Oh, our rule didn't get hit, what happened? Well, even though we created these rules, we have not yet added them to that OrderRules folder where our application's looking for them. Let's go ahead and take a look at our Output folder. So here's the Output folder where we have our OrderTaker.exe and we see it does have an OrderRules folder, but if we open it up, it's completely empty. So now, let's find that RulesOutput folder where we have the assemblies for our rules and again here, we have the OrderRule.Discount, the OrderRule.NameBadge, and the OrderRule.Quantity. Let's just move the Quantity order rule over to start with. So we'll Copy this into the folder. Now if we Rerun our application, and try to add 2 Starships, we'll see that now we have a broken rule and you can see the red area, we have the error message of Maximum of 1 Starship per order and we actually have a way to look at the details. So we can see that this called the Maximum Starship Rule, that's the name coming from our interface, the fully-qualified type name is OrderRule.Quantity.MaxStarshipRule, and the assembly that this is coming from is OrderRule.Quantity. Now, let's try one of our other rules. Our customer name is John Crichton, let's try to add a NameBadge for Dante and see what happens. Well, we still just have the same error message of Maximum of 1 Starship per order because we haven't added that NameBadge rule to our OrderRules folder of our application. Let's go ahead and include those as well. So we'll go ahead and Copy the Discount, the NameBadge, and the Quantity, we'll just grab all three of our assemblies. Then we'll go to our OrderRules folder and go ahead and Paste these in and now let's try running our application again. So, if we try to add 2 Starships, and we try to choose a NameBadge with Dante, we see that we do get two broken rules and again, we can open up the details and see that these are coming from different assemblies. One is coming from the OrderRule.NameBadge assembly and one is coming from the OrderRule.Quantity assembly and we can check our Discount percentage as well. Let's go ahead and pick Issac Gampu as our customer. Now he has a very low rating, which is 4, and that means that he should only be allowed of a maximum of a 5% discount, but let's go ahead and give him a 10% discount. When we Submit the order, we see that we do have the broken rule for the Discount as well. So now we have three broken rules and these are all coming from separate assemblies and that's really all there is to this. If we go ahead and change this so that we just have One Starship and then we change the NamdBadge so that's it's a valid NameBadge and let's reduce our Discount to 5%. If we click Submit Order, we see that none of the rules are broken and our order is submitted successfully. But if we change one of these items, such as a 15% Discount, now we have a broken rule and we will get errors. So with this code in place, our customers can create as many custom rules as they like. The rules just need to implement the IOrderRules interface and the assemblies need to be placed in the proper folder, which we can change with configuration. Let's do one last review of how we're actually doing this dynamic loading. So again, here we are in our Dynamic Loader. The first thing we do is we make sure that our Directory exists that has our rules in it, so in this case we're looking for that subfolder called OrderRules. Then we use the Directory class to enumerate all of the dlls that are in that folder. We pull those out and put those into an assembly files variable. Then we loop through each one of those files, each dll. For each one, we'll actually load the assembly and we'll do that with the static Assembly.LoadFrom method and then we'll look inside the assembly to look at its Exported types. We'll loop through each of those Exported types and if the type is a class and it implements IOrderRule, we'll use the Activator to create an instance of that type and then we'll add it to our rules catalog. So again, this code is really not all that complex. If we wanted to, we could take some of these nested foreach statements and if conditionals and turn it into a single link statement, but I'll leave that as an exercise for you to do.
Summary
With our example, we saw how Reflection can be very useful for extending an application. We have a Rules Engine that's based on a particular interface. Our clients can create their own business rules by simply writing classes that implement that interface and rather then have a bunch of configuration, we load up all of the assemblies in a particular folder. This means that we can have as many rules assemblies as we want and we can organize them however we like. Once we have the assemblies loaded, we discover what types are available. By reflecting the public types, we can see which ones implement the rules interface and then use the Activator class to create instances of those types. Then we simply load them into the rules collection used by our Rules Engine. We've used a very small set of features compared to what Reflection offers and generally, if we're building business applications, we really don't need to use very many features. But if we start looking beyond the applications that we build to the developer tools and frameworks that we use we will find a more extensive use of Reflection. Next up, we take a look at several of those tools to see how Reflection makes what they do possible.
Reflection in Developer Tools
Overview
We've spent quite a bit of time looking at a very small part of Reflection. These are the parts that are most applicable to everyday developers, but many of our tools use Reflection. These usually dive much deeper into the metadata then we have so far. This includes things like showing all of the types and members inside of an assembly including private members. They also decompile code, they may be dynamically resolving and loading objects, or they may dynamically invoke methods. These tools all work by reflecting into assemblies and then working with the metadata. We won't go into details on how these tools work. We're looking at these for two reasons, first, to see ways that Reflection can be used. Second, to see that there are tools to handle this functionality, so we don't have to try to build this ourselves. We'll be looking at several developer tools. Some of them are included with Visual Studio and the .NET framework and some of them are available to download from third parties. All of the tools that we'll look at today are freely available. We'll look at examples with each of these tools. Visual Studio will give us documentation based on a .NET assembly. One way is through the class definition window. When we use F12 or select Go to Definition from the menu, Visual Studio tries to take us to the source code where the object is declared. But if we don't have the source code, Visual Studio will dynamically generate documentation for us based on the assembly metadata. This is limited to the publicly exposed members of the assemblies and classes. Another way that Visual Studio will generate documentation is by opening the Object Browser. If we double click on an assembly in our project references, the Object Browser will open up a tree structure of the assembly to show us the publicly exposed members. These tools just show use the publicly available members, but other tools allow us to view private members as well. ILDASM is the Intermediate Language Disassembler. This tools ships with the .NET framework and we can use it to open up assemblies to view the metadata dynamic IL code. This shows use everything in the assembly, including the private members. And we can go to third party tools for this as well. JustDecompile is a decompiler that's offered by Telerik as a free download. Like ILDASM, this tool will show us the metadata and IL code for an assembly, but it actually takes things a step further. It will decompile the IL into C# or to VB .NET. The tools we've mentioned so far are things are things that we use when we're building or investigating applications. But there are some tools that we actually incorporate into our applications that use Reflection as well. Mocking Frameworks are an extremely useful tool for unit testing and their also great for creating placeholder objects while we're waiting for other modules and libraries to be completed. These work by creating in-memory objects based on an interface. One of these frameworks is Moq. To perform the mocking functionality, Moq dynamically invokes methods on in-memory objects and also reads and writes fields and properties and there are many other functions as well. We'll actually look at the Moq source code to see some of this. And the last tool that we'll explore is a dependency injection container. Dependency injection containers, which are also sometimes referred to as Inversion of Control or IOC containers, dynamically create objects and in the process they resolve dependencies based on configuration. To accomplish this, they make use of several Reflection features including locating types and constructors, and dynamically invoking methods. For our sample, we'll look at the Unity container that's put out by the Microsoft patterns and practices team. So let's open up these tools and look at how they work and how Reflection plays an important role in their functionality.
Demo: Reflection in Visual Studio
We'll start our exploration of development tools by looking at what Visual Studio offers. Here we have a solution that we looked at earlier. This is actually the Reflection dangers project that we saw, where we were accessing the private members of a sample class. Now as mentioned, we can go to class definitions and if Visual Studio does not have access to the source code, it will generate documentation simply based on the metadata. So if we right click on the sample class type and say, Go To Definition, Visual Studio will actually generate some documentation for us and notice that if we hover over the tab that this says it's coming from metadata and we can see that what this gives us are the public members that are available in this class. So we see the declaration public class SampleClass. We see the constructor and we also see the public CachedItems property and the public DataTime property. Both of those are read-only properties so only the getters are showing and then if we look at the top we can see that this is coming from SampleAssembly.dll and if we actually pop this open, this will show the actual path where this assembly lives, so this is the actual file that Visual Studio is reflecting into. Now we can also click into .NET types, so here's, list of string and we can right click and say, Go To Definition and if we look at the top it says List of T from metadata and we see that this is coming from the mscorlib.dll and when we look through this, we see all of the public members that are available in list. Now one thing that's a little bit different about the list is notice that all of these items are collapsed. If we pop these open, we actually have documentation. This is actually part of the XML documentation that's included with these assemblies. So if we do include XML documentation in our code and that file is available to Visual Studio, it will merge the metadata that's coming from the assembly with the XML documentation file. So this is the class definition and that's just one way that Visual Studio will show us metadata. The other thing we can do is we can actually double click on an assembly and open up the Object Browser. So if we double click on SampleAssembly we'll see we get a tree view and this actually includes all of the assemblies that are currently loaded by Visual Studio. So we can see mscorlib is in there, as well as SampleAssembly, which is the one we're looking for. Now if we drill into the assembly, we see a namespace which is also called SampleAssembly and if we drill into that, we see SampleClass, which is the actual class that we have in that assembly. And if we click on SampleClass, we can see the members. So we have the constructor SampleClass, and we have two properties CachedItems and DataTime and if we click on these, it actually shows us more information down at the bottom. So we can see that the CachedItems property is read-only, it only has a getter and we can see it's of type List of string. Now the interesting thing about the Object Browser is these types are all linked. So we can actually click on List of string and it will take us to the List of T Declaration and if we look at the tree, we see that this is coming from the assembly mscorlib and the namespace is System.Collections.Generic. And just like we saw with the class definition window, we have all of the public members of List of T available to us. And if you notice down in the bottom window, we actually have some more information. It's actually pulling in the XML documentation here as well. So if we click on the constructor, we can see a summary down in the documentation. If we click on something that actually needs a parameter like Remove T, we see we have XML documentation that includes the summary, as well as the parameter, and the return type. So again, Visual Studio will merge the XML documentation file with the metadata that's coming out of the assembly and make it available to us in the Object Browser. So this is a really easy way to look at the public members that are available in the assemblies. And how does Visual Studio do this? By using Reflection. Next, we'll move onto another tool that allows us to look at some of the private members, ILDASM.
Demo: Reflection in ILDASM
For our next tool, we'll look at ILDASM that Intermediate Language Disassembler that ships with the .NET framework. For this example, we'll look at SampleClass. This was the same class that we were reflecting into with Visual Studio, and as a reminder, these classes have both public and private members. So we do have some internal private fields for the dataDate and the cacheItems. We also have the public properties the dataTime and the CachedItems. We have the public constructor and we have a private method called RefreshCache. The easiest way to start up ILDASM is to open up a Developer Command Prompt. So in this case, I'll just go to the Start screen and type in command and one of the options is Developer Command Prompt. Now what's nice about the Developer Command Prompt is it includes the path for all of .NET tools that we might need including ILDASM. So, once we have this Command Prompt open, we just have to type in ildasm to open up the tool. Now we can navigate and open up files from here or we can open up assemblies from the Command Prompt. So what I've done here is I've actually navigated to the output folder for this SampleAssembly project that we were looking at. So we can see that this is pointing to the SampleAssemblyV1 folder and then to the bin Release folder inside of that and if we look in that folder, we have SampleAssembly.dll. So I can type in ildasm and then SampleAssmebly and that will open up that assembly. This gives us a very easy to navigate tree view, so we can pop this open and we can find the SampleClass and these are all of the items that are inside of our class, both public and private. So we do see the CachedItems and the DataDate are two private fields and we also see RefreshCache which is a Private method and we can actually double click into RefreshCache and this will show us the IL for that method and if we look at the top, this actually notes that it is private. Now this is actually the tool that I used to take the screenshots that we saw in our first module. There's a couple different ways that we can get to the metadata. One way is to use the menu. We can say View, MetaInfo, Show! and they think it's so important it's Show with an ! and this will actually give us the entire metadata that we have in this assembly. So if we look at this, we'll see some things that we saw at the beginning. So here's our TypeDefinition that shows the SampleClass and this shows us it's a public class that descends from system.object and then we have the two private fields up here at the top like we saw before. Now this metadata is very extensive. If we just page down we can see a number of items including Reference Assemblies, all of the different types, and a lot more information. So there's actually quite a bit in here. Now this MetaInfo actually doesn't show the IL code, but we can get everything together in a single file. So this is kind of nice as an interactive way of looking into our assemblies and again, if we do go towards the geekier sides of .NET, we can actually learn how to read the IL code and figure out what's going on in each of these members. Now there's also a way that we can dump the metadata to a file, so that we can look at it later and we can do that from the Command line. So for this, we'll just say ildasm and again, give it our assembly name, which is SampleAssmebly.dll then, we'll use the switch metadata to say we'd like the metadata, and then we can give it an output file and we'll --- call this metadata.txt. So let's flip over to our Output folder. So here's our Output folder that has the SampleAssmebly.dll and if we hit enter here, we'll see that it generated the metadata.txt file and we can double click this and open it up with Notepad and we can see this is all of the information that's coming out of that assembly and again, up here at the top, we saw the things that we saw before, the class definition, as well as some of the private fields and methods and in this file, if we scroll all the way down, we'll eventually see the IL code, and here, we can see the IL and this is basically all of the IL that's inside the assembly and it's all together in one spot. Now do we have a day-to-day use for this? Probably not, but it is something that's interesting to look at from time-to-time and this is all possible because of the Reflection methods that are available in the .NET Framework. So we've seen that it's possible to get to the private members of our class and view the IL code, but this can actually go a step further when we start looking at decompilers and that's what we'll do next.
Demo: Reflection in JustDecompile
The next tool we'll look at is JustDecompile from Telerik. This is available as a free download and it decompiles .NET assemblies. Let's go ahead and load in our SampleAssmebly, so we'll drag the dll into the window and this actually looks into the assembly using metadata and actually decompiles the IL code as well. So we see we can drill into it. We have SampleAssembly.dll, then we have the SampleAssembly namespace, and then we have the SampleClass. Now notice, in the decompiler window, we have what looks like C# code and when we open this up, it looks almost exactly like the source that we generated. But this is not looking at our source code, this is actually generating it dynamically based on the intermediate languages that's inside the assembly and that's really easy to prove because we can change the language from C# to Visual Basic. So now we have exactly the same methods but in a completely different language. So this shows that it's not actually looking at source files, it's looking at the IL and of course, we can get to the IL code as well, so that we can see how this works. Now this tool is very intriguing as well because we can actually use it to look at things outside of the assemblies as well. So remember in Visual Studio, when we clicked in the Object Browser and navigated to different assemblies? We can do that here as well. So, we can click on list of string and it will say, Do you want to load up mscorlib? Then it will locate the list of T class inside mscorlib and again, notice this is showing both public and private members. It's actually kind of interesting if we actually look at DateTime. So here, we have a DateTime property and if we'll click into that, we can actually use the tree to look at all of the members of DateTime and notice the ones that are grayed out. These are actually private members. So if we click on one of these, it will highlight it in source code window. So have you ever wondered how DateTime.Now works, well we don't need to wonder anymore because we can actually locate it inside of this class and it shows us the decompiled method of how this works. And this is actually kind of interesting because DateTime.Now actually gives us the local machine time, but if we look at the first line in the getter, it gets the utc time first. So this actually gets the utc time and then converts it to local time. So if you're torn between using DateTime.Now and DateTime.utcNow, utc now would actually be more efficient because DateTime now is calling that anyway. Now it's kind of interesting to look at these if statements. If we look at line 276 we see, if num is > this gigantic number, then we're just going to use that number. So what this does is it says, if this is out of the max range if it's > than the max DateTime, then we're just going to supply the max DateTime. Conversely, if we look right below that, if the value is < 0, it returns the min value for the date which is 0. Now decompilers don't give you the exact source code that came in, that's because the compiler does some optimization. So this gigantic long number that we see here, that's probably not repeated in the original source code, it's probably a const that's used in the class. In fact, we probably saw that earlier when we saw the max value. Let's go up and look at MaxTicks and there we actually see that exact same value. So most likely, this const MaxTicks is what's use in the source code, but the compiler optimized it by putting in actual value. So when it gets decompiled, it has that hardcoded value in there. So it's kind of interesting to see what decompilers are actually doing here, but this is all made possible by the metadata that's in the assemblies. So, the decompilation that's turning the IL code into C# that really doesn't have much to do with Reflection, but we do use Reflection to get that IL code to start with and again, we've got access to all of the public and private members that are part of these classes and assemblies.
Demo: Reflection in Moq
Mocking frameworks give us a way to create objects in-memory. These are very useful for unit testing. So for example, here we have the PersonRepository.Interface project that has IPersonRepository. This is the same IPersonRepository that we were looking at with our repository example. Now inside our unit tests, we don't necessarily want to test the repository itself, but we might want to test a class that uses a repository and when we're doing those tests, we do not want to be dependent on an external repository because if the database is down or maybe the network's not available, the unit tests would fail and that's not really what we want to test. So instead of using an actual repository, we can use a mocking framework to create an in-memory instance of this interface that doesn't reference any particular class that we have in any of our projects. Let's take a quick look at that. If we open up a unit test project we'll see a unit test that's using the mock framework, that's Moq, and it's available as a free download. In our test setup, what we want to do is create an IPersonRepository mock object that will return some hardcoded values that we can use in our unit tests. So, since we're mocking up a repository, we're going to call it RepoMock and for this we create a new mock object, and we tell it what interface we would like to use. After that, we use some setup code to tell it how we want it to behave. So in this case, our IPersonRepository has a method called GetPeople and if someone calls the GetPeople method on our Mock repository, we just want them to return a hardcoded collection of objects. In this case, we have a people variable that has two items in it. So rather than creating an entire class just to do this unit test, our Mock object will create an in-memory implementation of this particular interface and it will perform whatever functionality we setup. If you want more information on that particular example, this is actually taken from the Dependency Injection On Ramp course that's offered by Pluralsight. So now that we have a general idea of what Mocking Frameworks do, let's take a look at how they actually use Reflection. For this, we'll look at the source code. The source code for Moq is available for download and this is what the Solution looks like. Now with this in place, we can start searching for the types of methods that we find in Reflection. Some of those include MethodInfo, FieldInfo, and PropertyInfo. So let's go ahead and look for FieldInfo. and if we select one of these items it will show us the source code that's actually using Fieldinfo. Now Moq does a number of different things. In this case, it's actually checking to see if a Member on a particular type is a Field or a Property. If it's a Field, it will interact with it in one way, and if it's a property, it will interact with it in another and we can also look for PropertyInfo. And here's an example where it's actually casting a member to a PropertyInfo type and then trying to call GetGetMethod on it. If we look at GetGetMethod, We see that this actually reflects into the PropertyInfo class and this returns an MethodInfo type if it can actually locate the Get method. So Moq actually has quite a few different features and it can deal with all sorts of different objects. Because of this, it needs to use Reflection extensively. It's looking to see if certain items are methods. So in our test, when we were doing a setup on the GetPeople method it was actually locating that GetPeople on the IPersonRepository interface and associating behavior with it and it's all doing this dynamically in-memory. Now if you are really interested in mocking frameworks, you can again download this source code and look through it to see exactly how it works. Most of us don't need to get into that much detail, but again, it's good to know that somebody else is working with Reflection in very complex ways. So that way, we don't actually have to do that work, someone else is already done it for us.
Demo: Reflection in Unity
As a final stop in looking at developer tools, we'll look at a Dependency Injection Container. In this case, Unity, from the Microsoft patterns and practices team. If we look at our projects that we have here, we can see that we have a number of layers. This includes a View layer, a Presentation layer, a Repository layer, and a Service layer. These layers are all loosely coupled and the Dependency Injection Container will help us snap together our dependencies and make sure that our application works together. If we look at the part of the code where we're actually using the Dependency Injection Container, we see that at the top we have using.Microsoft.Practice.Unity, so that's the namespace we're using. So we have a class level variable and then in our constructor, we're actually newing up an instance of that. Dependency Injection Containers have the concept of a catalog. This is where concrete types are matched up with abstractions. So in this case, we're registering a type and we're saying, if someone asks for an IPersonRepository, an abstraction, we're actually going to provide them with a ServiceRepository, a concrete type. Now if we look at actually using the container, what we do is we ask it to Resolve types. When we ask the container to Resolve a type, what it does is it goes through the constructors and finds out all of the dependencies that are needed. The way it does that is through Reflection. So it finds out what all the types are, what dependencies are there, and it will go ahead and create instances of the types that are needed. Now as you can imagine, this would use Reflection extensively. If you want more information on how this particular sample works, you can check out the Dependency Injection On Ramp course, offered by Pluralsight. Now in this case, we can tell that Unity has to do a lot of Reflection and the Microsoft patterns and practices team actually provides us with the source code so we can actually check that out for ourselves. Let's go ahead and open up the source project. So here, we have the Unity Source project open. Let's go ahead and do a couple searches and see what we find. Let's go ahead and look for GetType, since that's a common thing that we use in Reflection. Let's go ahead and select this one right here and if we look in here, this is an interestingly named method, it's called SearchAssemblies. So as you can imagine, this probably has something to do with the dynamic loading of assemblies. And we can see on line 260 that it is actually calling the GetType method, and we can see that it's passing in an AssemblyQualifiedName. MakeAssemblyQualifiedName is a helper method inside Unity that will create that fully- qualified assembly name that we were looking at earlier. So we can see that Unity is actually doing some of these that we were doing in our own code. But this takes it to the next level. So this does much more Reflection, much more dynamic invocation. And Unity deals quite a bit with constructors. So if we look for ConstructorInfo, we see that's there's many, many places where it's actually using that. Including this FindConstructor method. So as we can see Unity makes extensive use of Reflection. Now do we want to build our own Dependency Injection Container? Probably not, but it's really nice that someone else has gone to all of this work, so that we can take advantage of that.
Summary
We've looked at several developer tools and how they let us reflect into assemblies or use Reflection in order to do their own work. We can easily view public members with Visual Studio. We have the class definition window that will create definitions based on metadata and we also have the Object Browser, which gives us a tree like interface to interact with the metadata. We can also disassemble or decompile our code. ILDASM ships with .NET and allows us to look at the metadata and the IL in our assemblies. JustDecompile is a decompiler from Telerik that will take this a step further and actually provide us with either C# or VB.NET code and this is just one decompiler that's available, there are many, many more and we took a look at a Mocking Framework, Moq. Moq uses Reflection to interact with fields, properties, methods, and events and this is just one of many frameworks that help us with unit testing. And we also spent some time with a Dependency Injection Container, Unity locates constructors, dynamically creates dependencies, and invokes constructors in order to resolve objects. What we should take away from this exploration is that Reflection can make developer tools very powerful and if we find ourselves tempted to use Reflection, such as to interact with private members in a unit test, we should really take a step back and look to see what tools are already available to help us with those tasks. We've seen several features of Reflection. These features include the ability to read and interact with private members of our classes. This leads to an important question, should I be worried? Next up, we'll take a look at some best practices to make sure that our code stays safe from prying eyes.
Should I Be Worried?
Overview
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.
The Scary Bits
We saw a few things early on that we should be concerned about. We saw that the metadata shows us all of the members in our classes, even the private members. And we also saw that we can easily get the value out of a private field. When we looked at this earlier, we said that this is not good practice, since we may end up with unattended side effects. But we also need to be aware that someone else can reflect into the code that we generate and get access to those private members. This means that someone can get access to values of private variables, execute private methods, or even look inside of methods to see what types of algorithms we're running. Let's take a look at this in action.
Demo: 'Hacking' .NET Assemblies
Sometimes we're tempted to put passwords inside of our source code. This might be because we have an application level password, that's used to access a database. But what we've seen so far is that the metadata makes this available to anyone who has access to these dlls. Let's see this in action. Here we have our SampleClasses that we we're looking at earlier. Let's go ahead and add some secret words to these. So let's create a private string and we'll call this magicWord and we'll set this = to Abracadabra and we'll create another private string and we'll call this password and we'll set this = to Open Sesame. Now, let's go ahead and build this assembly and open it up inside ILDASM. So again, I have a Visual Studio Command Prompt open so I can say, ildasm and then we'll say SampleAssebly.dll. Now if we open this up, we do see our private variables for magicWord and password. Now if we double click on these we really don't see much because this is just the field definition. But if we open up our constructor, look at this, we have our words Abracadabra and Open Sesame available in plain text. This is a problem and as we saw before, even though we have a private method, we can still look at this and see exactly what it's doing. So if we had some kind of proprietary algorithm that we used inside of our business, it could be exposed if we're not careful about it and again, ILDASM just shows us the IL code, but another tool like JustDecompile can show us this same code in C#. So what we can see by this that is we don't want to put secret stuff into our assemblies or at least assemblies that other people can get their hands on. Now let's look at some best practices because there are some good ways to deal with this particular situation.
Best Practices
So the question is, is .NET code safe? And the answer is that .NET is really no different than other compiled languages and environments. If someone has access to the compiled file, he can decompile or disassemble it. What's the difference between decompiling and disassembling? Decompiling is turning the compiled code back into source code, at least as much as possible. Disassembling is turning the compiled code into something closer to what the machine understands such as assembly language, but it's still readable by humans. In the .NET world, ILDASM is a disassembler, which shows the output in the Microsoft Intermediate Language. But there are also decompilers that turn assemblies into source code. We saw an example earlier with JustDecompiler from Telerik. This could output C#, VB.NET or IL. Some other options include .NET Reflector from Red Gate Software and dotPeek from Jet Brains and there are many others as well. But in the Java world, there are a number of decompilers include Procyon, Krakatau, and CFT among many others. And there are also disassemblers that work against Win32 exe and dll files. Examples of these include Boomerang, ExeToC, and IDA. And JavaScript isn't even compiled when it's transported to the user machine. So rather than comparing the safety of .NET assemblies to programs compiled in other languages and environments, we really should accept that if the files are on the user's machine, he can crack them open and look inside, but that does not leave us helpless. There are several things that we can do to minimize the risk. Let's say that we have a proprietary algorithm in our code. Maybe we have a highly optimized way of processing data and we want to keep these details confidential, since that's what makes us competitive in our business. The best way of doing this is to never let the secret code out onto our clients machines. We can do this by having the proprietary code run on our servers. The code that is running on our client machine simply asks the server for the results. When the client makes a request, we can make sure that there is some type of authentication involved, so we know that it's coming from a legitimate client. Then the server can process the data using the proprietary algorithm and return the results. This is a very common architecture and it is often implemented through services and referred to as Service Oriented Architecture or SOA. There are other advantages to SOA, but having control over how our code is exposed to the outside world is a huge advantage. We've seen how easy it is to get to the strings inside of code. Because of this, passwords and other secret data should not be compiled into that code that runs on a client machine. There are several different approaches to this. The preferred option is that we eliminate the need for a hardcoded password. This would mean that we switch our authentication so that it's based on user rather than on a hardcoded password, but this is not always possible or practical. If we really need an application password, then we can have the client application ask for it from the server. An even better option would be to run the code that requires a password, on the server itself. That way, the client application does not need the password at all. And I've seen a couple situations where a hardcoded password could not be avoided. In this instance, the developer obfuscated the password, so instead of having a plain text string in the code, the password was actually calculated using character math and some other interesting things. A determined hacker could still get to it, but there was nothing that obviously looked like a password, when simply scanning through the code.
Obfuscation
So we mention that we could obfuscate our code to make it more difficult to crack. But there are obfuscation tools that can do this for us automatically. What is obfuscation? Well, it's a way to make the IL code less readable. We cannot prevent Reflection, but we can make it more difficult. Obfuscators can do several things. One of the primary things they do is rename the private members of our code. Our private variables, fields, and parameters are given nonsense names such as a, b, and c. Our private methods are also renamed. Since the names are changed everywhere in the assembly, the code continues to work normally, but it is much more difficult for a human to understand. This effectively breaks reflecting into private members. Remember back to our example of looking at the private cached items field? This field would be much more difficult to find if it was simply named b. Even if we used Reflection to give us a collection of all of the private members, we would have difficulty telling one from another. Obfuscation does not affect public members. The names of these items need to remain unchanged, otherwise, our applications that references the private members would break. In a way, this technique is very similar to what's used in JavaScript minification. JavaScript Minification is not designed to obfuscate code. The reason that JavaScript code is minified is so that it will download to the client faster. Here's what the jQuery library looks like in its standard non-minified state and here's the jQuery library that has been minified. We can see that the function parameter names have all been changed to single characters and also all of the white space has been removed. This makes things much more compact. The readable version of jQuery is 261 kilobytes. The minified version is only 92 kilobytes. Now all of this code still works, the computer can read it, but it is very difficult for humans. More advanced obfuscators will take things a step further. Instead of simply making the IL more difficult for human to read, they actually try to prevent disassembly. One technique that I've seen that instead of using nonsense names like a, b, or c, the obfuscator replaces names with nonprintable characters. These are still valid IL, so the code still runs. But when a disassembler or decompiler tries to show the code, the decompiler may break. But then, the decompilers are improved to account for this. Ultimately, we end up with an ongoing batter between obfuscators and decompilers. Here are just a few of the obfuscators that are available. Dotfuscator has a free and paid version. The free version, which has fairly limited functionality ships with Visual Studio. Other options include Eazfuscator and Deep Sea Obfuscator. Both of these are paid products that offer fully functional evaluation versions. Let's take a look at a quick example with the free version of Docfuscator. This will give us a general idea of how these tools work.
Demo: Obfuscation
So we'll explore Obfuscation in .NET by using the same sample class that we've been looking at. In this case, we still have our magicWord and password inside of our project as private fields. Let's go ahead and open up Dotfuscator, our obfuscation tool. So we'll go to the Tools menu and open up PreEmptive Dotfuscator and Analytics. Now what it wants us to do is actually put assemblies inside the Input. So let's go ahead and open up our Output folder and drag something in. So here, we have our Output folder with our SamplAssembly.dll. Let's go ahead and just drag and drop this in here and we'll just keep all of our defaults and go and Obfuscate our project. So now, if we look at our Output, we'll see that we have a new folder called Dotfuscated and in here, we have our new SampleAssembly. Let's open this up in ILDASM. SO let's go to our Command Prompt and actually go to the Dotfuscated folder and we'll say, ildasm SampleAssembly. Now, if we open up this SampleClass, we'll see things are a little but different. Notice that instead of having our private members, which we're called magicWord, password, CachedItems, and DataDate, we just have variables a, b, c, and d. Now we can tell from the DataTypes that c is probably our DataDate and d is probably are CachedItems, but a and b are both strings so we might not know which is which. Also remember, we do have a RefreshCache private method. Here we just have a method called a and if we open up a, we'll see that this is actually interacting with some of other variables. So we can see that this is actually interacting with both c and d. So even if we were able to understand this code, it would be much more difficult to follow since the variables do not have meaningful names. Now this does nothing about our actual secret words. If we open up our constructor, we'll still see Abracadabra and Open Sesame there in plain text. So obfuscation won't help us with those types of things. Now let's open up our obfuscated assembly and JustDecompile to see how that views it. So we'll just drag the SampleAssmebly into JustDecompile and let's expand our class. Now you can see here that we do still have those single character variables names a, b, c, and d and then also we have our private method a, way down at the bottom. And if we open this up, we can see that it's setting c to the current DateTime and it's actually adding an item to the d collection. Now in this case, we just have a few private members. So even though it does make it more difficult to read, it's actually pretty easy to decode this. But if we had a much bigger class with a large number of private methods, variables, parameters, and so forth it gets very difficult to decipher very quickly and this is one of the reasons why we, as developers, like to give our fields and methods meaningful names, so that we can follow the code easily. Now you may be curious about one thing that's in our Dotfuscated folder that we have. In addition to the SampleAssembly.dll, we also have a Map.xml. What this does, is it actually maps our obfuscated code, back to the original source code. So this way, if we do actually need to debug this for some reason, we can find the information that we need. So if we look at this section in the method list, we actually have a method and it shows the original name was RefreshCache and its new name is just the single letter a, and if we scroll down to our field lists, we'll see that CachedItems is now called d, DataDate is now called c, magicWord is a, and password is b. So this is something our obfuscation tool can use to help us debug into our assemblies. Now is obfuscation something that we should really consider? I would say it really depends on your environment. In a lot of situations, it's much better if we just don't have the code on the client's machine at all. If we can actually keep our secret code on our own servers, then we have full control over it. But if we do need to release it to our clients, then obfuscation can make our code more difficult to understand if someone tries to decompile it.
Course Summary
Reflection makes it very easy for someone to decompile our .NET applications. Do we need to be worried? My answer is that we should be just a little bit worried. We should not be worried specifically about our .NET code because applications written in other languages can also be disassembled or decompiled. But we do need to be aware of this so that we can make sure we keep our confidential items confidential and we can do that by following some best practices. We want to keep our proprietary code on our server, under our control. If someone does not have access to an assembly, then he cannot decompile it. Along the same lines, we should keep passwords and other secret data out of the code that runs on client machines. One way of doing this is to implement a service infrastructure where our client machine asks the server anytime it needs secured information and we also say that obfuscation is an option. This generally does not prevent our code from being disassembled or decompiled, but it does make it more difficult and it also makes it more difficult for people to reflect into the private members of our classes. So a little bit of worry is fine. It leads us to make smarter choices about how we build our applications. But .NET is not really anymore exposed then other development environments. So now that we've come to the end, let's review our goal and see how close we were to meeting it. Our goal was to find the practical parts of Reflection and making sure that we balance safety, performance, and flexibility when we're using it in our applications. We took a fairly extensive journey in order to meet that goal. First, we looked at what Reflection is, including some of the major classes such as Type, Assembly, and Activator and we also saw some drawbacks. How Reflection can be slow and at time dangerous, if we're accessing private members. Then we moved onto the practical uses in our code. We saw that we can use Reflection to dynamically load assemblies and create instances of types that we can then use in our code. We also saw how we could deal with Generic types when we're using assembly-qualified names and fully qualified names. Then we moved on to how we can Discover types. We actually created a business rule engine that dynamically loads up assemblies just out of the file system. It looks through all of the dlls and pulls out the types that it's able to use. Then we saw how Reflection is used in our Developer Tools. The primary focus of this was to understand that there are extensive uses of Reflection and someone else has probably already built a tool that we can use, if we really need that. And finally, we ended with the question, Should I Be Worried? And the answer is yes, but just a little bit and no more than you should be worried in other development environments. Let's review some of the details of the journey we took. We looked at the capabilities and some Best Practices with Reflection. This included learning about what metadata is in assemblies. We also looked at several features including dynamically creating objects, and invoking members that we don't have direct access to. And we also saw the drawbacks. Reflection is significantly slower than normal method calls. Our creation calls were 5 times slower when we used Reflection and if we dynamically invoked a method, it was 30 times slower using Reflection. Based on this, we came up with the best practice of limited Reflection to just where we need it and that was key to figuring out how to practically use this in our own applications. In our first example, we saw how to dynamically load types based on configuration. In this case, we were loading up a repository so that we could interact with the data store of our choice. We saw several methods including the GetType method of the Type class, the typeof keyword in C#, and the CreateInstance method on the Activator class and we also talked a bit about Type Names including the Assembly-Qualified name, which includes the FullName of the type, along with the AssemblyName, the Version, the Culture, and the PublicKeyToken, and we also saw how the FullName changed when we used Generic Parameters. The syntax was a little strange to see the ` and the square brackets, but once we get used to it, it's not difficult to understand and we saw in this application that our focus was on Maximizing Performance by Limiting Reflection. We kept our Reflection isolated to one part of the application and we tried to limit the number of times we called those methods. In fact, we ended up just calling them one time when our application was starting up. Then we moved on to how we can dynamically discover types in assemblies. This allowed us to create a Business Rule Engine that made our application extremely flexible. By adhering to an interface and just putting assemblies into a particular folder, we could dynamically load up assemblies and process rules at Runtime. This allows our clients to build their own business rules that meet their unique needs. It makes our application extremely flexible. After that, we explored a number of developer tools. We saw how we can view public members in the Visual Studio Class Definition Window, and the Object Browser and we also saw some disassemblers and decompilers, and we saw how it turns the assemblies into human readable code. We also looked at some tools that we integrate with our own applications including Moq, a Mocking Framework and the Unity a DI Container. Both of these libraries make extensive use of Reflection and in fact, none of the functionality that's available in these tools would be available without Reflection. And finally, we asked the question Should I Be Worried? And the answer is yes, but just a little bit and no more worried than we should be if we we're developing in other environments. By adhering to best practices, we can make sure that our confidential information stays confidential. We can maintain control of our proprietary algorithms, and we can also ensure that we limit access to our code and if we need it, obfuscation is always an option. And that wraps up our journey on Practical Reflection in .NET. Hopefully, you're going away with a much better appreciation of how Reflection can actually be used in our own code. And if you are interested in the geekier sides of .NET, there's a ton more to explore in the Reflection world. If you want to take the next step, there is an MSIL course available on Pluralsight. That will take you through how the Microsoft Intermediate Language works and it also does do some IL generation. Some of the other topics that we touched on including Mocking and Dependency Injection, and Pluralsight offers courses on these items as well. So hopefully you're leaving with a better appreciation of Reflection and how you can use it practically in your own applications.
