title: Get assembly reference without reflection or a known type
body: <p>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: <code>typeof(SomeTypeInTheAssembly).Assembly</code>.  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:</p>
  
  <pre><code>FrameworkAssemblyReader.Read(typeof(SomeAssemblyNamespace.SubNamespace.GraphingCalculator).Assembly);
  </code></pre>
  
  <p>Now in my bootstrapping code, I have a direct dependency (although a pretty trivial dependency) on <code>GraphingCalculator</code> 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:</p>
  
  <pre><code>namespace SomeAssemblyNamespace
  {
      public static class AssemblyReference
      {
          public static System.Reflection.Assembly Get
          {
              get
              {
                  return typeof(AssemblyReference).Assembly;
              }
          }
      }
  }
  </code></pre>
  
  <p>Which isn't too bad because then my bootstrapping code looks like:</p>
  
  <pre><code>FrameworkAssemblyReader.Read(SomeAssembly.AssemblyReference.Get);
  </code></pre>
  
  <p>But now, I have about a dozen or so assemblies with this <code>AssemblyReference</code> class copy/pasted and I only expect it to continue to grow as applications are built ontop of the framework.  So my question is, is there a nice way to avoid the <code>AssemblyReference</code> class duplication and still programmatically pass in assembly references to the base framework, yet avoid the fuzziness of pointing to some arbitrary/unrelated type in the target assembly?  My googlings seem to tell me that there's no API or language feature that lets me strongly point to an assembly (like <code>typeof</code> for classes), but I'm hoping someone here has come up with a better solution than I have that avoids the class/code duplication.  Also of note, the code is sometimes compiled against Silverlight so I know that can tend to limit some of the API/techniques. Thanks!</p>
  
  <p>EDIT: Just to add another monkey wrench, based on answer by "the coon", I should mention that I don't always load the same assemblies.  For example, I might have a "CarBuilding" assembly that's applicable for some applications but not all.  It's up to the bootstrappers to tell me which ones they wish to use (along with any custom ones the developer is employing)</p>
  
  <p>EDITx2: To answer Jon Skeet's question:  Clients (or us internally) will create any projects/DLLs they wish to support their application.  In turn, these projects will reference the internal base framework.  Their projects <em>may</em> contain resources (3D files, images, text, localization, etc.) and plugin-esque classes (they implement scripts which we discover and instantiate/execute as needed during the lifetime of the application).  Additionally, our system supplies <em>optional</em> modules (DLLs) which contain reusable plugins/content which clients (or us) can leverage when making specific applications.  So you might see a project structure like:</p>
  
  <pre><code>Solution
      -&gt;MyAppBootstrapper_Android
          -&gt;MyAppGUI_Android
          -&gt;MyAppFramework
          -&gt;MyAppResources
          -&gt;MyAppAdditionalResources_Android
  
      -&gt;MyAppBootstrapper_Silverlight
          -&gt;MyAppGUI_Silverlight
          -&gt;MyAppFramework
          -&gt;MyAppResources
          -&gt;MyAppAdditionalResources_Silverlight
          -&gt;BaseFrameworkGraphingModule
  </code></pre>
  
  <p>The bootstrapper projects wire up dependencies and provide which projects/dlls (assemblies) should be provided to the base framework for discovery.  Note that in this case, "MyApp" shares its own mini-framework and shared resources across both Android and Silverlight builds, but both have their own references independent from one another.  The Silverlight one takes advantage of the <code>BaseFrameworkGraphingModule</code> and they have their own resources specific to the platform.</p>
  
  <p>So in the bootstrappers in the projects look something like (albeit simplified):</p>
  
  <pre><code>namespace MyAppBootstrapper_Android
  {
      public class Bootstrapper
      {
          public void Setup()
          {
              FrameworkAssemblyReader.Read(MyAppGUI_Android.AssemblyReference.Get);
              FrameworkAssemblyReader.Read(MyAppFramework.AssemblyReference.Get);
              FrameworkAssemblyReader.Read(MyAppResources.AssemblyReference.Get);
              FrameworkAssemblyReader.Read(MyAppAdditionalResources_Android.AssemblyReference.Get);
          }
      }
  }
  
  namespace MyAppBootstrapper_Silverlight
  {
      public class Bootstrapper
      {
          public void Setup()
          {
              FrameworkAssemblyReader.Read(MyAppGUI_Silverlight.AssemblyReference.Get);
              FrameworkAssemblyReader.Read(MyAppFramework.AssemblyReference.Get);
              FrameworkAssemblyReader.Read(MyAppResources.AssemblyReference.Get);
              FrameworkAssemblyReader.Read(MyAppAdditionalResources_Android.AssemblyReference.Get);
              FrameworkAssemblyReader.Read(BaseFrameworkGraphingModule.AssemblyReference.Get);
          }
      }
  }
  </code></pre>
  
  <p>So for each application built on top of the base framework, a bootstrapper is created that indicates which assemblies to include (and some other irrelevant wiring work).  To answer the question specifically, the project has compile-time references to each assembly needed (this pulls double duty as it ensures that all DLLs are packaged together for Android/Silverlight deployment) as they are not dynamically downloaded to the user's smartphone or Silverlight app but packaged in the initial download.  Your question as to how the Bootstrappers know which assemblies to use, well the developer knows and places necessary <code>FrameworkAssemblyReader.Read</code> calls.  I hope this helps!  Thanks for taking the time to look at it.  I have a feeling I'm making too much out of nothing (or missing a far better solution/design altogether).</p>
  
  <p>Finally, I neglected (stupidly) to mention that we also compile against Mono for Android, and in the near future, WPF.  WinRT is a likely addition in the future but I'll be happy to cross that bridge when we come to it.  Generally though, since each is compiled in their own way with their own platform features, I don't mind <em>terribly</em> if different platforms have a different way of pulling in the assembly references; though it would be nice if there was a unified syntax between the platforms.</p>
  
  <p>EDITx3: Yeah, another one.  I mentioned, but didn't clarify with an example that not all projects need or should be read by the base framework.  For example, utility or business logic projects that have code that isn't relevant to the base framework but relevant to the client application.  So from the above example:</p>
  
  <pre><code>Solution
      -&gt;MyAppBootstrapper_Android
          -&gt;MyAppGUI_Android
          -&gt;MyAppFramework
          -&gt;MyAppResources
          -&gt;MyAppAdditionalResources_Android
          -&gt;MyCompanySharedUtilities
  
      -&gt;MyAppBootstrapper_Silverlight
          -&gt;MyAppGUI_Silverlight
          -&gt;MyAppFramework
          -&gt;MyAppResources
          -&gt;MyAppAdditionalResources_Silverlight
          -&gt;BaseFrameworkGraphingModule
          -&gt;MyCompanySharedUtilities
  </code></pre>
  
  <p><code>MyCompanySharedUtilities</code> could be leveraged by the MyAppGUI_Silverlight, and MyAppFramework but the developer might not run it through <code>FrameworkAssemblyReader.Read</code> because it only contains, say, proprietary implementations of some math, or business rules.</p>