I just wrapped up my first DotNetNuke project. Well, I completed the initial development anyway. I'm sure we'll need to tweak the skin a little and the client may want some other adjustments... but the functionality is done.
I downloaded DNN for the first time Friday night around 10pm. And at roughly 11am this morning, 37 hours later, the project is complete. Now, to be fair, I worked 27.25 of those 37 hours. And I had done a few days' reading before I downloaded anything. But for start-to-finish in a weekend, I'm happy.
I am satisfied with the DotNetNuke framework too. I muddled my way through creating a couple custom modules and the site turned out better than I had imagined. The client's old site (that I created in 1999, yes, 1999) had a completely separate admin website. It looked like arse and it was cumbersome to navigate. The new site's administration is all built right into the DNN portal, and it's very intuitive and consistent.
Along the way, I had some strange issues. For a reason completely unrelated to DNN, my machine blue-screened last night. When it came back, I couldn't get the site to work anymore. I was getting an error that a DLL couldn't be loaded. As I deleted the DLLs out of the bin folder, it would just report that a different DLL couldn't be loaded. On a whim, I went and wiped out the Temporary ASP.NET directory, and that actually solved the issue.
Likewise, when I just deployed the site to the server in Release mode, I got a 'Server Unavailable' error. I wiped out the Temporary ASP.NET directory from the server, and the site now loads fine. So, something seems a bit fragile, but at least I know how to get past it.
A piece of advice that will help out a lot, is to log in as 'host' while you're developing your modules. You get the friendly errors even when logged in as 'admin.' But logged in as 'host,' you get the stack trace. I think I saw a host setting to turn the friendly errors off too. With only the friendly error, it can take awhile to figure out why your module is barfing. (Think Response.Write Debugging).
This project was a proof of concept for me. I wanted to see if I could use DNN to create sites for people that need to be able to edit their own content, while still allowing me to add custom functionality. I am calling it a success at the moment. We'll see if that changes when A) the client sees it and B) he tries to edit the site. I don't expect him to have any problems though.
The only place where I was a bit afraid of DNN was with the data access. For one of my custom modules, I actually use a different database, and I just use the SqlHelper directly rather than using the whole SqlDataProvider model. I cut corners here for 2 reasons:
- I wanted to keep the client's business data separate from the portal database. If something goes awry and the site blows up, I can always reconfigure DNN. But if something destroys his business data, we'd be in a bit more trouble.
- This site had been the same for 9 years. I imagine the new site will survive for quite a long time too, with little functionality change. So the flexibility the provider model offered me was more than I really needed.
I'm gonna call it a day and get some sleep. Kelly and the boys are on their way back from TN. Maybe I'll get enough sleep to be able to spend the evening with them.