If you have any familiarity with developing web applications in Microsoft Visual Studio 2005 you probably know about the Web.config file. This is where ASP.NET 2.0 gets all of its information regarding web-specific configurations such as the connection string to a database. In DotNetNuke, the file is named the same and serves mostly the same purpose with ability to add more parameters specific to DotNetNuke. It is a file written in Extensible Markup Language (XML) and can be edited with any text editor.
Basic configuration settings are stored in the web.config file to include encryption keys, provider information, and database connection strings. When you first install DotNetNuke, immediately make a copy of your release.config file that comes with it. This is so that you can always go back to the baseline installation if you have to. Rename the copied release.config file to web.config and this becomes your version 1 configuration file for DotNetNuke. This way when you upgrade DotNetNuke, the release.config will change with the new install but the original web.config will remain the same. You want this so that specific application setting will remain the same and not be lost.
A typical web.config file will have the following skeletal structure. A combination of you and the DotNetNuke CMS will be filling in the customized settings:
<configuration>
<configSections>
<!-- here is where sectionGroups will be defined -->
</configSections>
<system.web>
<!-- here is where the sectionGroups defined above will be implemeted -->
<httpModules>
<!-- here is where the httpModules are added -->
</httpModules>
</system.web>
</configuration>
Typically, not much needs to be changed in a new web.config file. Of course in the AppSettings node, you will need to change the SiteSqlServer connection string. If you are upgrading, you will need to maintain your orginal MachineValidationKey and MachineDecryptionKey settings. These settings are kept in the system.web section and can look something like this:
<add key="MachineValidationKey" value="12345678901234567890" />
<add key="MachineDecryptionKey" value="1234567890123456789012345678"/>
As mentioned earlier, the one setting you will more than likely change in a web.config file is the database connection string and the server parameters. This is where you would also specify the database password and database owner username. Are passwords stored unencrypted in the web.config file? Yes. But when the site is deployed, no one can access this file anyways.
Here is a typical connection string located within the connectionStrings tag of the web.config file:
<connectionStrings>
<!-- Connection String for SQL Server 2000/2005-->
<add
name="SiteSqlServer"
connectionString="Server=vista;Database=Demo;uid=someuser;pwd=somepwdr;"
providerName="System.Data.SqlClient" />
</connectionStrings>
The key SiteSqlServer must be described as well. So there is an additional key modified in the web.config file and appSettings tag to reflect the following:
<add key="SiteSqlServer" value="Server=vista;Database=Demo;uid=someuser;pwd=somepwd;"/>
The first question you are going to ask is what settings go in the web.config file. The answer is, “It depends.” It depends on what types of addins and customized modules you are using. Any of these would provide you with documentation as to the web.config parameters required.
Here is another setting that you can configure in the web.config file:
<httpRuntime useFullyQualifiedRedirectUrl="true" maxRequestLength="8192" requestLengthDiskThreshold="8192" />
This httpRuntime parameter defines how large of files you can upload into the DotNetNuke framework. Let’s say you have a custom language pack that interfaces with DotNetNuke and it exceeds the default of 4 MB (4096) in size. In this case, you would want to change the maxRequestLength to 8192 (8 MB) and the requestLengthDiskThreshold to 8192. Change the setting to handle the largest file you will upload.
System logging is a very important activity on any website. When things are not going right you need to be able to check the logs. System logging can be implemented to either a database or XML file. All versions of DotNetNuke 4.0 have the system logging provider located in the web.config file by default. The default system logging file can be found in this configuration setting:
<logging defaultProvider="DB_Logging_Provider">
The EventLog in a database provider contains the event types. In a XML file-based provider, the logs will be found in the default portal root directory. You can filter records to display as only the ones generated by your specific portal. What is an interesting feature is the list can be filtered by event type by the Portal Administrator and only the relevant messages can be emailed to a recipient.
And what would a web be without flexible role and member-ship based security. In Dotnetnuke, you can find these settings in the web.config file as well. Here is a sample of what a roleManager configuration might look like:
<roleManager cacheRolesInCookie="true" cookieName=".SQLROLES"
cookieTimeout="30" cookiePath="/" cookieRequireSSL="false"
cookieSlidingExpiration="true" createPersistentCookie="false"
cookieProtection="All">
<providers>
<add name="DNNSQLRoleProvider" type=
"DotNetNuke.Security.Membership.AspNetSqlRoleProvider,
DotNetNuke.Provider.AspNetProvider" connectionStringName=
"SiteSqlServer" applicationName="/" description="Store/retrieve role info
from local MS SQL Server DB" />
</providers>
</roleManager>
Even though you can edit a DotNetNuke web.config file with any text editor, make sure you know what you are doing before making the change. Many of these parameters are very cryptic and just one wrong setting can cause unexpected results. Remember that when you are editing the web.config file, you are actually altering Internet Information Services (IIS) settings. Always have some type of reference readily available and keep plenty of backups of your web.config file before making changes.