An Introduction to the DNN Folder Structure
Now that I have covered the DotNetNuke installation process, I would like to begin “dissecting” the application from a developer’s position to gain a better understanding of what is going on “under the hood.”
This week I’m taking a closer look at the folder structure, which presents itself after opening the DNN solution file in Visual Studio. This lays the foundation for my continued quest of “how to” develop with DotNetNuke.
Upon opening DNN in Visual Studio, the folder structure resembles an ASP.NET web site in its basic form. Digging deeper, I discovered some cool features that DNN has already “laid out” for us. After all, isn’t this the biggest perk of using DNN? I am working with Visual Studio 2005 and DNN 4.5.3 for this discussion. There will be slight variations depending on which version of DNN and Visual Studio you are using.
When you start an ASP.NET web site (in VS 2005: File | New | Web Site | ASP.NET Web Site) a basic files and folder structure is created: default.aspx and web.config files minimally. DNN adds a number of folders and files to this basic structure, which I will not be able to cover in its entirety as this is a much larger topic than my allotted space allows. The folders I’m discussing below have, for the most part, a specific bearing on DotNetNuke:
- Admin
- App_Code
- App_Data
- App_GlobalResources
- Bin
- Controls
- DesktopModules
- Portals
- Providers
1. Admin Folder
After a successful DNN install, you can browse your portal and it acts as a basic “shell” for your website. You can begin adding users, roles and pages without writing a stitch of code. Most of this administrative functionality lives in the admin folder and its corresponding database objects. These files and folders should be left untouched unless you truly understand what you are doing. However, it is a good place to start looking around to gain a better understanding of the DotNetNuke core.
2. App_Code Folder
The App_Code folder has a special status in the ASP.NET world as well as in DotNetNuke. Place common code such as the business logic layer (BLL) and the data access layer (DAL) for your DNN modules into this folder, with an individual sub-folder for each module. For example, for the “HelloWorld” module, I placed my DataProvider.vb, HelloWorldController.vb, HelloWorldInfo.vb and SqlDataProvider.vb files into this folder.
3. App_Data Folder
This folder contains the SQL Server Express database (.mdf file), which is used as the default data store in the web.config file.
4. App_GlobalResources Folder
This folder contains global resource files and other localization files in support of the DNN localization system. This is another folder that is typically not modified and its design is the reason why DNN cannot be pre-compiled.
5. Bin Folder
This folder contains compiled assemblies (.dll files) for modules, data providers, 3rd party components, ect. You will see quite a few existing assemblies by default and the number will only increase as you install modules.
6. Controls Folder
DotNetNuke comes with a set of web controls that have been written specifically for the DNN environment. They extend or abstract the functionality of existing ASP.NET components and allow module developers to access native DNN controls such as the text editor, label control, and URL Control. Each control is implemented as a standard .ascx file that can be referenced by custom modules. For details visit Jon Henning’s blog as he leads the development and documentation of DNN web controls.
7. DesktopModules Folder
DotNetNuke modules are built in 3 tiers: DAL, BLL and the Presentation Layer. I briefly noted above that the DAL and BLL files are in the App_Code folder. The Presentation Layer resides in DesktopModules. For each module you create or install, a sub-folder is created. Within that module sub-folder, the following files can be found for the HelloWorld module:
- local resources (.resx files)
- documentation
- SQL scripts (.SqlDataProvider files, typically inside a Providers folder)
- view/edit pages (.ascx files)
- settings.ascx (accessed from the “Settings” action menu item)
- module manifest file (.dnn file)
This sub-folder, along with the App_Code (BLL/DAL) folder, contains all the code necessary to run the HelloWorld module. Among other things, a module’s .dnn manifest file specifies the folder name for the module and you must be sure to provide a unique name for each of your modules.
8. Portals Folder
A single DotNetNuke installation can support multiple portals (websites.) The default portal configured during DNN installation occupies folder 0. This association is made based on the assigned “PortalID” value from the Portals database table. When you add additional parent or child portals, a new sub-folder is created under the Portals folder according to its PortalID (1, 2 ...) Visit DNN Creative Magazine for a nice illustration of this process.
9. Providers Folder
In this folder you will see a DataProviders\SqlDataProvider sub-folder, which contains xx.xx.xx.SqlDataProvider files. These files are the SQL scripts for each DNN version/upgrade. Notice that the last xx.xx.xx.SqlDataProvider file is 04.05.03.SqlDataProvider as we’re working with a DNN 4.5.3 install. Besides data providers, you’ll also find at least the html editor providers and logging providers in this folder. Think of providers as exchangeable components similar to modules only that providers act more “behind the scene” in support of modules. For instance, if you don’t like the default FCK text/html editor, you can easily replace it with the Telerik text/html editor. Just add a folder under /Providers/HtmlEditorProviders for the Telerik provider and modify the <providers> selection in the web.config to point to the provider.
I hope that this blog post helps aspiring DNN developers to take the next steps on their path down DotNetNuke lane. As always, feedback and comments are most appreciated.
Comments are closed