Continuing my quest to have a fully-integrated version of DasBlog with DotNetNuke, I have made some progress.

My original intent was to leave the DasBlog core untouched, but as I poked around, it became clear that this is not to be. I started by putting the DasBlog source in a folder structure that would allow seamless conversion of the DasBlog aspx pages to DNN controls. I created something like this:

/DotNetNuke/DesktopModules/Speerio_DasBlog/{main DasBlog web files}

/DotNetNuke/DesktopModules/Speerio_DasBlog/SiteConfig

/DotNetNuke/DesktopModules/Speerio_DasBlog/Themes

etc.

After several false starts in getting the IIS application mapping correctly, I had a DOH! moment. I moved the DasBlog web.config into /DotNetNuke and made /DotNetNuke into an application. That worked...almost...got a bunch of compiler errors, but at least I was making progress.

The source of the errors was that in several places in the code, DasBlog uses Server.MapPath("somefolder/somefile"). Of course, this doesn't work too well if it's not in the app root. Time to break out the trusty and hard-working Search and Replace and replace all such instances with "~/DesktopModules/Speerio_DasBlog/". Lift-off!? Nope...no such luck. Ran into an annoying VS.Net bug that prevents strong-named assemblies from working properly some of the time. Google says lots of people are having the same problem and the known solution is to not have strong-named assemblies (what kind of solution is that?) or build twice. The assembly in question is FTB and since I am not at the point where I can yank it out, I opted for the build twice.

After more of this, I now have DasBlog working using the revised folder structure. Next step, blow away the DasBlog security and have it look to the HttpContext instead.