DotNetNuke与定制开发

Question

我们正在考虑在相当短的时间内购买DotNetNuke (或Sitefinity)，我有一个问题，我很难找到一个快速的答案。(我有一个单独的，但类似的帖子，与Sitefinity作为重点，如果你可以更好地回答或补充。)

我们目前没有使用任何CMS在所有的，我们有一些定制的开发，不会消失仅仅因为我们去一个CMS的一部分或我们的网站大部分。

我们的自定义开发是带有站点母版和嵌套站点母版页的c# ASPX。这些自定义应用程序在我们的网站中不拥有自己的顶级应用程序，但它们是分支的一部分，通常是一个或两个级别(例如，http:www.contoso.com/branch/app/default.aspx). )。

• DotNetNuke通常是如何在CMS/自定义“混合模式”中配置的？例如，DotNetNuke是安装在网站的“顶部”，还是“在需要的地方”安装在网站中。
• 当CMS和自定义web应用程序混合时，这有什么关系呢？
• CMS界面是否允许添加这些自定义应用程序，还是只需转到web服务器并将它们添加到结构中？
• 从阅读其他文章中可以看出，我们可以创建自己的自定义c#模块，并让CMS编辑器“插入”页面上的模块。有人能帮我确认一下吗？

如果我没有提供足够的细节，请随时索取更多。

Answer 1

DNN最常见的安装在网站的根部，但这不是必需的。它有时作为一个应用程序运行在一个虚拟目录中，这个目录是一个更大的站点的一部分。

可以在DNN中的正确位置添加.aspx页面。UrlRewrite处理程序将首先查看所有此类请求，并假设现有页面和友好的url处理程序不认为它们“拥有”.aspx页面，那么DNN将停止处理请求并将其交给您的页面。没有特定的方式“注册”这些页面的DNN。我一般不会推荐这种方法，但它确实有效，在特定情况下也是有意义的。

或者，您也可以编写自己的DNN模块。现有代码，通常可以很容易地通过将代码转换为在继承自.ascx的PortalModuleBase用户控件中工作的代码。想要利用核心DNN特性(例如成员资格或权限)的代码当然需要修改以使用DNN。

DNN模块方法通常是最好的选择。但是，详细的情况可能会使另一种方法更适合你。基本上，只要您的站点被布局，以便明确哪些请求是指定给DNN的，哪些不是，您就可以根据需要与其他asp.net代码进行混合和匹配。

Answer 2

在混合配置中造成麻烦的一件事是配置继承。如果DNN是根应用程序，则必须删除应用程序的web.config中存在问题的http模块和处理程序，或者在DNN的(根)web.config中禁用位置设置的继承：

<location path="." inheritInChildApplications="false">
    <system.web>
    ...
    </system.web>
</location>

维护应用程序的web.config和DNN web.config之间的继承是脆弱的。DNN web.config中的更改会导致虚拟目录中的应用程序失败。除了删除每个http模块和处理程序之外，您至少还需要将DNN的App_Code目录添加到应用程序配置中。

另一方面，位置设置并不总是能很好地处理DNN模块，特别是当它们除了从PortalModuleBase继承控件之外还拥有aspx页面时。就我个人而言，我从来没有得到足够好的DNN的位置设置工作。

另请参阅

如何在web.config的子文件夹中禁用子应用程序的ASP.NET继承？ 如何停止web.config继承 使用web.config避免子web应用程序中的inheritInChildApplications继承