我正在开发 DotNetNuke 模块，自然希望在安装或分发它们之前先编译它们。过去，我只是通过浏览到本地 DotNetNuke 安装的/BIN 文件夹来引用特定版本的 DotNetNuke.dll。
这个引用使我能够使用 DNN 基类并在这些基类上创建我自己的一组类。我还在我需要的整个 DNN 命名空间/类中使用了各种辅助方法。 (即，从它们的 PortalModuleBase、ModuleSettingsBase 生成派生类，并使用它们的 Localization 类替换 Microsoft 的 ASP.NET 实现提供的类。)
我已经能够摆脱这种直接 DLL 引用(Copy Local = True，特定版本 = False)的方法，因为直到现在我一直在将这些模块安装到我维护的客户端网站上。因此，我至少将它们保留在我一直在开发的 DotNetNuke 版本上 - 或更新版本。最近，我在开发中引用了 6.1.3.108。
注意:这会自动将以下关联的 DLL 复制到我的模块的/BIN 目录中:
将此安装到较新版本的 DotNetNuke 站点上运行良好，这不是一个糟糕的开始。
我一直想知道的是，是否有一种非黑客的方式使我的模块对 DLL 的次要、构建或修订级别不敏感？
我意识到我有责任确保产品(如果在“中档”版本上开发)仍然适用于稍早版本和较新版本的产品。也就是说，我觉得我可以对这些构建进行彻底的测试。对我来说，这优先于必须在开发中运行最旧的主要构建。
换句话说，我宁愿不引用 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/