我希望我的DotNetNuke模块能够在尽可能多的版本下工作,同时避免程序集绑定重定向

Question

我正在开发DotNetNuke模块,并且在安装或分发它们之前自然希望它们被编译.在过去,我只是通过浏览到本地DotNetNuke安装的/ BIN文件夹来引用特定版本的DotNetNuke.dll.

这个引用允许我使用DNN基类并在那些基础上创建我自己的类.我还在我需要的DNN命名空间/类中使用各种辅助方法.(即从其PortalModuleBase,ModuleSettingsBase创建派生类,并使用其本地化类替换Microsoft的ASP.NET实现提供的类.)

我已经能够使用这种方法来制作直接的DLL引用(Copy Local = True,Specific Version = False),因为到目前为止我一直在将这些模块安装到我维护的客户端网站上.因此,我至少保留了他们开发的DotNetNuke版本 - 或更新版本.最近,我在开发中引用了6.1.3.108.

注意:这会自动将以下关联的DLL复制到我的模块的/ BIN目录中:

• DotNetNuke.dll
• DotNetNuke.Instrumentation.dll
• dotnetnuke.log4net.dll
• DotNetNuke.Services.Syndication.dll
• DotNetNuke.Web.Client.dll
• DotNetNuke.WebControls.dll
• DotNetNuke.WebUtility.dll

将它安装到NEWER版本的DotNetNuke网站上工作正常,这不是一个糟糕的开始.

我一直想知道的是,是否有一种非hackish方式使我的模块对DLL的次要,构建或修订级别不敏感？

我意识到这是我的责任,确保产品(如果在"中档"版本上开发)仍然可以在更早的版本和更新版本的产品上运行.也就是说,我觉得我可以对这些版本进行彻底的测试.对我来说,这是必须在开发中运行OLDEST主要版本的优先选择.

换句话说,我宁愿不开发6.0.0.0的引用,只是因为它可以在6.xxx上运行而不需要额外的努力.我只会这样做,如果有人没有一个很好的方式让我做引用说,6.1.3.108工作稍早或更晚的版本.(当然,我可以为主要版本更改制作不同的模块,例如5.xxx或7.xxx)

提前致谢!

Answer 1

不要引用bin文件夹中的程序集,而是将DotNetNuke.dll(和任何其他引用)的副本与源代码一起保存,并在那里引用它.将最旧的受支持版本放在那里,但在较新的站点上进行开发.在引用上设置Copy Local = False,这样就不会覆盖较新的版本,你应该没问题.

通过这种方式,我们可以在开发在DNN 6.1.x上运行的模块时引用DNN 4.5.3.我已经使用这种方法多年没有任何重大问题(除非我偶尔忘记关闭复制本地和我的DNN网站神秘爆炸).