Hot Off the Presses: Unity Goes to Windows

by Miguel de Icaza

Unity has announced that their Unity 2.5 IDE is now cross platform and now works Windows in addition to MacOS.

Unity rebuilt the entire Cocoa-based UI that they had previously with a Unity-powered UI. The entire UI is now built in C# using the Unity built-in APIs (all the controls, views, widgets).

This is a little bit like a compiler compiling itself. This time it is an IDE built using the IDE itself

Posted on 19 Mar 2009

Lucas integrates csharp REPL into Unity

by Miguel de Icaza

Lucas Meijer has integrated Mono's C# REPL into Unity.

Visit his post and check out the flash demo of the C# REPL in action.

Posted on 18 Mar 2009

Voices from Post-Saddam Iraq

by Miguel de Icaza

My friend Victoria Fontan who works at the UN's University for Peace in Costa Rica just published the book from her research work on Iraq.

The book is Voices from Post-Saddam Iraq: Living with Terrorism, Insurgency, and New Forms of Tyranny. From the editorial reviews:

Even today, most Americans can not understand just why the fighting continues in Iraq, whether our nation should be involved there now, and how we could change our tactics to help establish a lasting peace in the face of what many fear will become a full-fledged civil war. In the book at hand, Victoria Fontan - a professor of peace and conflict studies who lived, worked and researched in Iraq - shares pointed insights into the emotions of Iraq's people, and specifically how democratization has in that country come to be associated with humiliation. Including interviews with common people in Iraq this work makes clear how laudable intentions do not always bring the desired result when it comes to international conflict and cross-cultural psychology. For example, Fontan explains, one might consider the comment of a young Shiite: "The greatest humiliation of all was to see foreigners topple Saddam, not because we loved him, but because we could not do it ourselves." This gripping text is focused on a new and growing area of human psychology - humiliation studies.

Please vote to have the book available on Kindle. I got a hardcopy, but I would love to travel with it instead.

Posted on 16 Mar 2009

Mono and Qt

by Miguel de Icaza

The KDE folks have created some brilliant bindings for Mono and .NET called Qyoto.

But there is nothing like a polished application to really test the bindings. This week Eric Butler announced Synapse: an advanced Instant Messaging platform.

This is the first large application built with Qt/Qyoto/Mono and it is a beautiful application:

I had a chance to see Synapse live a couple of weeks ago in Seattle when we met Eric for dinner. Eric has written a very polished application. This is what love does to software.

Congratulations to Eric for the release of his app, to the Qymono crowd for creating these polished applications and Nokia/Trolltech for releasing Qt under the LGPL license.

Developers interested in doing Qyoto development with MonoDevelop can take advantage of the QyotoDevelop add-in that Eric created as well. This add-in generates code from the Qt Designers UI files (click for a screenshot).

Posted on 16 Mar 2009

Mono's Text Template Transformation Toolkit (T4)

by Miguel de Icaza

At the ALT.NET Seattle conference I was introduced for the first time to the Text Template Transformation Toolkit. Also known as T4. T4 is built into Visual Studio and developers use TT to generate code from all kinds of data sources. This tutorial covers the basics.

T4 Support in MonoDevelop, with error reporting and document outline.

T4 is very much like ASP.NET in that code is mixed with output code. Additionally TT has access to data on its "host". This allows for some creative data extraction from the environments before it generates output.

To my surprise T4 thing is wildly used by lots of people. Daniel Cazzulino's company has a product just to improve Visual Studio's support for editing .tt files.

What really got me interested in T4 were the templates that Damien wrote to convert from DBML files into C# code that is suitable for use with Linq. A nice replacement for the SQLMetal tool.

I mentioned this -in passing- to Michael Hutchinson as he had been working on ASP.NET MVC support for MonoDevelop and there are some nice ASP.NET MVC T4 files out there.

In a week he implemented: the T4 command line tool, the MonoDevelop host (to support ASP.NET MVC) and he even added syntax highlighting to it (see the above screenshot).

We have also started using it to migrate the code that previously used assorted WriteLines to generate RPM files from Visual Studio/MonoDevelop projects into a nice T4 template:

Packaging Template

Posted on 10 Mar 2009

Gnome Do

by Miguel de Icaza

Gnome Do got a new and shiny web site.

Posted on 24 Feb 2009

ALT.NET this weekend

by Miguel de Icaza

My friend تلة جوزيف (Youssef) and myself will be heading out to Redmond for the ALT.NET Seattle event this weekend.

This will be my first ALT.NET conference and I do not know quite what to expect. Youssef keeps telling me "You should not prepare for this", but I feel like I should at least prepare something exciting to get the juices flowing for discussion.


Posted on 24 Feb 2009

CoyoteLinux uses Mono for syadmin tools

by Miguel de Icaza

Interesting find: Coyote Linux -a firewall in a box- configuration of Linux is using Mono and ASP.NET for its admin tools.

Web Admin

Here is the rationale for the switch to C#:

One of the biggest changes to this release of Coyote Linux is the use of C# as the primary development language used for most of the administration, configuration, and maintenance utilities. Previous implementations of Coyote Linux made heavy use of C, Pascal (namely Delphi), and Bash shell scripting for this purpose. The change is being made to C# after nearly 2 years of working with the language in a cross-platform setting which involved the use of both Red Hat Linux and Windows 2003/2008 servers. The ability to use a single development environment (in my case, Visual Studio 2008) and produce executables that will execute in unmodified form on both Linux and Windows has seriously put the “R” in RAD programming. I am still actively involved in projects that require the development of cross-platform utilities and am already paying for all of the necessary licenses to provide my company with a full array of software and hardware to develop applications that work in a mixed server OS environment.

I have spent a great deal of time testing C# applications under Linux using Mono as the executing environment. While this is not necessarily the best choice for small, embedded hardware (486 / ARM class processing power) it works very well for anything using i686 or better technology. Another wonderful advantage of using this technology is the ability to run the same set of executables on both 32 and 64 bit hardware without the need for compatibility libraries to be installed. The installation of Mono dictates the 32/64 bit execution environment, preventing the need to recompile the full Coyote Linux software package.


Posted on 22 Feb 2009

System.Shell.CommandLine does not belong in System.Core

by Miguel de Icaza

Update: Justin Van Patten at Microsoft clarifies that the System.Shell.CommandLine API that was on the CTP for VS2010 will not be part of the final .NET 4.0. Instead better versions (similar in spirit to Mono.Options) will be made available in CodePlex in the future. Relief.

Update 2: Justin gave me permission to quote from his private email, which I include:

We are not shipping System.Shell.CommandLine in .NET 4. This was based on an intern project from a couple of years back that was mistakenly public in the .NET Framework 4.0 CTP. It wasn't a design that we were happy with and has been removed and will not be present in the next preview release.

We have a *much better* command line parsing API, along the lines of Mono.Options, that we're planning to release on CodePlex later this year.

Today I was alarmed by a new API being introduced into .NET 4.0, the System.Shell.CommandLine which is being dumped into System.Core.

An introductory blog post shows a bloated, over-engineered, too rich in the OO, too poor in the taste look at the API. Not only it is a terrible API, it is being dumped right in the core of the framework on the System.Core assembly.

This is the kind of API that you get when the work is commissioned as opposed to be created as an act of love. This is what you get from a culture of process. Some PM figured out "We need command line parsing". And since it does not look like rocket science they assigned this to someone that had absolutely no interest in this task. And clearly nobody involved (the PM, the developer and the tester) fought back. They were forced to do this, and they came up with this aberration, hoping that the sooner they were done with this, the sooner they could move on with their lives.

Compare this with the labor of love from Jonathan Pryor and his Mono.Options library. This API was discussed publicly, it was adopted in a few applications and tried out, it was morphed to support Windows, Unix and GNU style command line options and the result shows what passion and love deliver when it comes to APIs.

Compare and contrast. This is the sample posted for on the blog above:

	using System;
	using System.Shell.CommandLine;

	class Program
	static void Main()
	            Console.WriteLine("Checks a disk and displays a status report.\n");

	            CommandLineParser cmd = new CommandLineParser();
	            cmd.AddParameter(CommandLineParameterType.String, "volume", ParameterRequirement.Required,
	            ParameterNameRequirement.NotRequired, "Specifies the drive letter.");
	            cmd.AddParameter(CommandLineParameterType.Boolean, "F",      ParameterRequirement.NotRequired,
	            ParameterNameRequirement.Required,    "Fixes errors on the disk.");
	            cmd.AddParameter(CommandLineParameterType.Int32, "L",      ParameterRequirement.NotRequired,
	            ParameterNameRequirement.Required,    "Changes the log file size to the specified number of kilobytes.");

	            catch (ParameterParsingException ex)

	            string volume = cmd.GetStringParameterValue ("volume");
	            bool fix      = cmd.GetBooleanParameterValue("F");
	            int? logSize  = cmd.GetInt32ParameterValue  ("L");

	            Console.WriteLine("Checking volume {0}...", volume);

	            if (fix)
	                Console.WriteLine("Fixing errors...");

	            if (logSize != null)
	                Console.WriteLine("Changing log size to {0}...", logSize);
	                Console.WriteLine("Current log size: {0}", 1024);

This is the equivalent in Mono.Options. With Mono.Options you can take advantage of C# 3 features and make the code more succinct. An important style difference is that the policy is not limited by what can be poorly expressed by an enumeration but can be anything that can be expressed with a real language.

What is the point for "ParameterNameRequirement.Required" for example? This is essentially a bool option with a long name. The fundamental problem is not that it looks like someone left a turd on my source code or the fact that it is a glorified bool value. The problem is that enumerations and an OO structure will not give you the flexibility that is required for command line handling. This API would not be able to cope magically with conflicting options (either -a or -b can be used) or with options that are required if another option is set (if -v set, then -log is needed) or with custom parsing required after the basic command line options are parsed (consider a C compiler, -I and -L and -l options can be specified multiple times).

This is the equivalent code in Mono.Options. Notice that the policy can be enforced either outside of the parameter parsing (after the basic parsing has been done) or as each one of the delegates for the options:

	using System;
	using Mono.Options;

	class Program {
	    static void ShowHelp (string msg, OptionSet p)
	        p.WriteOptionDescriptions (Console.Error);
	        Console.Error.WriteLine (msg);

	    static void Main (string [] args)
	        Console.WriteLine("Checks a disk and displays a status report.\n");

	        bool fix = false;
	        int logSize = 1024;
	        string volume = null;

	        OptionSet p = new OptionSet ()
	            .Add ("volume=", "Specifies the drive letter.", v => volume = v)
	            .Add ("f|F",  "Fixes error on the disk", v => fix = true)
	            .Add ("l=", "Changes the log file size to the specified number of kilobytes",
	                  v => logSize = int.Parse (v));

	        try {
	            p.Parse (args);
	        catch (OptionException)
	            ShowHelp ("Error, usage is:", p);
	        if (volume == null)
	            ShowHelp ("Error: must specify volume", p);

	        Console.WriteLine("Checking volume {0}...", volume);

	        if (fix)
	            Console.WriteLine("Fixing errors...");

	        if (logSize != null)
	            Console.WriteLine("Changing log size to {0}...", logSize);
	            Console.WriteLine("Current log size: {0}", 1024);

The number of lines is roughly the same, but one is an eye sore and limited. The other is both beautiful and extensible.

Both APIs are capable of more. But System.Shell.CommandLine will merely give you more enumerations with limited functions and you will end up rolling out your own if you want to do anything remotely interesting.

Mono.Options is more of an open ended, future-proof and extensible API. It is implemented as a single C# source file (1,112 lines of code) that you can use in your own projects (and even tune/modify), you can start using today and will work on .NET 2.0 and up, it is nicely documented. More examples: here, here and here.

System.Shell.CommandLine does not belong in System.Core. System.Core is a fundamental assembly that will be everywhere .NET is, and it will soon enough run into the same upgrade and maintenance restrictions that mscorlib has.

This API needs to be moved into CodePlex or be available as an unsupported "PowerOverEngineeredPack.dll".

Posted on 21 Feb 2009

MonoDevelop 2.0 Beta 1

by Miguel de Icaza

Earlier this week we released the first beta of MonoDevelop 2.0.

MonoDevelop 2.0 is a very ambitious release in terms of the new functionality available since the MonoDevelop 1.0 release back in March 2008. It is ambitious, but also very stable, we have had hundreds of people dogfood this new release of MonoDevelop during the entire development cycle.

There are a number of new features since MonoDevelop 2.0 that are worth calling out:

Built-in Debugger

MonoDevelop now has a built-in debugger. The debugger supports both debugging Mono-based applications as well as native applications using GDB.

While hovering over variables, you can explore the values of complex data structures:

Breakpoints and Tooltips

You can debug both at the source code level, or the generated assembly code:

Debugging the Mono Runtime

Auto-complete on the watch window:

Auto-complete in the watch window.

You can also attach to running processes, both native or Mono processes and debug them:

Process selector

For more information see our list of supported features.

Improved ASP.NET support

Our ASP.NET story is getting better. web projects are now compatible with Visual Studio 2008 and Visual Web Developer 2008 SP1.

Our ASP.NET text editor now offers code completion of tag, attributes, attribute values and event handlers is now supported for ASP.NET and various HTML DTDs. For example:

We also now have DOM breadcrumbs in the editor as you edit your file, and a nice DOM/Document outline for navigating your HTML and DOM documents.

The beta does not contain this feature, but we will be publishing an Add-in that will help you get your ASP.NET MVC projects up and running with minimum hassle by the time ASP.NET MVC ships.

New Text Editor

A new text editor, this text editor is written entirely in C# and replaces the GtkSourceView widget. This has allowed us to more easily add features to the editor and bring MonoDevelop to the 21st century. Some of the features in the new text editor include:

  • Flagging errors with underlines on the fly.
  • Change bars (track what changes are in your buffers).
  • Incremental search.
  • Code folding: Support for collapsing regions of text (#region), methods, classes.
  • Themes for the editor.
  • Source code split views.
  • Transparent popups. Holding down the Control key when a completion popup is shown will make the popup transparent to make it easier to see the text that is underneath the popup.
  • VI-mode support. We understand that some of our users would rather use VI keybindings than Emacs keybindings. VI support is here.

Source Code Editing

Intellisense now works for pretty much every piece of the C# 3 language. I am not supposed to use the word "Intellisense", but I just did.

Also, sagacious readers will have noticed that I sneaked in "3.0" in the above statement. MonoDevelop now understands the C# 3.0 syntax. A great companion to our award-winning C# 3.0 compiler.

Now, technically speaking we have not received any awards for our C# 3.0 compiler, but we should have, because we are awesome. And in fact, I will be arranging a dinner at my place this coming weekend where we will award prizes to the best pieces of technologies and our C# compiler is a nominee.

Notice how it also supports nice automatic generations of methods when you declare an event:

MonoDevelop is also aware of types, so for example, if you type "override" when entering a method, it will offer a list of methods that can be overwritten. O-M-G.

There are other cute features like MonoDevelop can stub out interface methods for you. O-M-G.

There are also a few features that we liked from editors like TextMate that should make it more suitable for managing web projects like the revamped "Go to File" dialog (invoke it with control-alt-o). It is now able to do acronym searches.

New XML Editor

The XML Editor from SharpDevelop has been fully integrated into MonoDevelop and improved. It supports code completion of tags, attributes and attribute values (available for registered XSD schemas). A range of schemas are supplied with MonoDevelop.

XML files can be validated using the built in schemas, and can have XSL transforms applied. in addition, XSD schemas can be generated from XML files.

For instance, it is currently used to allow editing of Silverlight XAML files and have auto-completion of XAML tags that are valid for Silverlight/Moonlight.

Project Improvements

We have switched to msbuild-style project files to increase interoperability with Visual Studio.

Support for opening multiple solutions at once, and support for Workspaces.

We now have cascading project policies. This is useful for example to use different coding styles depending on the project that you are working on.

Cascading Project Policies

Gtk# GUI Designer

You can now make your custom widgets available on the toolbox, by just adding the [ToolboxItem] to your widget.

My favorite one is that now constructed dialogs and windows expose the Gtk.UIManager as a field. It was previously hidden, and not possible to adjust the UI dynamically without much work.

Assembly Browser

There is no better way of learning an API than browsing the data types exposed and their relationships. A new Assembly Browser has now been included.

Assembly Browser


A cute little window pops-up when you press Control-Tab these days:

Vala Support

Support for the Vala programming language has been integrated:

Vala Support

The Future: MonoDevelop, the Cross Platform IDE.

We are very excited about this release, and there are a few areas in which we would like to improve MonoDevelop for future releases.

We want to bring MonoDevelop to Windows to be able to reach into more users and to help developers doing Gtk# development on Windows.

MonoDevelop on Vista.

We are also currently shipping a preview of MonoDevelop for the Mac, it is not yet ready as there are a few kinks that need to be sorted out on that platform, but we are working to resolve those issues. For example, we want to integrate with the Mac menu system, and to provide bindings that are familiar for Mac users. Here is a preview:

Super-Alpha-Preview of MonoDevelop on OSX.

Unity has stated that they will be making MonoDevelop the standard editor for Unity3D on MacOS.

Posted on 19 Feb 2009

« Newer entries | Older entries »