仅通过publicKeyToken区分程序集

时间:2014-08-01 14:57:19

标签: versioning .net-assembly strongname extensibility assembly-resolution

请考虑以下情形:

  1. NuGet包中包含两个版本的程序集,一个用于.NET 3.5(在 lib / net35 中),另一个用于.NET 4.0(在 lib / net40 中) 。两者都命名为 SomeInterfaces.dll ,版本 1.0.0.0 ,但两个程序集的强名称具有不同的publicKeyToken值。
  2. 存在名为 CoolProgram.exe 的应用程序,并公开可扩展性功能(例如,通过MEF)
  3. 公司 A 开发扩展程序 AExtension.dll ,并引用 SomeInterfaces.dll 的.NET 3.5版本。
  4. 公司 B 开发扩展程序 BExtension.dll ,并引用 SomeInterfaces.dll 的.NET 4.0版本。
  5. 提供以下其中一项:
    1. 扩展程序 AExtension.dll BExtension.dll CoolProgram.exe 位于同一文件夹中,并且< strong> SomeInterfaces.dll 放在GAC中。
    2. 应用程序将安装扩展的路径添加到CLR绑定路径。例如, AExtension.dll SomeInterfaces.dll (.NET 3.5)可以放在 extensions / A 目录中, BExtension.dll SomeInterfaces.dll 可以放在 extensions / B 目录中;这两个目录都放在应用程序 CoolProgram.exe 的绑定路径中。
  6. 问题:

    1. 情况5.1:

      1. CoolProgram.exe 是否能够加载 AExtension.dll BExtension.dll 而不会出现任何问题,因为它们仅引用了两个程序集他们的publicKeyToken
      2. 有所不同
      3. 加载扩展程序的顺序是否有所不同?
      4. 如果 CoolProgram.exe 没有强名称,答案是否会更改,但 AExtension.dll BExtension.dll 都有强大的名字?
    2. 与问题1相同,但适用于情况5.2。

    3. 可选背景资料:

      如果两个程序集在运行时兼容;即它们暴露相同的公共API,只是它们的实现不同(例如,一个限制为.NET 3.5用于实现,一个在私有实现代码中使用.NET 4.0类型),那么用户将不会面临可扩展应用程序中的程序集绑定问题如果两个程序集具有完全相同的强名称。对于公共API在某些方面存在差异的情况,情况并非如此。

      公共API不同的一种解决方案是为每个版本的程序集使用单独的名称。这可能导致ANTLR 4 Runtime的以下情况:

      • Antlr4.Runtime.net20.dll
      • Antlr4.Runtime.net30.dll
      • Antlr4.Runtime.net35.dll
      • Antlr4.Runtime.net40.dll
      • Antlr4.Runtime.net45.dll
      • Antlr4.Runtime.portable_net40.dll
      • Antlr4.Runtime.portable_net45.dll
      • Antlr4.Runtime.netcore45.dll

      如果所有程序集都可以命名为 Antlr4.Runtime.dll ,则可以简化与项目关联的文档。在用户知道他们在多个供应商可能提供引用具有不同目标框架但具有相同版本的程序集的代码的环境中工作的情况下,可以采取步骤以确保他们的程序集可以在运行时定位。一个具体的例子是使用ANTLR进行语法突出显示的两个Visual Studio扩展,一个针对Visual Studio 2010+(使用.NET 4.0),另一个针对Visual Studio 2012+(使用.NET 4.5)。 [ProvideBindingPath]和/或[ProvideCodeBase]属性可用于提供情境5.2中描述的功能。

0 个答案:

没有答案