This week I've spent some time trying to fix bugs preventing Umbraco from running unmodified on Mono. Unfortunately, some modifications to Umbraco source code (diff here) were necessary due to the inherent Windows-centric coding in parts of the CMS. The diff above takes care of just one part of the cross-platform issues in Umbraco, namely it replaces hard-coded use of the \ directory separator character with the, correct, Path.DirectorySeparatorChar. For some reason MONO_IOMAP mechanism didn't take care of the problem, hence the workaround (I'm going to fix the IOMAP issue after I'm back from vacation mid-August). The other cross-platform issue is (very common in Windows .NET applications) inconsistent use of file naming case which MONO_IOMAP is dealing with nicely.
Making Umbraco run on Mono required some fixes to our ASP.NET parser (revisions 138474, 138520, 138521 and 138592 in trunk, for those interested. Backported to both 2.4 and 2.4.2 branches) as well as making AppDomain not reload when Umbraco writes to the Web.config file. All of the fixes willbe part of the upcoming 2.4.2.3 release. There are however some issues not fixed yet, but with workarounds:
- Web.config modifications during setup
- Generally it works fine - application isn't restarted, data is written to the config file, but for some reason Umbraco installer caches data from before database access credentials change. So if, for instance, you were presented with MS-SQL setup box and switched to MySQL, the connection and/or database creation will fail trying to use MS-SQL code. This is a bug in Mono which I'm going to investigate in August. Workaround for this issue is to stop the app after selecting the new database provider and credentials and just restart the installation process - everything will work fine from that moment on.
- VistaDB not working
- VistaDB comes without source, so I wasn't able to investigate what the issue was. The symptom is that when trying to connect to or populate VistaDB database you will get either a ThreadAbortException, a TypeInitializationException or a JIT error about invalid IL in the VistaDB assembly. This is likely a runtime issue - to be investigated. You can use either SQL Server or MySQL providers instead (I used MySQL for testing).
- Intermittent exceptions
- Sometimes visiting certain pages in the admin interface causes an exception to be thrown (usually NullReferenceException) but I never succeeded in reproducing the exception(s) by repeating the actions. To be investigated.
- TinyDLL.dll is a native library
- Since it is native, our compiler cannot figure out what to do with it and throws an exception. Simply remove the dll from there - it shouldn't be
there anyway.
So, this is the current status of Umbraco on Mono - please play with it and
report any bugs you might find, giving exact directions how to reproduce the issue. I will take a look at them once I'm back from vacations.
Since not everybody might want to or know how to compile and set up Umbraco from sources, I have precompiled the package with the diff applied and repackaged the 4.0.2.1 distribution with the bin/ assemblies replaced by their "Mono versions" (note that the ONLY difference in the assemblies is that the patched ones are cross-platform). Here are the download locations:
As many of you are probably well aware, we failed to ship the recently open-sourced Microsoft ASP.NET MVC with Mono 2.4.2. The release was soon followed by an update, 2.4.2.1, which included the source of MVC but, unfortunately, the story doesn't end here.
Sometime during MVC integration process, we discovered our C# compiler had a bug which made certain parts of MVC behave incorrectly. The bug was quickly fixed in trunk, but it was determined that backporting it to the 2.4 branches was not an option and since the issue was easily worked around, we decided to just put the modified MVC code in our repositories. Unfortunately, due to my mistake, the workaround didn't actually make it in neither 2.4.2.1 or 2.4.2.2 releases. I have just committed the 2-line fix (revisions r138087 and r138088) to the 2.4 branches and we should expect to see 2.4.2.3 released soon. My apologies for this omission to everybody who expected to see the bug fixed in 2.4.2.2.
If your MVC application throws an exception similar to this one:
System.ArgumentNullException: Argument cannot be null.
Parameter name: type
at System.ComponentModel.TypeDescriptor.GetConverter (System.Type type) [0x000ab] in /usr/src/tmp/mono-branch/mcs/class/System/System.ComponentModel/TypeDescriptor.cs:437
at System.Web.Mvc.DefaultModelBinder.BindModel (System.Web.Mvc.ControllerContext controllerContext, System.Web.Mvc.ModelBindingContext bindingContext) [0x000ba] in /usr/src/tmp/mono-branch/mcs/class/System.Web.Mvc/System.Web.Mvc/DefaultModelBinder.cs:186
at System.Web.Mvc.ControllerActionInvoker.GetParameterValue (System.Web.Mvc.ControllerContext controllerContext, System.Web.Mvc.ParameterDescriptor parameterDescriptor) [0x00090] in /usr/src/tmp/mono-branch/mcs/class/System.Web.Mvc/System.Web.Mvc/ControllerActionInvoker.cs:119
at System.Web.Mvc.ControllerActionInvoker.GetParameterValues (System.Web.Mvc.ControllerContext controllerContext, System.Web.Mvc.ActionDescriptor actionDescriptor) [0x00021] in /usr/src/tmp/mono-branch/mcs/class/System.Web.Mvc/System.Web.Mvc/ControllerActionInvoker.cs:128
at System.Web.Mvc.ControllerActionInvoker.InvokeAction (System.Web.Mvc.ControllerContext controllerContext, System.String actionName) [0x00099] in /usr/src/tmp/mono-branch/mcs/class/System.Web.Mvc/System.Web.Mvc/ControllerActionInvoker.cs:162
then you are hit by the bug. At this point you have three choices:
ASP.NET MVC sources in the Mono 2.4 and 2.4.2 branches are identical to the upstream source except for the workaround. Trunk version of ASP.NET MVC is identical to upstream.