Umbraco and Mono: Can it be done?

Recently, I've been dreaming about writing a next-generation .NET content management system (CMS). The CMS would incorporate a great feature set that my, as well as a ton of other organizations, would require out of a great CMS. After creating a project plan and set of documents, a friend of mine referred me to Umbraco, an open-source .NET content management system that claims to be as flexible as what I had imagined my CMS to be. My ambition for starting a brand-new project subsided since Umbraco incorporates a great number of the features I required. However, the main feature that my CMS had was platform independence. Umbraco, in its current state, is not ready. Neither is Mono. This article explains why.

• Research
• Environment
• First Test: Binary Distribution
• Second Test: Binary Distribution
• Third Test: Binary Distribution
• ThreadAbortException Issue
• Mono Page Parsing
• Inline ASP
• HTTP Debugging Proxy
• Conclusion
• See Also

Research

Environment

I took an older box (Intel P4 1700MHz, 1GB RAM, 30GB HDD) and loaded it with my favorite Linux distribution, Ubuntu 9.04 (Jaunty). After this, I installed all the compilation tools that are needed to build Mono and thusly grabbed Mono from Subversion. Since I know I've had some trouble in the past on how to build Mono on Ubuntu, here is a script that will get you a fully built mono development environment on your Ubuntu machine:

(Use gpaco to manage the installed-from-source packages)

Now at this point, I have a full Mono install from the trunk of the subversion repository. This ensures that I have the latest changes and bug fixes. This also makes it easier to contribute patches back to Mono when bugs are found. Also, don't forget to add a MySQL database and database user. I added two: one for Windows and one for Linux.

Another thing I ended up doing was setting up my Windows XP development box with the latest stable Umbraco source release (4.0.2.1). I extracted the source and built the solution in Visual Studio 2008. This will also be critical for making changes to the Umbraco project for the reasons found later in this article. Please review the Umbraco documentation for dependencies and how-to build.

First Test: Binary Distribution

• Now, the site loads with the installer! Apparently this already is farther than others have gotten.
• Clicked next a couple times through the installer, only to break a couple screens in with a yellow-screen-of-death (YSOD). A NullReferenceException (NRE) at System.Web.UI.Control.ApplyStyleSheetSkin.

This looks like an obvious Mono bug since it does appear to work on Windows.

• I opened mcs/class/System.Web/System.Web.UI/Control.cs and changed line 700 to:
  
  if (page != null && page.StyleSheetPageTheme != null) {

This resolved the problem. Bug filed with patch and unit test case as #521584.Curiously, it was fixed in SVN two days previously to posting the bug, patch, and unit test. Awesome!

• Recompiled and reinstalled Mono.

Now at this point I am at the database configuration page. I selected MySQL and entered in the connection credentials and clicked the confirm button, only to receive an error on the page (not a YSOD) that says, "Could not save the web.config file. Please modify the connection string manually. Object reference not set to an instance of an object." This is some internal Umbraco error handler, so I looked at the installer source in Visual Studio. Turns out that on line 219 of Umbraco's GlobalSettings.cs file shows: webConfig.ExeConfigFilename = FullpathToRoot + "web.config"; The actual file is named Web.config. This was the moment that I sighed really big, as I discovered that the Umbraco developers didn't pay attention to matching the casing of the actual filenames to the ones they use in code. This kind of error is everywhere, since Linux is a case-sensitive environment and Windows is not.

• I fixed the error in the Umbraco source code on my Windows box, and for now, renamed the Web.config file to web.config.
• 2/5: Clicked Install. The DB install was successful. Hooray!
• 3/5: Validate permissions: Successful (note: I'm running as a non-admin user in my own home-directory. I sure hope that there aren't going to be any permission problems!)
• 4/5: Umbraco Security: password was changed successfully.
• 5/5: Foundation. Since I'm not really experienced with Umbraco, I figured I would try first using the Runway install, since that seems to be what the Umbraco team is pushing novice users to choose. So that's what I did this time.
• Got a YSOD with, "The file '/umbraco/developer/packages/LoadNitros.ascx' does not exist."

This was another casing issue with the packages directory. It was named, "Packages".

• Renamed the packages directory to ‘packages' and retried the page.

Now at this point I'm getting an odd YSOD that doesn't make much sense. Took a look at the web.config file and it seems to be missing half of the file. I figured that this was a pretty decent first attempt and I decided to blow it all away and try again, knowing now what I do about the initial problems with Umbraco.

Second Test: Binary Distribution

Third Test: Binary Distribution

I opened up Mono's mcs/class/System/System.Collections.Generic/SortedList.cs file, and sure enough, the author appeared to have gotten the parameters reversed in the ICompare.Compare() method call. Whoops!

• I changed line 646-649 to read:
  
  int cmp = comparer.Compare (table[guess].Key, key);
  if (cmp == 0) return guess;
  if (cmp < 0) left = guess+1;
• Recompiled and installed Mono.
• Filed as bug with patch and unit test cases as #521750.

After doing this, the logs matched up and the infinite URL redirection has subsided. Now it seems I was really getting somewhere.

• Removed the custom logging changes I made to Umbraco to help diagnose the previous issue, and redeployed from my windows box.

ThreadAbortException Issue

Now if this is true, the only solution that I can see to this issue is to set a flag so that new requests are delayed while the active requests are finished processing. When no more requests are active, Mono then reloads the AppDomain and resumes handling requests.

Looking at Mono's mcs/class/System.Web/System.Web/HttpApplicationFactory.cs file, I can see the code that watches for changes and triggers the AppDomain reload, however I do not see any hints at the issue that I described above. I'm not entirely sure that this is the place to implement such a fix, but it's at least a start into the diagnosis.
What does this issue mean for Umbraco — as well as any other .NET application that makes frequent file system changes? It means that Umbraco will not be stable on Mono until this issue is resolved.

This diagnosis, explains the strange behavior with the web.config editing. About 50% of the time, when going through the installation, the application would modify the web.config file and attempt to do more processing after. Since the HttpApplication watchers picked up on the change, it instantly fires off the ThreadAborts and the request dies shortly after — or DURING — the write of the web.config file. This explains why the file would sometimes be complete or partially incomplete after the ThreadAbortException YSOD occurs. During the installation, the web.config file is edited twice, leaving for a very high chance that the file will be left in a screwed up state unless I restored it from a known working config.
This is the main issue plaguing the Mono + Umbraco duo. Filed as bug #522017.

Mono Page Parsing

While debugging Umbraco, I discovered an instance in Umbraco's umbraco/TreeInit.aspx where an <asp:PlaceHolder runat="server"…></asp:PlaceHolder> element existed inside of a client-side <script> … </script> tag. Mono would completely ignore this runat=server tag. That's very bad news. After poking around the System.Web.Compilation namespace for answers, it appears that previous developers KNOW that the page parser has a number of kludges — This being one of them. The answer for this (for now) is to convert the tag into a self-closing server tag, and you'll be back in business. So that's what I did. Changed to <asp:Placeholder … /> and then it worked. This is an obvious limitation with Mono, and needs to be fixed. There are bugs already filed related this, such as #367273.

On a side note, I seem to remember seeing comments that hinted that the entire parsing algorithm should be rewritten. I'm hoping that someone — maybe even me if I can get some help — will take a look at getting this done.

Update: 07/13/09: It appears that in some of the existing bugs filed under the System.Web space, that the entier Asp parser is scheduled to be completely rewritten soon. This is real good news for lots of these more complex issues.

Another instance of a major issue with the page parser is for non-html markup output pages. In this case, Umbraco's umbraco/js/contextmenu.aspx file is used for generating a dynamic JavaScript document. The server Page_Load method sets the response headers (which I also realize can be done in the server tag parameter) and the markup file of the page writes JavaScript, as well as some additional dynamic JavaScript from the Page_Load method. I've done similar things like this with other languages, and most recently in .NET with PDFs. Normally this isn't an issue. However with Mono it currently is.

In the markup file, there exists a for-loop with a less-than conditional, "<". When Mono parses the page, it treats the conditional as the opening of a tag, and then throws a ParseException when it reaches the end of the page, never finding a closing ">" character. Microsoft apparently just ignores the parse error and moves on to the next token. Mono, on the other hand, immediately aborts the rest of the page parsing.

Don't quote me on this, but I know of a server tag parameter called CompilationMode="never". When this is set, I believe all asp and subsequent server tags are ignored while parsing. When changing this in mono, this had no effect on the ParseException because the exception occurs before the CompilationMode parameter is even found or used.
Obviously, I can hack Umbraco to wrap the JavaScript in the markup file with something on the order of:

Wrapping the JavaScript code in an HTML comment is a hack for the problem. However, it still does not FIX the problem.
Now I know, "just because it works on Microsoft's platform doesn't mean it should work on Mono's platform" is a very valid argument for this issue. The problem I see though, is how do you handle custom page output with literal greater-than and less-than symbols that won't affect the parsing of the page and the output of the page?
Asp.Net  has been used as a templating language for many applications, including the SubSonic project. They use Asp.net template pages to generate C# code. When the page is output, sometimes a literal greater-than or less-than symbol is required. Using HTML entities won't work for this.

So really, I'm asking: What is the best way for this issue to be resolved? Is there a great technical work-around for this issue that makes sense for all situations — ignoring how Microsoft does it now?

Update 07/13/09 - Looks like the Asp parser rewrite will solve this issue.

Already filed as bugs: #339039, #323719.

Inline ASP

HTTP Debugging Proxy

During the course of the experiment, I used Fiddler, an HTTP debugging proxy. I set Firefox to run through the proxy on my Windows machine, so that it was really easy to spot when 404 and 500 server errors show up. 404's are obviously to do with the case-sensitive nature of the linux platform, but the 500s make it easy to spot when a page (like TreeInit.aspx) is misbehaving.

Conclusion

See Also

• http://www.mono-project.com/ - Mono Project Home
• http://www.umbraco.org/ - Umbraco open-source content management system