我正在开发 DotNetNuke 模块，自然希望在安装或分发它们之前对其进行编译。过去，我只是通过浏览到本地 DotNetNuke 安装的/BIN 文件夹来引用特定版本的 DotNetNuke.dll。
这个引用允许我使用 DNN 基类并在这些基础上创建我自己的一组类。我还在我需要的整个 DNN 命名空间/类中使用了各种辅助方法。 (即从它们的 PortalModuleBase、ModuleSettingsBase 创建派生类，并使用它们的本地化类来替换 Microsoft 的 ASP.NET 实现提供的那些。)
我已经能够摆脱这种直接引用 DLL 的方法(复制本地 = True，特定版本 = False)，因为直到现在我一直将这些模块安装到我维护的客户端网站上。因此，我至少将它们保留在我一直在开发的 DotNetNuke 版本或更新版本上。最近，我在开发中引用了 6.1.3.108。
注意:这会自动将以下关联的 DLL 复制到我的模块的/BIN 目录中:
将它安装到较新版本的 DotNetNuke 站点上运行良好，这不是一个糟糕的开始。
我一直想知道的是，是否有一种非骇客的方式可以使我的模块对 DLL 的次要、构建或修订级别不敏感？
我意识到我有责任确保产品(如果在“中档”版本上开发)仍然可以在稍早版本和较新版本的产品上运行。也就是说，我觉得我可以对这些构建进行彻底的测试。对我来说，这优先于必须在开发中运行 OLDEST 主要构建。
换句话说，我宁愿不使用对 6.0.0.0 的引用进行开发，这样它就可以在 6.x.x.x 上运行而无需额外的努力。如果有人没有让我引用的绝妙方法，我只会这样做，比如 6.1.3.108 工作在稍早或更高的版本上。 (当然，我可以为主要版本更改制作不同的模块，例如 5.x.x.x 或 7.x.x.x。)
提前致谢!
最佳答案
不要引用 bin 文件夹中的程序集，而是将 DotNetNuke.dll(和任何其他引用)的副本与您的源代码一起保存，并在那里引用它。将支持的最旧版本放在那里，但在较新的站点上开发。在引用上设置 Copy Local=False，这样您就不会覆盖较新的版本，您应该没问题。
通过这种方式，我们能够在开发在 DNN 6.1.x 上运行的模块时引用 DNN 4.5.3。多年来，我一直在使用这种方法，没有出现任何重大问题(除非我偶尔忘记关闭 Copy Local 并且我的 DNN 站点神秘地炸毁了)。
关于assemblies - 我希望我的 DotNetNuke 模块在尽可能多的版本下工作，同时避免程序集绑定(bind)重定向，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10155417/