If you're wondering what in the world a web.config file is, then wonder know more. . .in about 5 minutes, you'll know more than you do now and be well on your way to moving forward.
I'm guessing right now you're either installing your DotNetNuke website or trying to modify it and you've realized that you have to do some work on the web.config file. So, let's start with the basics...
By default, DotNetNuke comes with more than one "*.config" file and this can be confusing to some, especially those who have never worked with .config files. Your DNN website will need ONE config file (if you happen to know of a reason why you would use more than one .config file, you are not a beginner and the topic would be outside the scope of this article).
So, the file you will be using will be called “web.config”. Your default download of DotNetNuke will include three .config files:
- Development.config
- Release.config
- Web.config
You will not be using the development or release file, so just pretend like they are not even there or delete them, if you like. Or, if you don’t have a file called Development or Release, don’t worry. And even if you only have a Development or Release, but no Web, that’s cool, too. Simply rename any one of the .config files to "web.config".
If this is your initial install of DotNetNuke and you are connecting to any database other than a SqlExpress database located in the App_Data folder (i.e., a remote database) then you are going to have to open your web.config file and make some modifications.
Now, I want to cover all the bases here for you newbies, because the little stuff that's so easily overlooked can trip us up hard at times. To edit a .config file, all you need to edit is a notepad editor, or other program like Visual Studio or Visual Web Developer (a free download from Microsoft). Personally, I prefer using Visual Studio (or Visual Web Developer) to Notepad as I find the color coding to be very helpful for quickly identifying errors (such as when you are commenting and uncommenting lines). One little out of place character can bring your website to a dead halt, so be paying attention when your working on this file.
To install, you will need to modify, at minimum, the Connection String information. The connection string is the line of code that allows your DotNetNuke website to communicate with your SQL Server database. Without a proper connection, your website will not run. Period. It's like trying to make a phone call with no phone lines connecting the two phones together. It's just not gonna happen no matter how bad you want to talk.
Modifying <connectionStrings>
Inside the web.config file, locate the <ConnectionStrings> tag, as shown below.
<connectionStrings>
<!-- Connection String for SQL Server 2005 Express -->
<add
name="SiteSqlServer"
connectionString="Data Source=.\SQLExpress;Integrated Security=True;User Instance=True;AttachDBFilename=|DataDirectory|Database.mdf;"
providerName="System.Data.SqlClient" />
<!-- Connection String for SQL Server 2000/2005
<add
name="SiteSqlServer"
connectionString="Server=(local);Database=DotNetNuke;uid=;pwd=;"
providerName="System.Data.SqlClient" />
-->
</connectionStrings>
Figure 19: Locating the default connectionString information
In Figure 19, the default connectionString is for a SQL Express database. This is the connection string you would use if you were using a database that is located in the App_Data folder of your website files. This would be useful mainly for home installations as not many hosts allow you to use this type of database setup. This remainder of this article covers connecting to a remote SQL database. If you are using a SQL Express database within your DotNetNuke installation, it's your lucky day, because you don't have to modify anything!
Before you continue, you need to make sure that you have your connection information to your SQL Database. You will need to know the Server Name, the Database Name, the User Name and the Password. In Figure 19 above, you will notice via the color coding that some code is commented out. How do we know? Well, because green is reserved for comments. If you are working in a notepad file, you won’t have color coding, but you can tell it is a comment because it begins with <!-- and closes the comment tag with -- > . In the green code you are going to replace the Server , Database, uid or User ID (User Name), and pwd (Password) values with your own; then, delete the blue and red code so it looks like the example below:
<connectionStrings>
<!-- Connection String for SQL Server 2000/2005 on my GoDaddy.com hosted account -- >
<add name="SiteSqlServer"connectionString="Server=whsql-v06.prod.mesa1.secureserver.net;Database=DB_72973;uid=DNNapp;pwd=mypassword;"
providerName="System.Data.SqlClient" />
</connectionStrings>
Notice how the green commented section referring to the SqlExpress database is now gone. Terrific work...but, you're not quite through yet. Directly under the <connectionString> section, you will see the <appSettings> section.
Modifying <appSettings>
<appSettings>
<!-- Connection String for SQL Server 2005 Express - kept for backwards compatability - legacy modules -->
<addkey="SiteSqlServer"value="Data Source=.\SQLExpress;Integrated Security=True;User Instance=True;AttachDBFilename=|DataDirectory|Database.mdf;"/>
<!-- Connection String for SQL Server 2000/2005 - kept for backwards compatability - legacy modules
<add key="SiteSqlServer" value="Server=(local);Database=DotNetNuke;uid=;pwd=;"/>
-->
We are basically going to do the same thing adding our connection information, so that what we end up with is like this:
<appSettings>
<!-- Connection String for GoDaddy.com- kept for backwards compatability - legacy modules-->
<addkey="SiteSqlServer"value="Server=whsql-v06.prod.mesa1.secureserver.net;Database=DB_72973;uid=DNNapp;pwd=mypassword;"/>
The reason the connectionString information is found in both sections is to make DotNetNuke work with older systems. In ASP.NET 2.0, the syntax changed and added the <connectionString> section, but the DotNetNuke folks kept the <appSettings> to make sure things remained backwards compatible.
Now, that wasn't so bad was it?