获取没有反射或已知类型的装配参考

Question

在我当前的框架设计中,我仔细阅读所有类型的特定程序集,并根据找到的类型进行工作.它搜索的程序集由应用程序引导程序/初始化程序确定.程序集是编译的,因此可以通过以下方式强引用它们:typeof(SomeTypeInTheAssembly).Assembly.这很好,因为引导程序代码具有对程序集中类型的强引用,并且没有任何关于完全限定名称作为内联字符串的笨拙,如果程序集限定名称发生更改,则需要手动保持最新.但我不喜欢在程序集中引用一些完全不相关的类型,并依赖于那种类型.(如果它移动到另一个程序集怎么办？如果我们弃用/删除类型怎么办？更改其命名空间？)在代码中,它看起来有点奇怪:

FrameworkAssemblyReader.Read(typeof(SomeAssemblyNamespace.SubNamespace.GraphingCalculator).Assembly);

现在在我的引导代码中,我有一个直接依赖(虽然是一个非常简单的依赖),GraphingCalculator它与自举阶段无关(并且作为GraphingCalculator,它当然与获取程序集引用无关).为了避免这种情况,在我打算以这种方式使用的每个程序集中,我在它们的根中添加了一个类:

namespace SomeAssemblyNamespace
{
    public static class AssemblyReference
    {
        public static System.Reflection.Assembly Get
        {
            get
            {
                return typeof(AssemblyReference).Assembly;
            }
        }
    }
}

这不是太糟糕,因为我的引导代码看起来像:

FrameworkAssemblyReader.Read(SomeAssembly.AssemblyReference.Get);

但是现在,我有大约十几个这样的程序集AssemblyReference复制/粘贴,我只希望它继续增长,因为应用程序是在框架的顶部构建的.所以我的问题是,是否有一种很好的方法可以避免AssemblyReference类重复并仍然以编程方式将程序集引用传递给基本框架,但是避免指向目标程序集中某些任意/不相关类型的模糊性？我的谷歌搜索似乎告诉我,没有API或语言功能让我强烈指向一个程序集(比如typeof类),但我希望有人能提出一个比我更好的解决方案来避免类/代码复制.另外值得注意的是,代码有时是针对Silverlight编译的,所以我知道这可能会限制一些API /技术.谢谢!

编辑:只是添加另一个猴子扳手,根据"浣熊"的答案,我应该提到我并不总是加载相同的组件.例如,我可能有一个"CarBuilding"程序集,适用于某些应用程序但不适用于所有应用程序.这取决于bootstrappers告诉我他们希望使用哪些(以及开发人员正在使用的任何自定义的)

EDITx2:回答Jon Skeet的问题:客户(或我们内部)将创建他们希望支持其应用程序的任何项目/ DLL.反过来,这些项目将引用内部基础框架.他们的项目可能包含资源(3D文件,图像,文本,本地化等)和插件式类(它们实现我们在应用程序生命周期内根据需要发现和实例化/执行的脚本).此外,我们的系统提供可选模块(DLL),其中包含客户(或我们)在制作特定应用程序时可以利用的可重用插件/内容.所以你可能会看到一个项目结构,如:

Solution
    ->MyAppBootstrapper_Android
        ->MyAppGUI_Android
        ->MyAppFramework
        ->MyAppResources
        ->MyAppAdditionalResources_Android

    ->MyAppBootstrapper_Silverlight
        ->MyAppGUI_Silverlight
        ->MyAppFramework
        ->MyAppResources
        ->MyAppAdditionalResources_Silverlight
        ->BaseFrameworkGraphingModule

引导程序项目连接依赖项,并提供应该提供给基础框架以进行发现的项目/ dll(程序集).请注意,在这种情况下,"MyApp"在Android和Silverlight构建中共享其自己的迷你框架和共享资源,但两者都有彼此独立的引用.Silverlight利用了它,BaseFrameworkGraphingModule并且它们拥有自己特定于平台的资源.

所以在项目的bootstrappers看起来像(虽然简化):

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);
        }
    }
}

因此,对于构建在基础框架之上的每个应用程序,都会创建一个引导程序,指示要包含哪些程序集(以及其他一些不相关的布线工作).要具体回答这个问题,该项目对所需的每个程序集都有编译时引用(因为它确保所有DLL都打包在一起用于Android/Silverlight部署,因此它们不会动态下载到用户的智能手机或Silverlight应用程序)但在初始下载中打包.关于Bootstrappers如何知道要使用哪些程序集的问题,开发人员知道并FrameworkAssemblyReader.Read发出必要的调用.我希望这有帮助!感谢您花时间去看它.我有一种感觉,我从无到有做得太多(或完全错过了更好的解决方案/设计).

最后,我忽略了(愚蠢地)提到我们还针对Android编译Mono,并在不久的将来编译WPF.WinRT在未来很可能会增加,但是当我们来到它时,我会很乐意跨越这座桥梁.但是总的来说,由于各自以自己的方式用自己的平台特性编译,我不介意可怕的,如果不同的平台有集引用拉动的方式不同而已.虽然如果平台之间有统一的语法会很好.

EDITx3:是的,另一个.我提到过,但没有用一个例子说明并非所有项目都需要或应该由基础框架阅读.例如,具有与基本框架无关但与客户端应用程序相关的代码的实用程序或业务逻辑项目.所以从上面的例子:

Solution
    ->MyAppBootstrapper_Android
        ->MyAppGUI_Android
        ->MyAppFramework
        ->MyAppResources
        ->MyAppAdditionalResources_Android
        ->MyCompanySharedUtilities

    ->MyAppBootstrapper_Silverlight
        ->MyAppGUI_Silverlight
        ->MyAppFramework
        ->MyAppResources
        ->MyAppAdditionalResources_Silverlight
        ->BaseFrameworkGraphingModule
        ->MyCompanySharedUtilities

MyCompanySharedUtilities可以通过MyAppGUI_Silverlight和MyAppFramework来利用它,但开发人员可能无法通过它,FrameworkAssemblyReader.Read因为它只包含一些数学或业务规则的专有实现.

Answer 1

我不太确定您希望客户如何使用此代码，因此此建议可能无关紧要，但取消设置功能（至少对客户隐藏它）并使用不是更有意义吗？某种配置文件？

<ReferencedAssemblies>
    <ReferencedAssembly key="UnchangingKey" qualifiedName="SomeAssemblyName, version=1.0.0.0, Culture=neutral, PublicKeyToken=0123456789abcdef" />
</ReferencedAssemblies>

从配置文件加载程序集。使用密钥，如果完全限定名称发生更改，您不必更新应用程序，只需更新配置文件（并保持密钥不变）。

这基本上是 Visual Studio 对其项目文件使用的方法。下面是我的一个 VB 项目中的一个示例：

<ItemGroup>
  <Reference Include="System.Core">
    <RequiredTargetFramework>3.5</RequiredTargetFramework>
  </Reference>
  <Reference Include="System.Drawing" />
  <Reference Include="System.Windows.Forms" />
  <Reference Include="System.Xml.Linq">
    <RequiredTargetFramework>3.5</RequiredTargetFramework>
  </Reference>
  <Reference Include="System.Data.DataSetExtensions">
    <RequiredTargetFramework>3.5</RequiredTargetFramework>
  </Reference>
  <Reference Include="UIAutomationProvider">
    <RequiredTargetFramework>3.0</RequiredTargetFramework>
  </Reference>
  <Reference Include="WindowsBase">
    <RequiredTargetFramework>3.0</RequiredTargetFramework>
  </Reference>
  <Reference Include="PresentationCore">
    <RequiredTargetFramework>3.0</RequiredTargetFramework>
  </Reference>
  <Reference Include="PresentationFramework">
    <RequiredTargetFramework>3.0</RequiredTargetFramework>
  </Reference>
  <Reference Include="System" />
  <Reference Include="System.Data" />
  <Reference Include="System.Xml" />
</ItemGroup>

编辑：

这里有一个想法...如果您使用 Reflection.Emit 从 XML 配置文件生成程序集会怎样？您可以向生成的程序集添加一个存根类，您的核心项目可以使用它来创建对生成的程序集的硬引用，并且您可以使用反射来探测每个引用程序集（在 XML 文件中）以创建对任何对象的硬引用在引用的程序集中。当引用的程序集之一发生更改时，您需要重新生成程序集，但不需要更改代码。您甚至可以将程序集生成代码构建到核心项目中，以便用户能够根据需要更新其项目。