Within our organization, as software and web application developers, we house a variety of web applications within our parent DNN 3.x directory for providing a portfolio of our work. Because DNN 3 provides its own web.config with a variety of enhancements, these configurations are automatically inherited by the sub directories, and break the child apps due to missing or inconsistent libraries. In order to have Websites contained as Children (either subdirectories or virtual directories) within an existing instance of Dotnetnuke 3.x - a few modifications will be required for these application  configurations.

Because Dotnetnuke 3.0 utilizes specialized httpHandlers and httpModules for Url Rewriting, Exception Handling, and a number of other user interface behaviors, these referenced libraries are identified within the web.config. Any virtual directory that is appended as a child of this directory will therefore automatically inherit the httpHandlers and httpModules from its parent, attempting to locate those files in its own bin directory.

Since the web.config settings are inherited from the root directory, in our case the DotNetNuke installation, you will need to forcibly remove these references. Luckily, removing these references is a fairly simple task. All which is required is adding a <remove> tag to compliment each of the <add> tags found in DotNetNukes httpHandlers and httpModules configuration sections within the system.web configuration section of the web.config. If the web.config for this sub directory is missing one or both of these configurations, add the configuration section manually as follows:

    <httpHandlers>
           <remove verb="GET" path="FtbWebResource.axd"/>
           
    < / httpHandlers>

    <httpModules>
        <remove name="UrlRewrite"/>
        <remove name="Exception"/>
        <remove name="UsersOnline"/>
        <remove name="ProfilePrototype"/>
        <remove name="AnonymousIdentificationPrototype"/>
        <remove name="RoleManagerPrototype"/>
        <remove name="DNNMembership"/>
        <remove name="Personalization"/>
           
    < / httpModules>

Finally, and unfortunately, the web.config file for your virtual directory is processed after the httpModules and httpHandlers are executed. So - you will need to copy the files referenced by the aforementioned tags. In an ordinary Dotnetnuke 3.x install - these files are:

• DotNetNuke.HttpModules.DNNMembership.dll
• DotNetNuke.HttpModules.Exception.dll
• DotNetNuke.HttpModules.Personalization.dll
• DotNetNuke.HttpModules.UrlRewrite.dll
• DotNetNuke.HttpModules.UsersOnline.dll
• freetextbox.dll
• MemberRole.dll

In summary, it is possible to make Child Web Apps work appropriately within a parent DNN 3.x installation. While it is not entirely pretty, and sometimes adds a small amount of overhead - it can work!

Happy Nuking!

Does this mean that if this is implemented, there is one common database for mebers, roles, etc. for all child and virtual portals?

Hi Kevin,

I wanted to tell you that this particular article was a life saver.  I had written a web application last year to work as a child app within our DNN portal under DNN3.  I couldn't get it work until I found this article.......THX!!!!

I am still a relative noob to the world of DNN and web programming and our company has moved to DNN4.  When that occurred surprise, surprise the application is broke. I didn't think that it would be a big deal, but our client base really misses it.  I have attempted to apply the same logic outlined within the article, but alas I have been unsuccessful.  It's the same application, but DNN4 has changed a large portion of it's web.config since our pitiful 3.1 installation (Yes....we were that far behind). 

Is there any wisdom that you could offer to help me with this situation?

Thanks,
Ron