Here's the deal.  I have been looking for a blog engine that I could finally make my own.  I have explored many of the blogs out there and found that all of them lacked something.  I needed to have a variety of features.  I needed tagging, categories, MetablogAPI, additional pages, tracking, mulitple users, themes, and the ability to add additional modules if necessary.  I finally found BlogEngine.Net on CodePlex.  There are many reasons for the choice, one is that it meets all of my needs.  From a developers point of view it has a temendous potential.

I have been wanting to use DotNetNuke for the longest time since I host it and advocate it.  However, I could not use third party tools to blog.  Many blog applications do not allow you create additional pages, eg. dasBlog, but BlogEngine.Net does. 

I am going to be doing software tutorials that deal with CSLA.Net and the implementation of them.  The additional pages will allow for a psudeo article type functionality.  I may even find time to contribute to it.

I have been wanting to give back to the open source community that has given me many of the tools that I need to succeed in bussiness.  I cannot give to them all but I can give to some.

I look forward to publishing more now that I finally found a blog home. 

You have to bless all the people in the world who have contributed all of this time and energy into this fantastic project DNN.  I have installed over a hundred DNN sites and have gotten all kinds of errors.  Almost all of them were my fault.  But this latest one really kicked me in @#$.  I had to go to the DNN Forums to get the fix.  I had to add an appkey to the web.config:

<!-- I added this key to fix the redirect issue-->
<add key="UsePortNumber" value="True" />

Hope it helps.

This is an interesting challenge.  We are still in the process of namespacing and adapting our first DNN agenda items to our web services.  After reviewing much of the DNN code you find that there is little in the way of notifications.  You create the controller tell it to create the portal and you are done.  You do not get any error codes that the function succeed or failed.  The assumption is that it worked, otherwise an exception would be thrown.  In the Portal Controller class there are no Try..Catch blocks.  We are trying to develop a series of error codes to go along with the web services.  Since the applications using the web services do not have a state in the matter we need to let them know if they succeed or failed.  We will look at using Datasets and Begin/End Trans for the remote calls.