In the past 6 months, I have been working on a large number of migrations from older versions of DNN to newer. This blog post is going to be the first post in a series of posts around various activities that site administrators can do that will make future site administration easier. Over time websites will have modules installed, modules removed, upgrades performed and other activities that can often leave lasting marks that only add confusion to things in the future. Let's look at one area that can/should be cleaned on a regular basis and that is your web.config.
The following sub-sections will outline some of the things to look for in a web.config to ensure that it is as clean as possible. These steps only need to be completed after initial installation or after a major upgrade or module install/upgrade. Staying on top of this information will aid in support and other operations.
Before I get into the specifics of things that can be cleaned up in the web.config it is necessary to make a few notes regarding the risks of such operations. The web.config is an integral part of your website, if it has improperly formed information or if a critical section is removed your website WILL stop working. As such before making any manual changes to the configuration files be sure to take a backup copy in case something is done incorrectly.
Additionally changing the web.config will result in the application pool restarting which will cause temporary slowness for your users and can cause sessions to be ended unexpectedly. As such, changes should not be completed during the middle of the day.
Removing Commented Sections
Configuration files often contain a few comments here and there. Comments are stared with the character combination "<!--" (Without quotes) and are ended with "-->". These commented sections when viewing the configuration file inside of Visual Studio are easy to spot as the text appears green, however, in other editors, it can be often confusing. There are a few key areas of commented code that can be removed and will result in a more clean configuration file.
Of all recommendations, these items are the most simple items to cleanup.
Extra Connection Strings
By default, DNN has two different connection strings that are commented out, one in the <connectionStrings> section and one in the <appSettings> section. These are here for "reference" purposes, however when working with hosting companies and others that are unfamiliar with DNN it only adds to the confusion when supporting the application.
Removing these commented out connections help keep the file clean and easy to read and quick to identify the proper connection information.
Commented out AssemblyBinding & Other Nodes
As DNN upgrades occur there are assembly binding blocks of code that are commented out and/or updated by DNN. Often with a tag of "Updated by DNN" with a date/time of the update. Once your upgrade is completed, and you know that everything is ok there is no need to keep these confusing blocks in your web.config.
In one example I managed to find over 150 lines of a web.config that could be removed. Again, removing clutter helps later.
Often times a third-party module will add new settings in the <appSettings> location within your web.config. This was more commonly true in the DNN 4.x and 5.x days and often times this information becomes stale. After an upgrade, it might be good to quickly review information in this area to see if there is anything that looks incorrect. For example, an old Amazon S3 Key would be a good indicator that the setting is not used anymore.
NOTE: This is a RISKY cleanup and should be done with caution. However, it is an important aspect of knowing your site and the pieces and parts that are contained within.
Check for Partially Removed Modules
After uninstalling a module with advanced features if you selected "Delete Files" it should be removed fully, however, there are times and places where not everything is removed. One common best practice is to simply open up the web.config and search for any reference to the module in question.
Some modules will add <httpModule> or <httpHandler> elements or other to the web.config. You will want to make sure to remove any and all of these items. Once removed, you can then check for items in the /bin folder that were not removed as well.
Although small in nature, keeping up on your web.config can make life easier for those of us that come in at a later date and try to make heads or tails of things. A clean web.config can also help hosting providers and others find the important information when diagnosing an issue etc.
NOTE: None of these items will typically result in any performance gain. These steps are simply recommended to ensure that you have a clean site!