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.

Thoughts?

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.

Traffic

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.");

	            try
	            {
	                cmd.Parse();
	            }
	            catch (ParameterParsingException ex)
	            {
	                Console.WriteLine(cmd.GetHelp());
	                Console.WriteLine(ex.Message);
	                return;
	            }

	            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);
	            else
	                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);
	        else
	            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

Switching

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


Mono Runtime Debugging

by Miguel de Icaza

We now have better integration of GDB with Mono. Information on how to use this is in Debugging with GDB in XDEBUG mode in our wiki.

This will be useful if you are debugging the Mono runtime, or debugging Mono embedded into an application new versions of Mono (for example debugging Moonlight).

This will give you symbols for managed code in stack traces, for example the bold text in this example are the managed frames. These would previously just be rendered as "????????" by gdb.

(gdb) xdb
(gdb) bt
#0  0x0000000040cd707e in Tests:pass_floats_doubles (a=100, b=101, c=102, d=103, e=104, f=105, g=106)
#1  0x0000000040cd6fd8 in Tests:test_721_sparc_float_argument_passing ()
#2  0x0000000040a6228a in (wrapper runtime-invoke) Tests:runtime_invoke_int (param0=0x0, param1=0x7fc05e5b0e00,
    param2=0x0, param3=0x40cd6f80)
#3  0x00000000004219f7 in mono_jit_runtime_invoke (method=0x9daa70, obj=0x0, params=0x0, exc=0x0) at mini.c:4253
#4  0x00000000005c1d2c in mono_runtime_invoke (method=0x9daa70, obj=0x0, params=0x0, exc=0x0) at object.c:2399
#5  0x00000000005c39d7 in mono_runtime_invoke_array (method=0x9daa70, obj=0x0, params=0x0, exc=0x0) at object.c:3488
#6  0x00000000005cdc31 in ves_icall_InternalInvoke (method=0x7fc05c371be0, this=0x0, params=0x0, exc=0x7fff66729368)
    at icall.c:3038
#7  0x0000000040cd6bee in (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (
    this=0x7fc05c371be0, param0=0x0, param1=0x0, param2=0x7fff66729368)
#8  0x0000000040cd690c in System.Reflection.MonoMethod:Invoke (this=0x7fc05c371be0, obj=0x0, invokeAttr=0x0,
    binder=0x0, parameters=0x0, culture=0x0)
#9  0x0000000040cd683b in System.Reflection.MethodBase:Invoke (this=0x7fc05c371be0, obj=0x0, parameters=0x0)
#10 0x0000000040a6275c in TestDriver:RunTests (type=0x7fc05e5b6dc8, args=0x0)
#11 0x0000000040a62380 in TestDriver:RunTests (type=0x7fc05e5b6dc8)
#12 0x0000000040a62354 in Tests:Main ()
#13 0x0000000040a6228a in (wrapper runtime-invoke) Tests:runtime_invoke_int (param0=0x0, param1=0x7fc05e5b0e00,
    param2=0x0, param3=0x40a62340)
#14 0x00000000004219f7 in mono_jit_runtime_invoke (method=0x9576f0, obj=0x0, params=0x7fff66729600, exc=0x0)
    at mini.c:4253
	

For people running the archer branch of gdb, there is a "mono mode" implemented in python for gdb, which offers additional features: http://anonsvn.mono-project.com/viewvc/trunk/mono/data/gdb/

Posted on 19 Feb 2009


Mono on Android, update

by Miguel de Icaza

Koushik Dutta has posted two great updates on his blog about Mono running on the Android powered G1 phone. The code necessary to build Mono on Android is available at the androidmono page.

The first bit is his work to allow Mono code to call Dalvik code as well as the bridge to allow Dalvik/Java to call into .NET code. This is necessary to allow Mono-based applications to call into the phone API and integrate with the existing stack.

The second bit is a cute show of DLR-based IronPython running on the phone.

This of course means that with the bridge in place, any CLR or DLR-based language can access the functionality exposed in Dalvik.

Posted on 16 Feb 2009


Mono 2.0 - .NET Tool/Add-in of the Year

by Miguel de Icaza

Jeff just pointed out to me that Mono 2.0 won the ".NET Tool/Add-in of the Year" award from the guys at developer.com.

Sweetness!

Posted on 13 Feb 2009


« Newer entries | Older entries »