我正在开发DotNetNuke模块，自然希望在安装或分发它们之前编译它们。过去，我只是通过浏览到本地DotNetNuke安装的/BIN文件夹来引用特定版本的DotNetNuke.dll。
此参考允许我使用 DNN 基类并基于这些基类创建自己的类集。我还在我需要的 DNN 命名空间/类中使用各种帮助程序方法。（即从他们的PortalModuleBase，ModuleSettingsBase创建派生类，并使用他们的本地化类来替换Microsoft的 ASP.NET 实现提供的类。
我已经能够摆脱这种方法进行直接 DLL 引用（复制本地 = 真，特定版本 = 假），因为到目前为止我一直在将这些模块安装到我维护的客户端网站上。因此，我至少将它们保留在我一直在开发的DotNetNuke版本上 - 或更新的版本。最近，我在开发中引用了 6.1.3.108。
注意：这会自动将以下关联的 DLL 复制到我的模块的/BIN 目录中：
- 点网核.dll
- DotNetNuke.Instrumentation.dll
- dotnetnuke.log4net.dll
- DotNetNuke.Services.Syndication.dll
- DotNetNuke.Web.Client.dll
- DotNetNuke.WebControls.dll
- DotNetNuke.WebUtility.dll
将其安装到较新版本的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（以及任何其他引用）的副本以及源代码，并在那里引用它。 将最早的支持版本放在那里，但在较新的站点上进行开发。 在引用上设置"复制本地=False"，这样就不会覆盖较新的版本，应该没问题。
通过这种方式，我们能够在开发在 DNN 6.1.x 上运行的模块时引用 DNN 4.5.3。 我已经使用这种方法多年了，没有任何重大问题（除非我偶尔忘记关闭复制本地并且我的 DNN 站点神秘地爆炸了）。
关于确定您从 DNN 子类化的类中的 DNN 版本。
假设 YourClass 继承自 DNNClass，但因为您引用了属性的早期版本，因此"NewProp"不存在。 具体操作方法如下：
public class YourClass : DNNClass
{
public string NewPropSubstitute
{
get {
string newPropVal = "your default if earlier DNN";
System.Reflection.PropertyInfo pi = this.GetType().GetProperty("NewProp");
if (pi != null)
newPropVal = (string)pi.GetValue(this, null);
return newPropVal;
}
}
}
这是一个根据内存做出的猜测，所以它可能无法编译，但你明白了。 如果你愿意，你不一定必须获得 DNN 版本 - 只需尝试通过反射获取属性 - 如果它在那里，隐含地你得到了正确的版本。
当然，此方法假设如果 DNN 版本不支持 DNN 属性（或方法），则可以用值替换它。 但这完全取决于你想做什么。
如果您确实想查找 DNN 版本（版本安全且始终正确），您可以使用嵌入在我的版本安全 jQuery 包含代码中的代码，链接自此博客文章：在 DotNetNuke 5 和 6 中使用 jQuery