I wasn't that lucky when I tried to install DotNetNuke for the first time. After reading this forum I believe many had the same frustation like mine. I did figure out where the problem was and I like to share it with everybody. In my case I consider it was silly.

I'm using Windows XP Pro SP2 with 256 MB of memory on Transmeta Crusoe 800 MHz. The database is SQl Server 2000. I'm installing DotNetNuke 4.0.2 using 'install' package.

The following are three error messages I had one after the other:

1. Could not find file "...\Providers\DataProviders\SqlDataProvider\DotNetNuke_template.mdf"
2. Could not find file "...\SiteUrls.config"
3. Object reference not set...

Those error messages could be misleading but the source of the problem is somewhere 'near' the connection string setting in web.config.

I was using notepad to alter web.config file. I overlooked the comment end markers '-->' on two places. By default web.config commented out connection string for SQL Server 2000 but NOT SQL Server 2005 Express. At first I thought both are NOT commented (See the original part one and two below). So I commented SQL Server 2005 Express. I FORGOT line 12 on part one and line 6 on part two. Only after few trials, internet searches and reading the forum I come back to the web.config and read it thoroughly. I saw the sillyness and solved the installation problem. The comment end markers '-->' were not appropriatedly placed or removed.

Original part one

1  <connectionStrings>
2    <!-- Connection String for SQL Server 2005 Express -->
3    <add
4      name="SiteSqlServer"
5      connectionString="Data Source=.\SQLExpress;Integrated Security=True;User Instance=True;AttachDBFilename=|DataDirectory|Database.mdf;"
6      providerName="System.Data.SqlClient" />
7    <!-- Connection String for SQL Server 2000/2005
8    <add
9      name="SiteSqlServer"
10      connectionString="Server=(local);Database=DotNetNuke;uid=;pwd=;"
11      providerName="System.Data.SqlClient" />
12   -->
13  </connectionStrings>

Altered part one

1  <connectionStrings>
2    <!-- Connection String for SQL Server 2005 Express
3    <add
4      name="SiteSqlServer"
5      connectionString="Data Source=.\SQLExpress;Integrated Security=True;User Instance=True;AttachDBFilename=|DataDirectory|Database.mdf;"
6      providerName="System.Data.SqlClient" />
7     -->
8    <!-- Connection String for SQL Server 2000/2005 -->
9    <add
10      name="SiteSqlServer"
11      connectionString="Server=(local);Database=DotNetNuke;uid=DotNetNukeUser;pwd=dnnadmin;"
12      providerName="System.Data.SqlClient" />
13  </connectionStrings>

Original part two

1  <appSettings>
2    <!-- Connection String for SQL Server 2005 Express - kept for backwards compatability - legacy modules   -->
3    <add key="SiteSqlServer" value="Data Source=.\SQLExpress;Integrated Security=True;User Instance=True;AttachDBFilename=|DataDirectory|Database.mdf;"/>
4    <!-- Connection String for SQL Server 2000/2005 - kept for backwards compatability - legacy modules
5    <add key="SiteSqlServer" value="Server=(local);Database=DotNetNuke;uid=;pwd=;"/>
6    -->

Altered part two

1  <appSettings>
2    <!-- Connection String for SQL Server 2005 Express - kept for backwards compatability - legacy modules 
3    <add key="SiteSqlServer" value="Data Source=.\SQLExpress;Integrated Security=True;User Instance=True;AttachDBFilename=|DataDirectory|Database.mdf;"/>
4    -->
5    <!-- Connection String for SQL Server 2000/2005 - kept for backwards compatability - legacy modules -->
6    <add key="SiteSqlServer" value="Server=(local);Database=DotNetNuke;uid=DotNetNukeUser;pwd=dnnadmin;"/>

John,

What is step 6 in your post above. I'm not a DBA guru so I don't know what the next step in your cookbook recipe is. If not web.config, then where would I copy and use this string I successfully created using a ".udl" file?

It seems like a great idea not have a password sitting in a file on the IIS server. I can really get behind that idea.

Thanks,

--Bill

JonAskew,

Microsoft does recommend using integrated security (Windows Authentication), but believe me when anyone gains access to that file, it's gonna be the least of your problems, since that means the intruder has already gained access to your machine and can do many things more and he doesn't really need your password to get access to the DB cause he can do it anyway with integrated security.