This is Greg Young talking to Joseph Hill about the Mono Project. Joseph, if I were not using Mono for, let's say, a purely Unix spaced environment, is there anything I can still benefit from using Mono?

Yes, it is actually a pretty important popular topic recently for us that have been interacting with the .NET community more. Lots of .NET developers might be aware that there are Mono is out there and that you could target Unix or Mac or be cross platform, but they aren't aware of that. Mono is not just an implementation of ASP.NET and Windows Forms and everything that is in the class libraries they have, but we have our own stack of lots of libraries. For instance Mono.Cecil. Cecil is an extremely useful tool. I think it's probably one of the more popular ones that has broken outside the balance of the .NET development.

Cecil is a Reflection on steroids; it allows you to load up the assemblies and you can read the data out of the assemblies without necessarily loading the assembly into your AppDomain. You can also manipulate the IL within that assembly. It is useful if you want to change an existing assembly without the source code and without recompiling it. We use Mono.Cecil and Mono.Addins, which is another utility that started to see a little bit more popularity outside of the Mono space. Mono.Addins was recently developed for MonoDevelop IDE to enable people to load up or to develop add-ins for the IDE such as ASP.NET designer - basically every component of IDE is a separate add-in.

It enables Mono.Cecil to load APIs that may be exposed in a different add-in and read that information and share it with the users as they select which add-ins they want to run in the IDE without actually loading it into the AppDomain. It works pretty efficiently. Mono.Addins is pretty popular if you are looking to make your application extensible and, if you want to have an add-in architecture, Mono.Addins provides a lot of support for that, as well as support for localization and other things you need when you start thinking about having and extensible application.

Another thing in the area of the extensibility is Mono.Rocks - that's pretty interesting - that started to get a little bit of traction. I've heard a lot of excitement about it here more than I've even seen within the Mono community itself. That is a collection of useful extension methods, particularly like N32. Once you load up the Mono.Rocks extension for N32, you enable people to save 6, which is an int, and up to 100, and that per ratio. Then we have extension methods for "join". These are things that people come in and write extension methods for and so we are hoping to get a common collection of extension methods so you have a place to go to when you need common extension methods and hopefully people have written good implementations of the things you might try to write yourself anyway.

Would you care to explain what MoMA is?

Certainly. MoMA is pretty high on the list if you go to Google for "MoMA" - and you might think that would be the Museum of Modern Art which is probably the other top result but I know we are pretty high there as well. Basically as a migration analyzer, MoMA also uses Cecil to load up assemblies, so you can take and download MoMA - it's a 4-step wizard - and you can point it at the binaries for .NET application and it will introspect the assemblies and give you a report back as to how likely that application is to run on Linux using Mono. Usually we see 4 classes of problems that .NET applications face that would prevent them from being able to run well or run at all on Mono.

The first one is: they are using a part of .NET we haven't implemented yet, so that's a pretty big deal if you are using a class or members of a class that we don't have yet and .NET goes to load up your application and then load up all your dependencies and those dependencies aren't there, the application is simply not going to load. So it will give you a list back of every place you are making a call that's not implemented or that doesn't exist. Not implemented is actually a little bit different, so that's a separate class of problem.

Within a class, we'll implement everything that we need to fill the interface that gets you past the first problems, the class is entirely here but it may not be entirely implemented. You might call different methods within that class that will throw a not implemented exception, so we haven't written it yet. That's a problem because it would be a Runtime problem. You know that the application is going to load OK but if you go through a code path and call something in Mono that throws an implement exception, then you get an error and it will report back to you about PInvokes or platform invocation, where you are calling outside the manage codes.

That's a real problem because you are probably calling in the Windows specific libraries that are not going to be available on the other platform and that seems to be the biggest road block that our people face today: they have a legacy bit of code that is neither in their own or external library and that is not going to exist in Linux. If you have too many of those your application may not be a very good candidate for porting. If you have source code for that library you may just need to recompile it for Linux or the Mac and then you would be able to call into it there. So it's not necessarily a deal breaker but it could be a little problem. We do you have a mechanism in Mono called DLL Map so if you do recompile your library to the other target you can actually give a directive to Mono "When it calls for this library, go look for the APIs in this library", so it's useful for that. There is a fourth class of problem that I can think about right now.

Sometimes a method might be implemented to Mono and might be attributed what to do and that sort of nebulous is broken, maybe it has just to do with hazard, maybe this code can be optimized to run faster. So it's something it's good to know about, I mean it is really a problem, but we are telling you so you can be aware of it. Now, the really great thing about MoMA is that, as I mentioned, it drives of development at Mono now. The last step of the wizard allows you to anonymously send all that information about your .NET application backup to us. We've had thousands of these reports submitted back to us and we were able to prioritize what portions of the .NET framework we are going to focus on and implement next, based on what people who are running the application in Mono find missing.

Apart from that, there are a lot of Winforms applications out there that are not in business, they are not open source and we, as Mono developers, don't have access to them. Prior to knowing how people were using Winforms through hard evidence such as this, we went alphabetically through the APIs like "We'll implement this, we'll implement that" and that was how we were developing things until about a year and a half ago when we introduced MoMA.

ince you've introduced MoMA, how much have you been able to prune the number of problems that have been coming out with migrations?

We introduced MoMA in November 2006 and around that time maybe 7 or 8% of the applications that were tested with MoMA had problems and they would submit a report back with all these different classes of problems. From there, we immediately gathered a short list of low-hanging fruit - we were on about 6 weeks release cycle back then -. Within 6 weeks we released the next version of Mono so we were up to 20% of applications working and each after release after that was 20% of the remaining class.

Today we typically see about 40% of the applications that people test with MoMA for Mono have no error supported and then maybe the next 20% have a couple of problems that could probably be addressed within a few hours, and then another few percent, maybe a few weeks' work. The remaining 10% have a lot of PInvokes or significant changes would be needed to their code to run on Mono, so we don't necessarily consider them good candidates for Mono.

Are there any other interesting bits coming out of Mono these days, large new developments?

I think there are a lot of developments. The first one that comes to my mind, because we talked about migration, that I should probably mention because hasn't been well publicized, is that we have an abstraction layer in Mono called Mono IO Map. If you set an environment variable, this is getting deeper, but if this certain environment variable that says MONO_IOMAP before you run your Mono application, we can abstract everything that is platform specific which typically tends to be a problem. If you are in cross-platform development, you run into problems like back slashes.

Windows commonly uses slash separated characters or forth slashes in Unix and all of the access to the file system is case sensitive, so if you turn on an abstraction later all those problems are removed for you when you access the file system will turn your back slashes into forth slashes and will look for the right file based on that case sensitivity. I think that's an important development that's actually been on for a while that is underreported. Let's talk about other interesting exciting news too, if you are interested.

JH: Probably the most relevant thing that has been talked about recently is Moonlight, our open source implementation of Silverlight. If you are interested in Silverlight, you are probably pretty excited to know that it's not just limited to Windows and Mac, because if you are interested in having a truly ubiquitous platform, it's nice to know that Moonlight provides the same level of operation for Silverlight on Linux. It's, I believe, exciting for other reasons to you though, because Moonlight is an open source implementation. You can do interesting things with Moonlight that you couldn't do with Silverlight.

We enable concepts on Linux of being able to embed Moonlight in your application and gives you vector rendering and access to the Silverlight functionality within your application or you could write desklets where we just run Moonlight or Silverlight directly on the desktop. That's interesting, because it's open source and that's where package is. We can enable another scenario which is that Silverlight is just a small portion of the .NET based class libraries from .NET 2.0 we have a tool called MOpen which is actually Silverlight plus all of the rest of .NET 2.0. So you can write full .NET 2.0 applications with the Silverlight rendering engine and renders on your desktop and have things like file IO and break outside of the browsers sandbox and I believe that enables some interesting scenarios as well.

You used to see a lot of developers compiling in Windows and then just moving binaries over to Unix. Are you seeing now a lot of developers compiling natively in, let's say, a Mac and moving their binaries directly to Windows.

I like that story. I don’t know if we are seeing a lot of people, I am seeing a lot of interest, we do work to enable that. So we ship Mono for the Mac and our Mono comes with everything you need to run ASP.NET and Winforms applications on the Mac and it also includes MonoDevelop, which is our Visual Studio or IDE, and I think it begins to make a compelling case for what you are saying. Today .NET developers that purchase Macs usually depend on Parallels or Fusion so that they continue to run Visual Studio, doing everything else natively in the Mac.

So I think MonoDevelop definitely opens the doorways for people to move at least some of their .NET development into working natively in the Mac. Going forth, we've just released MonoDevelop 1.0 in March and that has good support for compiling and good support for IntelliSense within C# and a few other good IDE features, but we are on a 6 month release cycle now for MonoDevelop; when MonoDevelop 1.0 comes out this fall, I think. That story will start to become really compelling for Mac because the current stuff that's in trunk enables IntelliSense within the ASPX designer so we have much better support for doing ASP.NET development on the Mac, which is probably where it's going to be most popular anyway, as well as probably better support for working with database.

Mono supports lots of databases beyond the SQL Server and we have a database add-in for MonoDevelop, which allows you to execute queries and explore the schemes of all these various databases that we support, which is pretty much the complete web development story for the Mac.

You are currently approaching Mono version 1.9. You are really heading a major goal.

Yes, previously, Mono had a Linux versioning scheme, but I think that was really confusing particularly to the .NET portion of our target market, which is a lot of the people we want to use Mono, or we want to make .NET developers into cross-platform developers. They would look at the previous version of Mono, Mono 1.2.6 and say "Well that sounds not like much more than .NET 1.1", but in actuality we've had ASP.NET 2.0 complete for over a year and 1.2.0 is mostly complete at this point; it's been the main thing that held us back from having a complete 2.0 story. We changed the versioning scheme recently, Mono 1.9 was released in March and that was just another indication to the .NET community and the Mono community in general that we think .NET 2.0 is pretty well complete.

In June, probably around that timeframe, we are targeting to release Mono 2.0, which should pretty well be .NET 2.0 in a fairly stable form. Beyond that though, it's a shame that .NET has such a messed up versioning scheme on it's own because you've got 3.0, which is WPF and WF and WCF and then you've got .NET 3.5, which is C# 3 and Link. We actually have C# 3 complete so Mono 2.0 includes C# 3, LINQ to XML, LINQ to objects, doesn't have LINQ to SQL - that's a little bit lower on our priority list. Mono 2.0 that's .NET 3.5 but it's not .NET 3.0, but it is .NET 2.0.

If someone wanted to help, where would they get started?

That's an interesting question. The most useful thing you can probably do is solve a problem for yourself. If you have an application that you want to see running on Mono and you write it in MoMA and you find out that the parts you need aren't there, you can download the source and feel free to fix the components that are missing and submit us the patches. I don't know if we have a Visual Studio solution for everything in Mono, but a lot of the components of it do include the Visual Studio project. If for instance, you want to help contribute to Winforms, you can go get the system that Winforms project and you can build that in Visual Studio, just that name space alone, leaving out the other components.

So, it's actually a lot easier to contribute to Mono than you might be aware. Running MoMA, and then submitting your reports to us actually helps quite a bit as well, and we have a very active community on IRC, probably jump a little bit in there and find plenty of places you could help.