DotNetNuke and custom development

Question

We are considering purchasing DotNetNuke (or Sitefinity) on pretty short notice and there are is a question I have that I am having trouble finding a quick answer to. (I have a separate but similar post with Sitefinity as the focus, if you can answer that better or in addition.)

We are currently not using any CMS at all and we have some custom development that will not go away just because we go with a CMS for some or most of our site.

Our custom development is c# ASPX with Site Master and nested Site Master pages. These custom apps do not own their own top level in our web site, but are part of a branch, typically one or two levels down (for example, http:www.contoso.com/branch/app/default.aspx).

• How is DotNetNuke typically configured in a CMS/Custom “mixed mode”? For example, is DotNetNuke installed at the “top” of the web site, or “where needed” down in the web site.
• How does this relate when mixing CMS and custom web applications?
• Does the CMS interface allow for adding these custom apps or do you just go to the web server and add them to the structure?
• It appears from reading other posts, we can create our own custom c# modules and have CMS editors “drop in” the modules on the pages. Can someone confirm that for me?

If I did not provide enough detail, please feel free to ask for more.

Answer 1

DNN is most commonly installed at the root of the website, but that is not required. It is sometimes run as an application in a virtual directory that is part of a larger site.

It is possible to add .aspx pages at the correct location within the DNN. The UrlRewrite handler will initially look at all such requests, and assuming that existing pages, and friendly url handlers don't think they "own" the .aspx page, DNN will stop processing the request and hand it to your page. There is no specific way to "register" these pages with DNN. I wouldn't generally recommend this approach, but it does work and can make sense in specific situations.

Alternately, you can write your own DNN modules. Existing code, can usually be quite easily be adapted by converting the code to work in .ascx user control that inherits from PortalModuleBase. Code that wants to take advantage of core DNN features e.g. membership or permissions will of course need to be modified to use the DNN APIs.

The DNN module approach is generally the best option. But the details of your situation may make one of the other approaches more appropriate for you. Basically as long as your site is layed out so that it is clear which requests are destined for DNN and which are not, you can mix and match with other asp.net code as needed.

Answer 2

One thing that causes trouble in a mixed configuration is configuration inheritance. If DNN is the root application, you'll either have to remove problematic http modules and handlers in the application's web.config or disable inheritance with a location setting in the DNN's (root) web.config:

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

Maintaining the inheritance between application's web.config and DNN web.config is fragile. Changes in DNN web.config can cause the application in the virtual directory to fail. In addition to removing each http module and handler, you'll need at least to add DNN's App_Code directories to the application configuration.

On the other hand, location setting does not always play well with DNN modules, especially if they have aspx pages in addition to controls inheriting from PortalModuleBase. Personally, I've never got the location setting work well enough with DNN.

See also

How to disable web.config Inheritance for Child Applications in Subfolders in ASP.NET?

How do I stop web.config inheritance

Avoid web.config inheritance in child web application using inheritInChildApplications