In my current framework's design, I peruse all types of specific assemblies and do work based on the types found. The assemblies it searches through are determined by the application bootstrapper/initializer. The assemblies are compiled in, so they can be strongly referenced via: typeof(SomeTypeInTheAssembly).Assembly. This is nice because the bootstrapper code has a strong reference to a type in the assembly and there's no fumbling about with fully qualified names as inline strings which need to be manually kept up-to-date if the assembly qualified name changes. But I didn't like referencing some completely unrelated type in the assembly and being dependant on that type being there. (what if it moves to another assembly? What if we deprecate/delete the type? Change its namespace?) In the code, it looks a bit weird too:
FrameworkAssemblyReader.Read(typeof(SomeAssemblyNamespace.SubNamespace.GraphingCalculator).Assembly);
Now in my bootstrapping code, I have a direct dependency (although a pretty trivial dependency) on GraphingCalculator which has nothing to do with the bootstrapping stage (and as a GraphingCalculator, it certainly has nothing to do with obtaining assembly references). To avoid this, in each assembly I intend to use in this way, I added a class in their root:
namespace SomeAssemblyNamespace
{
public static class AssemblyReference
{
public static System.Reflection.Assembly Get
{
get
{
return typeof(AssemblyReference).Assembly;
}
}
}
}
Which isn't too bad because then my bootstrapping code looks like:
FrameworkAssemblyReader.Read(SomeAssembly.AssemblyReference.Get);
But now, I have about a dozen or so assemblies with this AssemblyReference class copy/pasted and I only expect it to continue to grow as applications are