Why is the use of reflection in .NET recommended?

Is it definitely a good practice to use it?

What are some possible situations in a project that need reflection?

The main value of Reflection is that it can be used to inspect assemblies, types, and members. It's a very powerful tool for determining the contents of an unknown assembly or object and can be used in a wide variety of cases.

Opponents of Reflection will cite that it is slow, which is true when compared to static code execution--however Reflection is used throughout the .NET framework, and provided that it's not abused it can be a very powerful tool in the toolkit.

Some useful applications:

• Determining dependencies of an assembly

• Location types which conform to an interface, derive from a base / abstract class, and searching for members by attributes

• (Smelly) testing - If you depend on a class which is untestable (ie it doesn't allow you to easily build a fake) you can use Reflection to inject fake values within the class--it's not pretty, and not recommended, but it can be a handy tool in a bind.

• Debugging - dumping out a list of the loaded assemblies, their references, current methods, etc...

There are many uses for reflection:

1. Iterating through properties in an object.
2. Invoking a method that's defined at runtime.
3. Many other other on the same vein.

However, one of my favorite uses of reflection is to find properties that have been marked with attributes.

For example, I've written attributes that mark which properties in my classes should be indexed using Lucene. At runtime, I can look at any class, and figure out what fields need to get indexed by just querying the class for "marked" properties.

Reflection is just a way of investigating objects during run-time. You shouldn't use it if you don't need to do just that.

Reflection allows an application to collect information about itself and also to manipulate on itself. It can be used to find all types in an assembly and/or dynamically invoke methods in an assembly.

System.Reflection: namespace contains the classes and interfaces that provide a managed view of loaded types, methods, and fields, with the ability to dynamically create and invoke types; this process is known as Reflection in .NET framework.

System.Type: class is the main class for the .NET Reflection functionality and is the primary way to access metadata. The System.Type class is an abstract class and represents a type in the Common Type System (CLS).

It represents type declarations: class types, interface types, array types, value types, enumeration types, type parameters, generic type definitions, and open or closed constructed generic types.

Eg:

using System;
using System.Reflection;

static class ReflectionTest
{
    public static int Height;
    public static int Width;
    public static int Weight;
    public static string Name;

    public static void Write()
    {
	Type type = typeof(ReflectionTest); // Get type pointer
	FieldInfo[] fields = type.GetFields(); // Obtain all fields
	foreach (var field in fields) // Loop through fields
	{
	    string name = field.Name; // Get string name
	    object temp = field.GetValue(null); // Get value
	    if (temp is int) // See if it is an integer.
	    {
		int value = (int)temp;
		Console.Write(name);
		Console.Write(" (int) = ");
		Console.WriteLine(value);
	    }
	    else if (temp is string) // See if it is a string.
	    {
		string value = temp as string;
		Console.Write(name);
		Console.Write(" (string) = ");
		Console.WriteLine(value);
	    }
	}
    }
}

class Program
{
    static void Main()
    {
	ReflectionTest.Height = 100; // Set value
	ReflectionTest.Width = 50; // Set value
	ReflectionTest.Weight = 300; // Set value
	ReflectionTest.Name = "ShekharShete"; // Set value
	ReflectionTest.Write(); // Invoke reflection methods
    }
}

Output

Height (int) = 100
Width (int) = 50
Weight (int) = 300
Name (string) = ShekharShete

You can use reflection to implement a system of plugins for example. You just look for all DLL's in a folder and through reflection check if they implement a certain plugin interface. This is the main purpose for which I used reflection, but I also used it to implement a generic home-brew object serialization, where performance was not the greatest concern.

As mentioned above, performance will take a hit.

Another great advantage is that you can dynamically load assemblies, perform property manipulation even though you may not have the scope to see what to change, etc.

The reasons to use this are plenty. Here is an introduction if you need.

Reflection is commonly used in IoC containers. Let's say you want to register every concrete class the ends with the word "Controller". Reflection makes that a piece of cake.

I've also used reflection to manipulate private fields when unit testing classes.

The very useful XmlSerialization class relies on reflection. You don't have to deal with reflection yourself to use serialization, the serialization classes invoke reflection themselves. But it helps to tag your code with Attributes that guide how objects are serialized. The serialization classes use reflection at runtime to read those attributes. In the end, the process seems almost magical, requiring very few lines of explicit coding in a application; it's reflection that makes that convenience possible.

XmlSerialization itself is awesome not only because it is a very convenient way to create data files from an application, it's also a very easy means of generating human readable records of a program's internal data model for debugging purposes.

Coming from C++ and having needed some simple class hierarchies, I can say that the is keyword is invaluable!

class MenuItem : Item { }
    
foreach(Item items in parent.ChildItems) {
    if (item is MenuItem) { /* handle differently */ }
}

P.S. Isn't reflection slightly expensive, btw?