Ok, it’s not really about getting dasBlog to work with MonoRail, but really remembering that web.config has a cascading effect on sub applications in IIS. I had two bugs today the first of which took a long time to find, but both related to the root web.config having entries that caused problems in the sub application (dasBlog in this case).

The first issue, for some reason I had the domain attribute in the forms authentication section set to / in the root web.config. Not sure why it was set like that, but apparently MonoRail overrides the domain value when setting cookies, while dasBlog doesn’t. This has the effect of not being able to log in to dasBlog, but not producing any errors, and in fact it says the login was a success. However, no cookie is issued. Removing the domain attribute fixed this problem.

The second issue was regarding httpModules, in this case MonoRail’s routing module. This caused problems by requiring Castle dll’s be copied to the blogs bin directory, but more importantly it caused the FreeTextBox control to break and the blogging.aspx page to break because in these cases the files didn’t exists on disk and so (I think) the routing engine kicked in, though not setup on this application and missing dependencies, it failed. The fix for this, also easy and strait forward, is to remove the routing module from the blog application. To do that, you can just add a remove tag to the httpModules config like:

  <remove name="routingEx"/></httpModules>

Both issues were simple enough, but not very obvious at the time.