Back to WordPress

After playing around with BlogEngine.NET for the last couple of months, I have decided to retire it and go back to WordPress. The bottom line is the software is not quite ready for Mono and Linux. There always seemed to be some minor issue to overcome whether it was installing a plugin or figuring out why your session was expiring unexpectedly. Most of these problems were related to subtleties in Mono’s implementation of .NET and while they were not show stoppers, they always seemed to get in the way of using the tool for its designed purpose.

I might have stuck with BE however, the project lacks any sort of unit or integration testing which would help with the quality of the releases. There appeared to be a number of bugs and discussion topics related to regression failures which confirmed this is a problem that could be mitigated through some sort of testing discipline.

I would like to thank the BlogEngine developers for creating a feature packed open source tool.  Please consider taking a test driven approach with future versions of BE and you will have a winner!

Mono Development on Ubuntu

The past month has been an in depth investigation of developing .NET applications on Ubuntu using Mono. The experiment was quite simple, use Mono and MonoDevelop to create a simple ASP.NET application. The test application was built using Mono 1.9.1 and MonoDevelop 2.0 from the SVN repository (trunk).

The application makes use of master pages and the membership API. I used the membership providers from the BlogEngine.NET project to save time. Putting the application together with MonoDevelop was not difficult however, it would have been nice to have a shortcut for adding page events to the code-behind instead of from memory or the API documentation. If this functionality exists, perhaps a reader could kindly point out how to use it.

After a couple of hours I have this little test application that serves pages to authenticated users with role based authorization. I am feeling pretty good at this point and I am ready to move to the next part of my evaluation, unit testing. This is where MonoDevelop’s warts start to surface and although I am using an alpha version of the IDE, the problem encountered has been reported in the past on the Mono mailing lists and Novell’s Bugzilla.

The first brick wall that I encountered was the inability to use a custom app.config for my NUnit tests. I have used standalone NUnit in the past under Windows and Ubuntu with a custom app.config without any problems. I simply copy the app.config to the build directory renamed to match the assembly name e.g. TestAssembly.dll -> TestAssembly.dll.config. The two files are co-located and NUnit picks up the custom configuration file. MonoDevelop ignores the custom configuration file and uses mdhost.exe.config located in MonoDevelop’s bin directory. This departs from the expected NUnit behavior and was a source of frustration until I figured out how MonoDevelop was handling the configuration files. This bug was reported over a year ago on Bugzilla without any action, see Bug #325514 for details. I hope this bug will be addressed when MonoDevelop 2.0 goes final, but I have my doubts based on the current status in Bugzilla. I have also posted this to MonoDevelop mailing list (with others experiencing the same problem) as well as adding my experiences to the existing bug report, without any feedback on the problem.

I also encountered an issue with the ConfigurationManager and ProviderSettings classes in Mono 1.9.1. Basically the name and type are saved to the configuration file with the parameters collection being ignored, see Bug #421166 for details. The sample snippet I included in the bug report is confirmed to work on Windows with the expected results. As with the previous bug I also posted my finding to the Mono development mailing list and have not received any feedback to date.

I realize that a project like Mono is a monumental undertaking and I applaud the progress made by the team to date. There are a lot of developers working on this project who know more than I and deserve recognition for their contributions. On the other hand I really worry about committing to the platform when I take the time to report basic functionality issues and see no acknowledgment or action taken to resolve them.

If you are a Mono or MonoDevelop contributor and steps are being taken to address these issues, I would love to hear from you. Again, great work and a job well done!

Mono and MonoDevelop

Two years later and a lot of work by dedicated developers, Mono’s .NET 1.1 support is essentially 100% complete. The prospect of cross-platform .NET while exciting, brought back memories of the progress made by the Wine project. Wine has been around longer than Mono and still cannot run most Windows applications in a stable fashion. This was part of my decision to wait an extended period before evaluating Mono.

Yesterday I downloaded the generic Linux installer for Mono v. and had a working Mono instance on Ubuntu 6.10 after a few mouse clicks. Using the command line tools, I compiled a couple of simple .NET 2.0 programs I developed on Windows using Visual Studio. I was able to install my assemblies into the GAC and run my applications without any errors. Mono appears to work quite well for .NET 1.1 development and has enough 2.0 support for simple applications.

My experiences with MonoDevelop were disappointing to say the least. My first attempt to create a simple ASP.NET application worked well enough, a couple of basic controls on form that echoed their content on submit. I noticed a number of quirks such as the aspx and code behind files not being displayed in a nested fashion until the project was saved and re-opened. Trying to connect to and query a MySQL 5.0 database was so frustrating I gave up. I was able to create the connection and display the tables in my database. Trying to refresh the view randomly locked MonoDevelop and trying a simple “SELECT *” resulted in a query syntax error. The same query copied from MonoDevelop and pasted into the MySQL Query Browser worked flawlessly. MonoDevelop generated numerous “data source already open” errors.

I checked out the latest MonoDevelop from SVN and built it with the alpha ASP.NET designer. JSCall-Sharp is needed by the ASP.NET editor and was checked out from the SVN trunk as well. MonoDevelop configured and built without any errors. I started the application and encountered the same errors with MySQL and could not get the ASP.NET editor to function as well. The ASP.NET editor was complaining about the number of calls present in JSCall-Sharp.

A project of this scope is difficult and complex. The members of the Mono team have made an outstanding effort creating a cross platform version of .NET. I will be waiting for the official 1.0 release of Mono before re-evaluating the platform. For now the best option for cross platform enterprise applications is still Java.