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.x.x.x上运行而不需要额外的努力。我只会这样做，如果有人没有一个很好的方式让我做引用说，6.1.3.108工作稍早或更晚的版本。（当然，我可以为主要版本更改制作不同的模块，例如5.x.x.x或7.x.x.x.）

提前致谢！

Answer 1

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

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

Answer 2

关于确定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包含代码中嵌入的代码，该代码链接自此博客文章： Using jQuery in DotNetNuke 5 and 6

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

2 个答案: