Over the last few days I have been working on an open source version of the ASP.Net content management system that I started earlier this year.It’s not really the same CMS. The original one was designed to be used by an organization that could access the administrative pages through a separate back-end website that made use of Windows authentication and Dynamic Data. The reason for doing that was to get it up and running very quickly.

All that is gone, now. In this version everything will be managed through the front end. Dynamic Data is out. I haven’t entirely figured out what I want to replace it with, but I planned to start with an ‘Edit Page’ page that would let me do whatever I wanted to a particular page, either through ordinary form fields or using TinyMCE.

I did not get very far… First, I wanted to bring up a test page just to try out some of the ASP.Net component features that I haven’t used in a while, and to gain more experience with Entity Framework (EF). So I used an EntityDataSource to feed a ListView control. Hah! Doesn’t work. It broke somewhere along the line with EF 5 or EF 6. Microsoft is working on it. In the mean time it might work or it might not, depending on what version of EF (and Visual Studio) you are using, and how good your luck is. For me, in this application, it doesn’t work. I tried everything I could think of. The only thing that worked was switching to LinqToSql and the LinqDataSource. At least it lets me work with ListView and FormView in their various editing states (view, edit, insert, delete).

OK, so hours later I was finally able to make a data bound control work with a data source control, in spite of MS’s code being broken. What an accomplishment! Next, I wanted to be able have a kind of site map page where a website page owner could go to select any page for editing that that person was able to edit, even if it was unpublished. That’s pretty simple — just use a SiteMapDataSource and a TreeView control, right?

Yes but, well, no. What I got instead was infinite recursion and stack overflow. Hours later, I know why. When I wrote my core CMS components, I constructed the SiteMapNodes using Url values that represented the actual URLs and Key values that represented the routes as they would appear in the ASP.Net route map. Why not? Well, now I can tell you why not.

The format of a route is a little different from that of an URL. First of all, if the application is subordinate to another one in IIS then the URL contains the parent application name while the route does not. Second, if the route is for the home page then it is an empty string. What could be simpler?

It seems, however, that somewhere between the SiteMapDataSource and the TreeView controls, somebody got the bright idea that a null parent node is somehow equivalent to a root node having the empty string as its key. There is no way that a null pointer is equal to an empty string, let alone that the parent of the root node is the root node (the root node has NO parent), but tell that to Microsoft.

The fix? Simple. Use ANYTHING but an empty string as a key value. It doesn’t matter what you use as long as it is unique (SiteMapNode Url and Key values must be unique) and not too confusing. I changed the root node key from an empty string to “/”, since either value is unique with respect to all other possible nodes. Now it works.

My brain is pretty well fried from all these hours of debugging MS’s code, but I will coming back to my CMS sometime soon, I hope. I would like to publish the source code as an example of a really simple ASP.Net CMS that leverages what is built in to the framework rather than reinventing the wheel and waxing very complex.

Some applications need that kind of complexity, but many probably don’t. I am rather surprised at some of the complex (and sometimes just plain wrong) solutions I came across while researching how to write my code. There were no doubt historical reasons for some of that, but since .Net Framework 4.0 came along the main reason for it seems to be nothing more than not being able to find the right information.

Once I have the new CMS host working, I hope to produce a new open source version of code I developed some years ago that turns a Reporting Services report into what amounts to an OLAP browser. The original code used MDX queries, but the new code will use SQL and will work well with data that has been optimized for use with PowerPivot.

At least that’s the plan.