OK, maybe everyone else is just smarter than I am. Maybe not. For those that are in the ‘not’ category, here are some notes on setting up DNN with MS SQL Express on XP:

First of all, if your system did not have DotNet 2.0 on it before you loaded IIS – BUZZZ! – Thanks for playing! You have to uninstall DotNet 2.0 then re-install before things are going to work right. Sorry, but you know the MS shuffle…

Once you get that hair pulling out of the way, you can go to phase two of pain management: getting the darn dB to work right. I am still working on the details of this, but (and this is just my opinion) as far as I can see the evil geniuses at MS figured a way to mess up dB rights and privileges to allow their evil minions (DotNet and IIS/ASP) to access things that man should not see without old fashioned permissions. What I mean is this: you can download and run DNN once you set up your virtual dir in IIS with no alterations to your dB engine, and without editing the web.config file. This is just evil. It should never work in a sane world, but hey this is MS XP and IIS so why think ‘sane’?

If you were to do this evil thing and run the site installer, you might actually get what I did – a fully functional DNN site that does not show up in the management console of the dB, but just works. Of course some people think this is nice and convenient, but we all know better – it is evil and subverts dB management.

Further, if you did just run it and got a working DNN site, then attached your dB to the management console, it would break. Honest I know – I spent a few hours proving that I could never get the darn dB reversed into the console this way. Perhaps others can, but hey – why do it this way – it is evil remember?

What I suggest is that you either do what I did and give up and set your access to SQL mode (what I consider a non-evil way to get to a dB) then pick an all powerful user like ‘sa” and alter the connection settings in the web.config file. Of course what you should do is make a less powerful user and have them admin the DNN site, but I have to confess to being lazy and using ‘sa’. To get this to work you would do something like this to the connection section of the web.config file:

<!-- Connection String for SQL Server 2005 Express -->

    <add name="SiteSqlServer" connectionString="Server=YourServernameGoesHere\SQLEXPRESS;Database=DotNetNuke;uid=sa;pwd=yoursapasswordhere;AttachDBFilename=|DataDirectory|Database.mdf;" providerName="System.Data.SqlClient" />

Now my big pain with this is that it is just plain hard to read XML. No human should have to. What we should have is a nice interactive web page that asks us to enter our values for the needed name value pairs and then test them to be sure they work, and once they work, builds this file for us. Fat chance…You are on your own in the wonderful world of XML config madness friend…Get used to it. Invest in bi-focal lenses, you will need them soon enough. Actually, invest in a color coded editor so you can see what you are doing, and put in your connection details then run the install page (just access the site and it will install the first time).

The advantage here is that your dB will show up in the SQL Express management console this way, and you will see the tables you are going to need to edit later when stuff messes up. Also backups work and all that goodness.

Perhaps there are other ways. Of course if you are using something besides SQL Express you have to change other code to get all this to work. If you are already using SQL (the real one) I bet you don’t do Windows authentication (who would?) and you will never have this mad problems I ran into using the defaults people said to try.

Anyway, this will get you installed and running with dB management, and I have yet to see it work with the instructions given on most web sites – sure DNN will run, but SQL Express will never see it. There may also be ways to make Windows access work, but I honestly can’t see why I would ever want such a thing getting to my dB – I want to control my accounts at a lot finer grain than that where a dB is concerned – hence the fact that I suggest creating some user besides sa to use for the real install.

Bottom line: This is nice CMS code, and does a lot. It has cool DotNet features, but a way under-documented support structure. It also defaults to some spooky ‘just works but not really’ install parameters that leave you with a working CMS you can’t manage. There needs to be a more hand holding install that makes access permissions and dB configs interactive and clear – the same way most non-MS CMS systems do it. Access through the account you logged in on is just evil and should not work as a matter of principle, since no one who logs onto a system should have admin (or root) as a matter of course. Sure, this is not yet the norm in MS-land, but it is coming, and DNN should get ready for a ‘derooted’ MS world.

ADDENDUM - After I vented this I thought about it. Honestly installing as the NT user is not so bad a thing - if you assume that the NT user is not an Administrator on the box. That would be the right thing to do if you were in a 'derooted' environment. A regular user would be authenticated by the OS/Domain sign on process, and have no special privledges on the box they install an app like DNN on. Of course that is not going to cut it in most cases, since the user has to do stuff to IIS and to the dir structure to allow all the goodness of DNN to work. Still - I have to admit that the regular user install is not such an evil idea. Thought I should come clean about that...

OK end of rant, but I do hope this could save someone the hours of pain I had. Now that I am past that crap, I am using the nice tool and building some custom skins (what I needed to do in the first place)…

Cecil