我正在考虑通过提供一些预定义的接口来增加现有应用程序的可扩展性，这些接口可以通过放置在特定位置并由应用程序接收的“插件”来实现。当插件更频繁地更新和部署时，应用程序的核心很少更新。
因此，基本上，具有这样的设置：
// in core assembly (core.dll)
public interface IReportProvider{
string GenerateReport();
}
// in other assembly(plugin.dll)
public class AwesomeReport : IReportProvider {
string GenerateReport(){ ... }
}
这两个项目都是同一构建过程的一部分，并且核心应用程序被单独部署，并且在以后的阶段将其插入。
我的问题是程序集的版本控制和随着时间的推移而解决。假设已经部署了core.dll v1，我想插入一个插件。如果plugin.dll引用core.dll v1，则此方法效果很好。但是，如果plugin.dll是针对core.dll的更高版本（作为构建的一部分，例如v2）编译的，则该插件将无法加载，因为它引用了core.dll v2，但是部署的版本仅包含core.dll v1。
这是合理且预期的行为，但它给我带来了该项目设置方式的两个痛点，即不能仅通过再次运行构建并放入新插件来完成对插件的开发/更新。新版本的依赖项）。
（我知道将较新的程序集解析为较旧的程序集的潜在问题以及类型定义中的潜在不匹配。问题仅在于解决高级程序集解析问题，而不在于解决与类型不匹配的类型定义有关的问题。）
我看到了使事情正常运行的几种选择，这些选择都不是我真正想要的那么简单：
将绑定重定向添加到web.config，指示所有core.dll v1 +引用解析为core.dll v1引用
创建一个包含接口定义的“ contracts.dll”程序集，并在整个版本中保持此特定程序集的版本号不变
针对core.dll的已部署版本构建插件（以某种方式引用开发中的已部署版本）
如前所述，对我而言，这些都不是真正的低挂水果，我希望有人能够提供更高级的解决方案？
最佳答案
我在这个领域进行了相当广泛的工作，并且一直发现您需要确定范围内和范围外的界限。想要最大程度的扩展是有风险的，但是这一切都是有代价的。该费用要么是约定时，最佳实践的形式，要么是编译时的费用，或者可能是自动构建检查的费用，否则将是一个复杂的运行时。
要解决您列出的选项：
绑定重定向只是实现解决方案的部分工具。它们将使您的程序可以“滑动” DLL的一个版本来代替另一个版本，但是，它不能神奇地解决方法更改时发生的问题。 MissingMethodException吗？
这里您可能还没有的东西就是依赖关系链。
您可以看到，当应用程序将依赖项“ A”视为版本1对象时，它在内部从较新版本中创建了一些内容，并将其传递回应用程序并转换为v1.0-导致异常。
这可能很难处理-只是风险之一。
在各个版本中保持合同装配版本相同
这可以优雅地工作，但是，这只是将复杂性从构建时间推迟到了运行时。
您将需要努力确保所做的更改不会破坏各个版本之间的兼容性。更不用说随着应用程序的老化，您将在这些合同中收集许多您想弃用的声明。最终，该文件将变得庞大，笨拙，并给开发人员造成混乱-甚至还不能解决您拥有的所有实体合同！
我不太确定您的意思是什么，以及它如何覆盖您的问题空间。
您可以采用的另一种方法是为“ SDK”的每个主要版本创建一个新合同。这具有一些政治上的优势，因为它可以在一段时间内修复主要功能，这意味着我们可以将功能请求保持在合理的期望水平，并且超出此范围的任何内容（需要新一代合同）都推迟到下一个主要版本发布'。
但是，这确实需要对功能的设计进行认真的努力-事先考虑周全地编写合同，以便您可以抢占最明显的要求-但是，我真的觉得这无庸置疑……它们被称为“合同”因为某种原因。
每个新合同都将存在于版本名称空间中（Company.Product.Contracts.v1_0，Company.Product.Contracts.v1_1）。
我不会链接我的合同（每个新版本的合同都继承了最后一个）。这样做会使您回到保持版本号相同的问题，如果不完全打破束缚，就永远无法完全摆脱功能。
插件加载后，它可以询问主机支持的功能级别（合同版本）-以及是否是较旧的主机/较新的插件方案：或者，对插件进行编程以减少其运行时功能，以处理较少的主机功能，或只是拒绝加载。
您可能仍然应该执行这些检查，因为没有任何魔术可以使您的插件利用主机中根本不存在的功能！微软的MAF框架试图通过使用填充程序基础结构来实现这一目标，但是对于大多数人来说，这导致了大量的复杂性。
因此，您需要考虑的一些事情是：
满足您的可扩展性要求！您想要完成的所有事情都会使您付出持续维护的费用。
考虑一下您将如何弃用功能
别忘了您的合同将包含实体以及逻辑合同，它们与逻辑合同的注意事项略有不同，因为它们经常被传递得多。
仔细考虑是否在编译时而不是运行时更好地执行每个兼容性检查（反之亦然）
版本编号！程序集版本号非常适合运行时行为，文件版本号可帮助您将DLL跟踪回版本控制中的源代码-充分利用它们！
如果要执行自定义DLL解析，请使用app.config定义您的自定义DLL位置，而不是程序集解析事件。配置方法更容易预测，嘿，它是在易于阅读的Xml中声明的！ Fusion Log Viewer还将很好地报告您的DLL在探测链中的插入位置，而Assembly-resolve事件将在代码中隐藏所有逻辑和规则。
唯一真正的缺点是，使用app.config意味着更改将在您的应用程序重新读取配置文件（通常是应用程序重新启动）后才会生效，但是如果您对插件进行AppDomain隔离，您甚至可以解决此问题。
与您的“ core.dll”问题有关...
我认为，对于您来说，这是一个相对简单的问题。您的Core Contract DLL中的所有内容都应存在于版本名称空间下（请参见上文，Company.Product.v1_0等），因此DLL也包含版本号实际上是有意义的。这将消除将DLL部署到bin文件夹时相互覆盖的问题。
不要依赖GAC-从长远来看，这将是一个痛苦。令人遗憾的是，开发人员似乎总是忘记了GAC会覆盖所有内容，这可能成为调试的噩梦-还会在权限方面影响您的部署方案。
如果确实需要使DLL名称保持相同-可以在应用程序中创建一个“本地gac”，这将使您能够以不相互覆盖但彼此仍然可以解析的方式存储DLL。运行时。在app.config（see my answer here）中检出“绑定重定向”。可以将其与应用程序bin文件夹下的“伪GAC文件夹结构”结合使用。然后，您的应用将能够找到所需的任何版本的DLL，而无需任何自定义程序集解析代码逻辑。
我将在您的应用程序中部署core.dll的所有以前支持的版本。
如果您的应用程序的版本为9，并且您决定也支持插件的版本7和8，则只需包含Core.7.dll，Core.8.dll和Core.9.dll。您的插件加载逻辑应检测对较早版本的Core的依赖性，并警告用户该插件不兼容。
这个话题有很多，如果我想到与您的原因有关的任何其他信息，我会回头...
关于c# - 加载程序集和版本控制，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12177639/