Mini Post – DotNetNuke and web.config problems

I could have Twittered this but I wanted to put it here: Every now and again I find myself refreshing my developer’s copy of my project on my local computer from source control.

The way I have source control is primitive and probably incorrect. I tend to save ALL of my project (DotNetNuke included) into source control, so when I get a clean setup, I can basically run it out of the box.

This particular time, I was working with a different database than I normally do. Because of this, my source control wrote over my web.config and copied the wrong database settings, which resulted in the web.config pointing to a no-longer existing database.

When I loaded up my website, I was greeted with the installation wizard from DotNetNuke. “Okay,” I thought, “Perhaps I forgot to update this particular database with the new DNN version.” I clicked on next a few times and realized it was just the wrong database being referenced. I changed the web.config to be the correct database and credentials and all was well…

Or was it?

I loaded up my project and I was getting rather unhelpful “I need to put a ScriptManager on the page in order to use AJAX.net” error. I just couldn’t figure it out! It worked before! Long story short, the DNN install wizard messed around with the web.config and broke a few things configured specifically to my install. Once I pulled up an older web.config, everything worked perfectly.

This wasted about 2 hours of my time (which I don’t really have) and was easily avoidable if I was paying attention.

Lesson learned: Always be methodical with processes which you perform regularly.  If something strange goes wrong within the process, it probably doesn’t belong and should be approached very, VERY carefully.

DotNetNuke Settings Issue: Truncated Data

DotNetNuke is great.  It has a great established core, along with a fairly straight forward process for developing extended modules.  You can use the already established DotNetNuke settings framework in order to facilitate settings for each instance of your own module.

We have a unique install in which we have central data that is shared by many custom modules.  I needed a way to have specific settings per portal, so I built a custom settings library.  I also wanted to be able to override these settings so I built in an XML parser to do so.

I found out the hard way that the settings table has an nvarchar size of 2000.  This almost never affected us, since the XML is generally smaller than 2000 characters, but I had one setting that went over.  It messed up my xml, and broke my module.

My immediate fix was to change the core database.  I made the settings to be nvarchar(MAX), and set up the add and update stored procedures to accomodate them.

I believe the best way to fix the issue without changing the core is to create another table, which either has a text type or a varchar(MAX) as the value.