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?

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

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

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.

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/

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.

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!

Linus Torvalds does 25 things about me.

Now that Moonlight 1.0 is out, I should talk a little bit about Aaron Bockover's amazing Moonshine plugin.

Moonshine's About Box while playing HBO.com

Moonshine is a tiny plugin that registers itself with Firefox to render Windows Media streams and emulates the Windows Media Javascript API by redirecting it to Moonlight.

So when you visit a page that in the past used to embed the Windows Media Player (for example at HBO.com or at C-SPAN), instead you get a Moonlight-based rendering engine and uses Microsoft's Media Pack for doing the video and audio playback.

It is trivial to install it, just go to this page and click on the moonshine that is right for your platform.

Internally we referred to this project as "Pornilus" a homage to the Roman senator and patron of the arts from the 3rd century. And like Pornilus, we want to bring the arts to the people.

Cute fact: Pornilus/Moonshine will pick-up your Gnome theme and theme itself accordingly.

Oddly enough, there is no Wikipedia page for Pornilus yet. Someone needs to correct this.

Moonlight, the open source implementation of Silverlight for Unix systems has officially reached its 1.0 level. We are feature complete, we pass all the Microsoft regression test suites and we shipped support for Microsoft's Media Pack for x86 and x86-64 architectures.

Moonlight is available as a Firefox plugin that can be installed with a single click from the moonlight download page.

What is in Moonlight 1.0

Moonlight 1.0 contains our plugin that can be used in Firefox 2 and 3 on Unix systems using the X11 windowing system.

Moonlight 1.0 (and Silverlight 1.0) both come with a graphics pipeline, video and audio frameworks and a javascript bridge and neither one of them contains an actual execution environment. The execution environment is the browser's own Javascript engine. When developers build 1.0-based plugins they script all of the functionality using the browser's own Javascript engine.

The browser Javascript engine communicates with Silverlight (or Moonlight) through the Javascript API exposed by the plugin.

With Silverlight 2.0 and Moonlight 2.0 in addition to this model where the browser's Javascript drives the interaction a new model is available: the ECMA CLI execution system powers the actual execution of the code and will deliver performance anywhere between 20 to 300 times faster execution speed than even the most modern Javascript implementation if you use a strongly typed language like C# or Boo.

CNN's The Moment on Moonlight.

It is worth pointing out that Moonlight is provided both for 32 bit systems and 64 bit systems on the launch date.

We are also hoping to expand our reach to other Unix variants that use X11 like the various BSD systems and Solaris and make codecs available for those.

How we got here

The development of Moonlight has been a fascinating adventure. It all started at the Mix conference in May 2007 when Scott Guthrie introduced Silverlight 1.1. It was a bold move for Microsoft to embed the ECMA CLI into their Silverlight 1.0 plugin.

In my blog post called "Mix 07, Silverlight, Dynamic Languages Runtime and OpenSource". From that post you can see that I was already excited about the technology, and I could not wait to get this technology to Linux. The talk on the DLR at Mix 07 was also fascinating and got me interested in bringing this to Linux.

A few weeks after the DLR had been announced and open sourced, our team had it working on Linux with Mono and by the end of May I had cooked up enough to render a spinning video on the screen.

IronPython 3D visualization on Moonlight

It was during the dynamic language workshop at Microsoft that I had a chance to have dinner with Jason Zander and Scott Guthrie in an Indian restaurant in downtown Redmond. In this dinner they discussed some of the design tradeoffs in Silverlight and these would become part of our own implementation a few days later.

At Mix 2007 I had the chance to meet Marc Jalabert from Microsoft France. Marc invited me to the Remix event in Paris but did not take the invitation seriously until he offered us to demo Moonlight on Jun 21st.

Other than a spinning video and the DLR we did not really have much code so on May 31st I sent an email to the team and asked them to work on an intense 21-day hackaton to bring Silverlight 1.1 to life on Linux. By Jun 21st we had a demo working and we showed Silverlight 1.1 applications (with the CLR) running on Linux.

A few weeks passed by, and Jeff Jaffe from Novell asked me to present our Moonlight to Bob Muglia as part of the regular Microsoft/Novell interoperability meetings. After struggling with the video projector for what seemed like an eternity the Silverlight Chess and the Silverlight Airlines demo came up on the screen on Linux.

In the meantime, we were in love with our Moonlight engine, and we used to build desktop applications in addition to web applications.

After this meeting, I do not remember exactly how things happened as too much happened too quickly, but Microsoft and Novell agreed to collaborate on bringing Silverlight to Linux. We announced the collaboration on September 5th.

It was early on, at that dinner with Jason and Scott that the issue of how to properly license codecs for MP3, WMV and VC-1 had been discussed. We knew that we could implement the engine, but the question remained: how to get codecs to end-users in a fully licensed way. This and other problems had been already discussed and agreed on the collaboration agreement. Microsoft would develop, distribute and maintain their own Media Pack for Linux users and other Unix operating systems.

The entire media work involved hard work at every level, but it was worth the effort. We now have one of the best open source media pipelines implemented. And it will only get better with all the new features in Silverlight 2 for adaptive streaming.

The Immediate Future

We are now hard at work on Moonlight 2, and those of you interested in trying it out can do so by following the build instructions on our web site.

Silverlight 2.0 was a major upgrade from its original announcement Silverlight 1.1. It is more complete, more polished and has been future-proofed.

Microsoft has continued to help us all along in creating an open source implementation of Silverlight. They have open sourced the Microsoft DLR, the Microsoft MEF framework and the crown jewels: the Microsoft Silverlight Control Library and the Control Toolkit under the OSI-approved MS-PL licenses. Without this it would have taken years for us to catch up.

Jimmy Schementi's IronRuby + DOM + Flickr sample.

Up until two weeks ago we could not see much in the screen as a lot of Moonlight had inter-dependencies between various subsystems. But once Larry Ewing's layout system landed in our tree, magically many things started to come together.

You can try out yourself Moonlight with some very hot demos including CNN's The Moment, the Photosynth-based 3D browsing engine for Obama's Inauguration and of course the always amazing DLR demostrations.

Silverlight 3

Silverlight 2 is incredibly exciting, it is delicious and mindblowing. There is a lot of excitement about it, my favorite three sites on Silverlight 2 include:

• Silverlight News on twitter.
• Infragistics Quince: UX Patterns Explorer
• Information Visualization with Descry: a project do visualize information in interesting ways using Silverlight. The project is now open source.

Microsoft will be announcing the details about Silverlight 3 at their Mix conference in March in Las Vegas.

My wish list

I love Silverlight and the use of the CLR for building web applications. That is just how I am wired up.

I still personally wish that Silverlight 2.0 had a JSon interface to XAML, like the prototype that Chris Toshok did, or that Silverlight had a more fluent model for application deployment. I would like the XAP model to be entirely optional or non-existent for IronRuby or IronPython.