This post is inspired from another post (in Romanian, sorry for the not Romanian speakers), which asks about the usefulness of System.Reflection.Assembly class.
This class is primarly your one stop shop if you want to implement a plugin host in .NET Framework. The implementation of a plugin host in .NET Framework is somehow different than the old "C/C++" way of implementing by the simple fact that we no longer have header files to ship to the plugin writers in order to describe our interface. But no worry, this doesn't means that it's more complicated to do such a thing in .NET. The closest way to do this is to generate a class library DLL project, that doesn't implement code (or maybe just some utility classes) but to have the definitions of our interfaces. This is the easy way, but in my opinion it's not the cleanest way. If we go this route we will have to ship our "interface" DLL to clients since it's a required dependency. For large projects where you have hundreds of files shipped to client, it might be fine, but for small project where you ship just your host and few plugins the clutter it's less desirable. A clever way to do this is to implement your interfaces in your host project, and make the plugins dependant on your host .exe file. This way you will have always up-to-date dependencies, since you cannot break the host (or, your code won't compile at all). Prior to Visual Studio 2005, you weren't able to add to a project a dependency to another project whose output is a .exe file. This was recognized more or less a bug, since .exe and .dll files doesn't differ at all internally, so the workaround for Visual Studio 2002 and 2003, was to build your project, get the output, rename it to .dll extension, and add the dependency to your plugin project.
If you are new to plugins in .NET and you come from C/C++ plugins a warning that might save you a lot of time: do not try to reimplement your host interfaces with the same definition in your plugin project, just to remove the intermediary DLL file dependency (the easy way above). IT WON'T WORK. Objects in .NET (interfaces, classes, etc) have the same identity only if they have the same name AND come from the same assembly.
Someone said there that is not normal that Visual Studio accepts dependecies to .EXE files. Well, the fact that they prevented explicitly this (I believe, since they were filtering some types of projects) in VS 2002 and 2003, and now it works in 2005, it might mean that some people finds the feature useful. And I come and say why not accept dependencies of .EXE files/projects?