Working with Reflection

Introduction

Reflection is how we access metadata about code at run time. This opens up some wonderful dynamic runtime possibilities, but it can also be leveraged to create some exciting code generation opportunities.

In this chapter, we will look through the various types of metadata that we have available, showing how the pieces fit together. Once we have finished this survey of reflection techniques, we will tie it all together with a code generator that will load an assembly and find all of the types that are derived from ApiController. For each of these classes, we will find the actions that are exposed and create a method to automate calling that action using HttpClient.

Throughout this chapter we will add functionality to a new class called ReflectionHelper that we can use to simplify accessing eeflection data. Go ahead and a new class called ReflectionHelper in the T4Utilities project that we created in Chapter 4.

Load an Assembly

Loading an assembly can be a bit tricky. Without proper care, you can wind up locking the assembly that you are trying to load. If you are reflecting on an assembly being built by your current solution, you could be stuck having to shut down Visual Studio every time you run your template.

We have a couple of options to avoid this. The most straightforward approach is to read the contents of the assembly into a Byte array, and then load the array. With this approach there is no file to lock. We can see a simple implementation in Code Listing 54. Add the following method to the ReflectionHelper class that we added to the T4Utilities project.

Load an Assembly Without Locking

AssemblyName is a handy object in the Reflection namespace that simplifies the process of referring to an assembly and ensuring that you are referring to the correct one. It can be initialized like this:

Initializing an AssemblyName

This approach to loading an assembly will ensure that you can continue compiling the code that generated the assembly being loaded and rerunning the templates using that assembly without clashing with each other.

Note: This is very important, because nothing is more frustrating than having to exit and restart Visual Studio just to unlock an assembly so you can recompile. This is an area that has been greatly enhanced in the more recent version of Visual Studio, which used to lock assemblies behind the scenes in many places. But as of Visual Studio 2013, this should be a thing of the past. Any locked assemblies should be self-inflicted, and avoidable by following this simple trick.

Get a List of Types

While gathering the metadata to support code generation, we will usually be interested in multiple types in an assembly. This means that we will call GetTypes to get all of the types in the assembly. Depending on your metadata requirements, you may know which type you are interested in. If this is the case, you can call the GetType method, which will return a single Type object.

Tip: In general, you will be better off making a single call to GetTypes rather than several calls to GetType. Unless you are explicitly interesting in a single type, GetTypes is probably the better choice.

Getting a list of types is pretty straightforward:

Getting a List of Types

Note: The list of types is cached to improve performance. Getting the list of types is a fairly expensive operation. If the TargetAssembly has not changed, there is no reason to repeatedly to through the cost of building this list.

We can build on this to simplify some common filters by running LINQ queries against the results, using any of the methods or properties exposed by Type.

For example:

Filtering Types By NameSpace

Or

Getting all Interfaces

We can add a couple of helper functions to give us even more options:

Determing if a Class has a Particular Base Class

The GetBaseClasses method will walk the entire inheritance hierarchy back to object and return this as a list. HasBaseType will determine if any of the items returned matches the item that we are looking for.

With these helper functions, we can now include a filter like this:

Filtering Types Based on Base Class

Once we have an Assembly loaded, we can easily get all of the types, a single type by name, or list of types filtered any number of ways.

Get the Properties of a Type

Once we have identified the type or types that we are interested in, we can start learning more about the members in that type.

Again, getting the properties is fairly straightforward:

Getting the Properties of a Type

There are some built-in filters that .NET provides directly through the BindingFlags that can be passed to the GetProperties method. As will see shortly, these BindingFlags can be passed to a number of places.

Depending on your metadata requirements, you may want different filters, but a common practice is to return only the public properties defined at this level of inheritance.

Adding BindingFlags to GetProperties

This will filter the properties and only return the public ones defined at this level of inheritance that are not static.

Getting the Methods of a Type

Getting the methods defined in a type is very similar to getting the properties.

Getting a List of Methods Including the Binding Flags Filtering Out Properties

We are using the binding flags that we saw earlier, but I add an extra filter. We want to remove the methods that start with get_ and set_. These are the methods that implement the getters and setters for the properties in the type. As a general rule, when we are dealing with methods, we are not interested in the methods that implement a property. We will deal with those methods as we deal with the property.

Methods also have a couple of interesting properties worth exploring: ReturnType and Parameters.

We may want to filter based on the ReturnType like this:

Filtering Methods Based on Return Type

Alternately, we may want to filter based on some attribute of the parameters.

Ficltering Based on the Parameters

Get the Attributes of a Type, Method, or Property

The GetCustomAttributes method is defined as part of the MemberInfo class. Fortunately for us, this just so happens to be the base class for types, methods, and properties. We can easily write a method to get the custom attributes for any of these types like this:

Getting Attributes

Once we have this list of attributes, we can define a handy function to easily determine if the member that we are interested in has a particular attribute.

Checking to See If a Member Has a Particular Attribute

Now that we have the handy HasAttribute method, we could write new filters against properties or methods, taking into account their custom attributes.

Filtering Properties by Attribute

One key point to remember here is that even though we think of the “Required” attribute, the full name for this attribute is “RequiredAttribute”.

Defining a Custom Attribute

Now that we know how to access the types in an assembly and the various members of a type, as well as the custom attributes for each of these, the next question is: “How do I create my own custom attribute?”

It’s pretty straightforward; all we need to do is define a new class and derive it from System.Attribute.

Let’s go ahead and add a new project to our solution and name it book.Model. Let’s add a new class to this project called HideMethodAttribute.

Add the following code to HideMethodAttribute:

Defining a Simple Attribute

The AttributeUsageAttribute might seem a little strange at first. It simply instructs the compiler that this attribute is valid only on methods. Thanks to this attribute, you will get a compile error if you try to use it anywhere else.

Properties for the attribute are simple properties added to this class, defined like any other property, set when it is applied, and accessed during code generation. That is it for a simple attribute. The interpretation and meaning of the attribute comes from what we do when we detect that the attribute has been applied to a method.

Pulling it All Together

Go back to the solution that we have been working in, and add a new project. This time, add a new MVC Web API Project.

Adding a Web API Project

Add a reference to the book.Model project that we created when we discussed creating a custom attribute. In this project, let’s create a new class called EmployeeModel.

Add the following code to EmployeeModel.cs:

Some Common Properties for an Employee Model

Now let’s go back to the Web API project, and create a controller based on this model.

Add Controller Specifying Scaffolding Options

In the Scaffolding options section, we can specify the Template; this is the MVC template that will be used to generate the controller. We will select MVC controller read/write actions and views. We also specify the Model class and the Data context class for Entity Framework. In this case, we selected Create a new one, and were prompted for the name to give it.

With this minimal information, the scaffolding system will generate the full controller and the Entity Framework context.

Let’s look at the code generated for the controller.

Generated Controller Code

As you can see, this controller includes actions for each of the HTTP verbs GET, POST, PUT, and DELETE.

It would be nice to have a proxy class to automate calling these methods using the HttpClient library available by using the Microsoft.Net.Http package available through NuGet.

Let’s go back to our solution, and in the book project, use NuGet to add the Microsoft.Net.Http package.

Install Microsoft.Net.Http

Now, in the book project, we want to create a new text template and name it services.tt.

In order to access the book.WebApi assembly, we will need to add a few references to the template.

Assembly References Needed for Services.tt

To make the code a little bit simpler, we will add some basic import directives.

import Directives Needed by Services.tt

Now with the basics for our directives out of the way, let’s think about the type of class that we want to generate.

Let’s generate a single class with a method for each API action that it finds. We will start by initializing our ReflectionHelper, and then outputting some boilerplate code:

Initializing the Services template

The bulk of the code generated will be the calls to the various actions that we find in the assembly.

Now let’s turn our attention to the feature block for the template. We need to define a couple of properties for the template that we initialized earlier, as well as the OutputActionCalls method.

The OutputActionCalls Method

The properties are defined just like any other property, and the OutputActionCalls is rather straightforward. We hand most of the heavy lifting over to the ReflectionHelper. Because we want to handle the various actions differently, we will filter them out by checking their attributes to see which ones handle which verbs.

Note: This does require changing the code generated by the Web API scaffolding. If you don’t want to have to make this change, you could also identify which actions go with which verbs by matching the naming conventions on the methods.

Let’s go back to the controller and some action selector attributes to the generated code. Because this is generated from scaffolding, we are free to change this code as needed—this was always a onetime code generation.

Let’s look at these various process methods.

Supporting Process Methods

The actual implementation of this method is not necessarily very exciting, but there are a couple of things to note. First, we make a call to get the parameters as a string, and we want to add an extra parameter for the URL. We first need to do a little bit of conditional logic to properly handle the cases where there were originally no parameters.

The other item potentially of interest is the use HttpClient. For each verb, we will call the appropriate method corresponding to the verb that we are working with. Here, we call GetAsync. For POST, we will call PostAsJsonAsync. For PUT, we will call PutAsJsonAsync, and for DELETE, we will call DeleteAsync.

For your reference, here are the remaining methods defined in this template:

The Supporting Process Methods for the Services template

Note: This is not intended to be a guide to coding Web API calls. For best practices and better understanding the Web API, please refer to the Succinctly Web API book.

An important takeaway from this example should be how easy it would be to modify the template to change the generated code as your best practices improve.

Summary

In this chapter we have covered most topics related to accessing data through reflection. We saw how to load an assembly without locking it, and we explored how to get and filter the types contained in the assembly. We have seen some simple ways to format the name of some complex types so that they look nice in our generated code.

We explored retrieving and filtering the basic components of type that would commonly be used in code generation. There are similar methods available to retrieve the fields and events from a type.

Throughout this chapter we have seen that .NET keeps a wealth of information for us about the code being run. The only drawback is that the code has to be compiled before any of this information is available through reflection.

In the next chapter we will explore ways to retrieve similar information directly from the source code without having to wait for the code to be compiled.