Cross-Platform Network Applications with Mono

Curious about .NET? Try out this useful sample app that exercises the GUI and XML-RPC features of Mono.
Updating the Weblog

The clicked signal on the Update button is bound to the method OnUpdateClicked. This process is too long to reprint in full in this article, but the operation is simple enough. First, it gets the text from the two text controls and creates a hash table representation of the post; this is required for the MetaWeblog API call. Depending on whether the EditingOldPost flag is set, the method then sends an XML-RPC request to the Weblog, using the metaweblog.newPost or metaweblog.editPost calls as appropriate. When the Weblog returns a successful response, indicating that it has been updated, the method finally clears the text forms and allows the user to start anew.

The other buttons on the main window, New Post and Quit, are short snippets of code. Like the Post button, the clicked signals are bound in MonoBlog. New Post is bound to a method that clears the text forms and sets the EditingOldPost flag to false, allowing the user to start over. Quit, as expected, exits MonoBlog using the Application.Exit() GTK call.


The .NET class library includes classes that handle reading in preferences from an XML file. Listing 1 shows an example MonoBlog configuration file.

The method getConfig(), shown below, reads in these values:

private bool getConfig {
  try {
  AppSettingsReader config = new AppSettingsReader();
  ServerURL = (string) config.GetValue("ServerURL",

  ServerUser = (string)  config.GetValue("ServerUser",

  ServerPass = (string) config.GetValue("ServerPass",

  BlogID = (string) config.GetValue("BlogID",

  NumberOfPosts =  (string)
  config.GetValue("NumberOfPosts", typeof(string));

  catch(Exception problem) {
    return false;
  return true;

The AppSettingsReader object, by default, looks for a configuration file named executable.config, so here it opens a file called monoblog.exe.config. Then, the GetValue() method is used to determine the required preference values. MonoBlog calls this method in its constructor before it attempts to query the Weblog for old posts, so it has the required information. If the file does not exist or if there is a problem reading the data, the method returns false. The constructor only calls getRecentPosts() if this method returns true, preventing garbage values from being used.

Updating the preferences is a more complex task. First, the Preferences option in the main window's menubar is bound to the method OnPrefsActivate, using Glade's Menu Editor. This brings up the dialog shown in Figure 2 and fills in the fields with the current values, if any are defined. When the user clicks on the OK button in this dialog, MonoBlog updates the variables and writes the new information back out to the configuration file. Unfortunately, the .NET class library doesn't have classes that update configuration files. As the configuration here is fairly simple, I wrote a method called saveConfig() that opens the default configuration file and writes the updated information back out to disk using a series of Write() statements. This could be replaced with a more sophisticated method that builds a proper XML document, but it was easier for this application simply to write out the values in a plain manner.

Error Handling

As MonoBlog makes calls to the Internet where things can go wrong that aren't within the control of the program (network errors, name server problems and so on), it contains some basic error handling functionality. The getRecentPosts() and OnUpdateClicked() methods are wrapped in a try...catch block. The code that accesses the Internet is executed, and if there is a problem, the following catch block runs:

catch(Exception problem) {
  MessageDialog md =
  new MessageDialog(MonoBlogWindow,


This causes an Error dialog to appear on screen, with the problem as reported by the Mono CLR included as a text message. This allows the user to continue and possibly fix the problem. However, at the time of this writing, exception support is not working in the PPC branch of the Mono CLR, so if the program runs on Mac OS X, the exception mechanism does not work and the program fails silently. Work is proceeding on the PPC port, though, so by the time this article makes it to print, this lack of support may no longer be an issue.