I thought about writing this blog entry while doing a technical review of a book on DotNetNuke 5.x. The soon-to-be-published book (by Packt Publishing) says this about DotNetNuke portals:
Parent portals are sites that are defined by a unique URL (www.CoffeeConnections.net, www.e-coffeehouse.com, etc.). Parent portals allow you to run multiple sites from the same host and same DotNetNuke installation. This means that each domain name is unique but points to the same location . DotNetNuke handles how to route the requests depending on which domain name is entered.
Child portals, on the other hand, are sub-portals related to your main portal and share the domain name of their parent. A directory is created on your web server allowing the portal to be accessed through a URL address that includes a parent name and the directory name combined
(say www.CoffeeConnections.net/TestingPortal ).
Although completely correct, I would like to relate the concept of DotNetNuke Parent & Child Portals to ASP.NET in particular & .NET at large.
Now, remember creating a Parent Portal requires you to create an appropriate Virtual Directory/Web Site/Web Application (depending upon your IIS version, and what you are trying to achieve) in your web server. And any of these identifies your site as an independent application to the web server. And the web server would load that site’s code into its independent App Domain (even if they are running in the same App Pool in IIS 7).
Thus, each Parent portal is loaded into its independent app domain by the web server. So each Parent Portal would have its code and assemblies loaded independently from other parent portals into its own App Domain. This is true, even while considering the fact that you would have configured your Parent Portal domains to point to the same physical path on the disk.
This is even more important even if your Hosting Provider has imposed memory limits on your Hosting Account, meaning that the DotNetNuke codebase would be loaded once per Parent Portal into the memory, and your Hosting Provider would count the memory use as, the sum of memory consumed by each Parent Portal.
Now, coming onto Child Portals, they are a pure DNN concept, and do not require any configuration on the web server. They are completely managed by DNN, and the web server would not even know of their existence. Thus say for example, paths like:
http://example.com/Page/Default.aspx
http://example.com/ChildPortal/Default.aspx
where the first path is a Page on Parent Portal, and the second is on the Child Portal appear exactly similar to the web-server.
Thus, in terms of App Domains, the Main Portal and child Portals are running under the same app domain.
The above distinction is important considering the facts like the Parent & Child Portals would have their caches etc. being maintained in the same app domain, whereas for 2 different Parent Portals, they would be in different app domains.
You might be interested in these 2 wonderfulr blog entries to know more about IIS App Pools, and .Net App Domains:
http://it.toolbox.com/blogs/programming-life/enter-the-net-appdomain-5595
http://odetocode.com/articles/305.aspx
Still have nagging questions in mind, feel free to use the comment form below.
Recent Comments