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!
Please follow and like us:
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!
Please follow and like us: