我正在开发 DotNetNuke 模块,自然希望在安装或分发它们之前对其进行编译。过去,我只是通过浏览到本地 DotNetNuke 安装的 /BIN 文件夹来引用特定版本的 DotNetNuke.dll。
这个参考允许我使用 DNN 基类并在这些基础上创建我自己的一组类。我还在我需要的整个 DNN 命名空间/类中使用了各种辅助方法。(即从它们的 PortalModuleBase、ModuleSettingsBase 创建派生类,并使用它们的本地化类来替换 Microsoft 的 ASP.NET 实现提供的那些。)
我已经能够摆脱这种直接引用 DLL 的方法(复制本地 = True,特定版本 = 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
将它安装到较新版本的 DotNetNuke 站点上运行良好,这不是一个糟糕的开始。
我一直想知道的是,是否有一种非骇客的方式可以使我的模块对 DLL 的次要、构建或修订级别不敏感?
我意识到我有责任确保产品(如果在“中档”版本上开发)仍然可以在稍早版本和较新版本的产品上运行。也就是说,我觉得我可以对这些构建进行彻底的测试。对我来说,这优先于必须在开发中运行 OLDEST 主要构建。
换句话说,我宁愿不使用对 6.0.0.0 的引用进行开发,这样它就可以在 6.xxx 上运行而无需额外的努力。如果有人没有让我参考的绝妙方法,我只会这样做,比如 6.1.3.108 工作在稍早或更高的版本上。(当然,我可以为主要版本更改制作不同的模块,例如 5.xxx 或 7.xxx)
提前致谢!