Slashdot Mirror
Mono: A Developer's Handbook
When learning a new language such as C#, or working with a new development environment such as Mono, it usually takes some time before you get up to speed in developing programs. Wading through the reference documentation and reading other people's source code often provides much-needed information on how to do certain things. Both, however, are very time consuming and tedious.
Enter Mono: A Developer's Notebook. This book provides a series of task-driven chapters which are thin on theory, but rich on practical content and example code. The featured code snippets are, in contrast to ones in books that teach theory and concepts, not solely designed to illustrate a specific theoretical aspect of programming. Each one is designed to perform a useful task that is essential in day-to-day application programming. What sets this book apart from the multitude of .NET books already available on the market? In order to answer this question it is neccesary to provide a short introduction on Mono.
Mono is essentially an open source cross-platform implementation of Microsoft's .NET development framework and implements the API's which are standardized by ECMA. It is, however, not an exact clone. Besides providing a (partially implemented) stack that provides compatibility with Microsoft's .NET API's, Mono adds a whole new API-stack of its own, consisting of open source technologies such as the Gtk+ toolkit and the Gecko HTML rendering engine. This makes it possible to develop cross-platform applications based on open source technology while (mostly) compiling from a single code-base. In contrast to most .NET books available on the market, which focus primarily on Microsoft's API's in the context of Visual Studio.NET, this book concentrates on the basic ECMA API's and Mono's own open source stack. A complete coverage of .NET and the Mono architecture is outside of this review's scope, so for more information you are advised to check the Mono Project's website.
Before we dive deeper into the content of the book, a short introduction on the Developer's Notebook series by O'Reilly may be useful. The books in this series are styled to resemble the kind of notebooks college students carry around during their classes in which to take notes or, more commonly, draw caricatures of their teachers. The 'notebook' theme persists throughout the look-and-feel of the book. The 278-page thick paperback has a glossy blue cover, complete with faux post-it note and coffee-stains. Inside, the pages are not clean white but lined like the pages found in math notebooks. In the margin, useful comments are scribbled in a font that resembles handwriting. At first I suspected that the 'busy' look would distract from the content, but in practice this was no problem, thanks to the thick black typewriter font in which the bulk of the text is printed.
The chapters in this book are referred to as labs. Each of them focuses on a specific set of tasks and/or features and is divided into several paragraphs. Most paragraphs consist of a number of standard sections following a rigid formula that help you understand a certain aspect of working with Mono. The most common sections are:
- How do I do that?: Often using a liberal amount of practical code, this section shows how to accomplish the task at hand, for example working with files.
- How it works: In this section, the code and concepts involved in the previous section are explained more in depth, step by step.
- What about...: Offers a short focus on more advanced topics or pitfalls.
- Where to learn more: If you are craving more information after reading the previous sections, you are often offered a helping hand on where to find more information, providing url's to relevant documentation such as MSDN and other websites.
The first chapter, Getting Mono Running, describes how to get Mono up and running on Linux, Windows or Mac OS X, and how to compile from source on other platforms. The installation instructions for Windows only describe how to install Mono and Gtk#. Integration of Gtk# only in an existing Visual Studio.Net installation falls outside of the scope of the book, but a recent blog entry offers some hints on how to accomplish this. Besides installation, the first chapter offers a short description of the individual tools that make up the mono development. After installation, you will want some kind of editor or IDE to work with. Both the MonoDevelop IDE and several other ways of integrating Mono into your existing environment as a Java or Windows developer are covered. Finally, the community is an important aspect of every open source project. Ways of interacting with the community as well as a guide on how to submit bugs and links to some working Mono/C# applications are part of this chapter.
The C# introduction in the second chapter, Getting Started with C#, is tailored towards people who have at least some proficiency in using an object-oriented language such as C++ or Java. Some differences between C#, Java and C++ are discussed, as well as the differences between value- and reference types, the basics of error handling, working with assemblies and more. Concepts such as classes, methods, inheritance and namespaces are assumed to be known territory. If you have no previous programming experience, Mono: A Developer's Notebook is only useful in combination with a book that teaches programming with C# such as The C# Programming Language by Anders Hejlsberg.
An important part of any modern language is its class libraries. The third chapter, Core .NET, provides an introduction to the standard Framework Library Classes, which describes essential everyday tasks that are part of every program, such as working with files, strings, searching for text patterns and handling collections of data. Besides those basic functions, the chapter also dives deeper into the internals of a compiled assembly, the handling of processes and easy multitasking using threads. Finally, the last paragraph explains how to use a .NET version of the JUnit Java Unit testing framework, Nunit, to test your code.
Developing Gtk-applications with Mono and C# is remarkably easy. Chapter 4, Gtk#, describes the basics of writing Gtk# applications. First, it's neccesary to remark that Gtk# might be a bit of a misnomer. Besides the raw Gtk+ toolkit functionality, Gtk# also includes most of the Gnome libraries like gconf, the gnome canvas, libglade and more. Chapter 4 describes functionality available in the Gtk namespace, the basic Gtk+ toolkit. Gtk+ is a constraints-based toolkit, which means that widgets are not positioned using absolute pixel coordinates but rather on basis of their logical relation to each other. This can be a bit confusing for novices, but this chapter provides a good introduction to the basic principles of writing layouts using Gtk#. The authors provide descriptions of essential operations that almost every application needs, such as creating menus and drawing pixmaps (or more advanced things like using the treeview widget and drag-and-drop), assisted by easy-to-read code snippets.
While chapter 4 introduces basic Gtk# functionality, chapter 5, Advanced Gtk#, delves deeper into more advanced features of the Gtk# library which also include functionality outside of the basic Gtk-namespace, such as the Gnome libraries. Working with Gnome button toolbars, the Glade user interface designer, storing your application settings in Gconf, setting up some preferences through the use of a wizard/druid, asynchronous operations and threading to increase responsiveness of your application while performing background tasks, rendering HTML in your application using the Gecko rendering engine and internationalisation and translation of applications are all described in this chapter.
The use of XML is tightly integrated throughout the Mono framework. It is, for example, the underlying format of the messages that web services use to communicate using the SOAP and XML-RPC protocols. The 6th chapter, Processing XML, describes the XML functionality available in Mono. It starts off by simple operations, reading and writing to an XML-file using relevant examples such as RSS and Dashboard clue-packets. It then proceeds to describe how to modify XML in memory, how to navigate and transform XML using Xpath and XSLT, how to constrain XML in several ways and how to serialize and deserialize objects into and from their XML representation. As in previous chapters, the information density is very high so it might take several reads to grok everything explained. The code examples and accompanying text however are very clear and concise.
The 7th chapter called Networking, Remoting, and Web Services describes the networking functionality available in Mono. The chapter starts off with ASP.NET. Mono's stand-alone XSP webserver and Apache integration with mod_mono are discussed, as well as the basics of writing a web application using ASP.NET's code-behind functionality which enables web applications to completely seperate presentation from the underlying code. Communication using plain tcp/ip, remoting using binary serialized objects and invoking remote procedures using XML-RPC as an alternative to SOAP are also described in this chapter. You might want to encrypt the data you send over the network, so a basic description of the Mono cryptographic API is provided. Finally, a short introduction to database handling using ADO.NET concludes chapter 7.
The 8th and last chapter titled Cutting Edge Mono starts off with an introduction on how to use the GNU Automake, Autoconf and the pkg-config tools to create an easy to build source package of your project. It then proceeds to describe various pitfalls and considerations in case you want to write cross-platform applications using Mono, such as filesystem layout, configuration storage and the calling of native code using p/invoke. A particularly cool project is IKVM, which translates Java bytecode into the Common Intermediate Language bytecode Mono uses. This enables Mono to run Java applications and allows Java and Mono code to inter-operate. A short introduction on the use of IKVM is provided, as well as some code examples on how to call Mono assemblies from Java and use the Java class libraries from within Mono applications. The chapter ends with some other cutting-edge functionality, like how to run a development version of Mono, a preview of the Generics (templates in c++) implementation available as featured in C# 2.0 and how to write Mono programs in Basic.
What is missing? The book doesn't contain a reference section on any of the described API's. If you need detailed information on the C# language specification or an API reference you will need to consult external resources such as the documentation provided with Mono, MSDN, or a separate book covering the topic to make optimal use of the information contained in this book. Fortunately, the book kindly provides pointers on where to find those. The information-density is much higher than you would expect from a book this size. This means the information contained in it is terse. Many topics are treated in a only a couple of pages and the book doesn't take time to explain a lot of programming concepts. The information gets you 'on the road' quickly however, which is exactly what this book is supposed to do.
The strength of this book is that it fills the gap between the earlier-mentioned reference documentation and the need to go out and try to read sourcecode to find out how a particular thing is done. The writing style is clear, concise and neutral. Some topics are clarified by the use of screenshots, which is especially useful in the chapters dealing with Gtk# widgets. All in all, if you are a developer with previous experience in object-oriented programming, Mono: A Developer's Notebook will provide you with an excellent introduction into many of the aspects of working with Mono, its associated libraries and programs.
More information and a sample chapter can be found at the book's homepage.
You can purchase Mono: A Developer's Handbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
It was only a matter of time before O'Reilly used them all up.
1. Why not use Java? 2. Does it run on Linux? 3. Imagine a beowulf cluster of these! 4. Keep up the good work Miguel! 5. Miguel you are a tool! 6. Why not use Java!
Tech, life, family, faith: Give me a visit
For me, Obj-C combined with Cocoa (*Step), is that same sweet spot. And sometimes Python, when a really high-level language is required. Naturally still together with Cocoa through PyObjC.
Am I the only one who immediately thinks of debilitating diseases whenever this project is mentioned?
bug.gd: error search engine. Humanity working together to solve all errors.
I had Mono in 7th grade, it sucked.
Not quite. A better comparison,
.NET is Microsoft's implementation of this standard.
Mono is Novell's implementation of this standard.
On the other hand,
Same standard, 2 different implementations of the standard.
Tech, life, family, faith: Give me a visit
One thing I still haven't been able to figure it is how Mono compares to developing .NET applications on Windows with the Microsoft toolset. Does Mono capture the simplicity of the .NET Framework in building Windows (GUI-based) applications?
Sweet spot? I call it uninteresting void. It seems to me that most programming is either:
1) operating system kernel or core library, embedded or high-performance programming. This niche only finished moving from assembly to C a few years ago. C++ is usually too slow & big & unwieldy for this niche, let alone C# or Java, although we may be ready for it in 5 years or so.
2) application programming. Here development speed is more important than execution speed. Python and kin provide 'good enough' execution speed when coupled with proper libries (QT, etc) with the fastest development speed.
What kind of code falls between the 2? Sure there is some, but is it interesting?
Bryan
one time i thought i had mono for an entire year; but it turned out i was just really bored.
I once thought I was developing Mono for an entire year. Turns out I was just really bored.
Lets look at somne important facts first so we can have an eduated and informed discussion.
.NET, ASP.NET and ADO.NET compatibility layers might run into trouble in the long run because those libraries are patent encumbered.
Mono with the
Mono with GTK#, Gnome, Mozilla and other libraries doesn't have that problem because the only thing that it uses from Microsoft is the ECMA standard C# language implementation.
Why Mono and not Java? Mono is 100% open source.
Why Mono and not Python? Mono uses a virtual machine environment that is faster than an interpreted language. Some people prefer the Java and C++ similarities that C# offers. Mono is cuasi language independent. You can use Python in Mono (See Iron Python).
"Miguel de Icaza is wasting his time..." Miguel works on Mono because he likes it, he is not employed by you (except if you are Novell) so he spends his time as he sees fit. He owes you nothing.
Cheers,
Adolfo
It takes MUCH longer to code a program in Java than C# (business type programs with lots of screens, error checking and database access). Each language has it's place and C# approaches VB for RAD where Java is more like programming in C++ for speed of application development.
If you have questions about Mono, read the project launch statement or visit the list of Frequently Asked Questions.
There's an RSS feed for the newest news, updates, etc. on Mono, too.
You can. Fujitsu implemented a COBOL.NET. It's an abmonination.
Most slashdotters need instructions on the normal way to develop Mono.
What the hell are you talking about? VB.NET has nothing to do with VC++. Neither C# or VB.NET compiles to object code which can be executed directly by the target computer. You should really read up on what youre talking about before posting... And that goes for those who gave you points as well.
I developed mono back in the 7th grade.
C/C++ = Weakly statically typed
Java/C# = Strongly statically typed
Python/Ruby = Strongly dynamically typed
"Loose" typing is another way of saying "weak" typing. Meaning the system doesn't enforce type safety. In almost all scripting languages, type safety is strongly enforced.
A deep unwavering belief is a sure sign you're missing something...
You can run ASP.NET on Linux using Mono, but you cant run it on Windows. You would think there would be a big push to get in working under Apache on Windows since this woulod be the perfect bridge to moving your site to Linux.
"God fights on the side with the best artillery." - Napoleon, Marshal of France - speaking truth to power
Can you use C# without .NET or some replacement for it? Is it possible to use it with POSIX alone? Or perhaps with OpenGL?
I've been writing in Java for 6 years professionally, and been playing with it since I picked up the beta with one of the original programming books in '96ish time frame. Lately I've been playing with C#, and while I don't particularly care for Microsofts business practices, they put out some pretty good development tools. C# is a damn fine language that seems to have learned from the mistakes others have made while taking away the good stuff. Java has way too many things that bug me. Little things here or there. C# pretty much got rid of them. Off the top of my head, overloading operators is a big one for me. I tend to write a lot of mathematical manipulations, and being able to overload the operators to naturally manipulate custom data structures is a huge benefit from my standpoint. I mean if you want to write a method to do it in Java and then have to make explicit method calls feel free... You're stupid, but feel free. I'd rather just work with it naturally. The Java GUI library is crap, and with rare exceptions (sweet sweet firefox) doesn't produce attractive apps. C++ is still my favorite development language, but I don't want to write tons of boilerplate code, deal with messy structure, or have to deal with custom memory managers everytime I write an app. For those who are putting down Mono as some kind of stupid side project, stop stroking your self. I'm a little tired of sysadmins out there who know a little scripting coming off like they are developers. It's a pretty ambitious undertaking for anyone to work on in their spare time. And just because a Microsoft team developed C# doesn't mean it's going to just be a Microsoft development language. The C# spec has been accepted by ISO and anyone can write a C# compiler at this point.
Lately, my interest in the Mono project has been growing. The C# language appears to offer just that sweet spot between power and productivity I've been looking for
Yeah, of course now that there's an open source implementation, C# is a good language...
Beware: In C++, your friends can see your privates!
Mono with GTK#, Gnome, Mozilla and other libraries doesn't have that problem because the only thing that it uses from Microsoft is the ECMA standard C# language implementation.
And the beaut think about that is the *potentially encumbered* libraries are in a different part of the build tree, ready to be pulled if a MS (FUD) patent does get served.
peterrenshaw ~ Another Scrappy Startup
Java and C# are quite different in my view. Java is succesfully entrenched on the server side, while C# looks like it will become quite successful on the desktop.
.NET 1.1 or bundling the runtime with the OS is a tremendous benefit and a magnitude easier than getting end users to install Java. The most important difference, on both Windows and on Linux, is the fact that some application is written in C# won't be broadcasted to the users. You want application "foo", mono gets pulled in a dependency like any other library or runtime. You launch "foo" and the program comes up with a native GTK#/SWF GUI. It's a fundamentally different outlook than with Java, which continually jumps in your face "this app is written in Java!" either explicitly (as if the user gives a damn) or because of the one hundred little things that are off even when using SWT in Eclipse. NET/Mono will just be a dependency, like the VC++ runtime before it and the VB runtime before that. It's a huge cultural difference: "Java Powered!!!1!" vs "I guess it's written in C#... or something." I was playing around with the NASA World Viewer application featured last week on Slashdot, only later did I find out it was written in .NET on this site. There's just no way to tell.
.NET specific container. You'll install the software exactly as you always have, for example by using RPMs via apt-get or yum. It might seem like a small detail, but it's actually a huge deal from the end users point of view because nothing changes. On a pristine installation of Fedora I issue "yum install monodevelop" and then "monodevelop" and lo and behold the app starts. Mono does its work quietly in the background, something Java has never achieved.
To date Java has produced exactly two good desktop applications, Eclipse and Azureus. It's an abysmal failure, and the associated stigma won't disappear anytime soon.
Telling users to go to Windows update and pull down
Mono apps on Linux or Windows won't come in some funky
The JRE is an alien piece of software in Linux land. Even after you install the official RPM "java" produces a "java: command not found". Even as a developer I don't want to deal with that sort of shit these days if it can just be automated. There's just been no thought given to end user experience and it shows throughout the whole platform.
All these points make Java a horrible system for desktop Linux apps, and Mono on par with existing systems. Then when you add in all the niceties of working in a managed language, you've got to at least give Mono a good look when deciding what to use for your next Linux app.
Mono's 100% open source. Dismissing it right from the start just because it has its origins with MS is just stupid. The situation is completely analogous to MS SMB vs Samba. Even in an all Linux shop you're likely to find Samba in use because, frankly, NFS for the longest time has been a real piece of shit and is only recently worth using on Linux.
It's like deja vu all over again.
no elite or FUD here, but if you read the specs for the java vm found in pre-1.4 it indeed uses a 32 bit address space for its internal pointers. IBM and Sun have released the 64 bit (internal) JVM, but I've yet to hear they are production grade. You might also be interested to know that while Sun boxes with UltraSparc 1 chips were 64 bit capable, the Solaris 2.5 and 2.6 were not true 64 bit OS (I have an Ultra 170e which triple boots 2.6, 7 and 8, btw). Not until Solaris 8 (which includes both 32 and 64 bit kernel you have the choice of booting) did they get *most* of the 64 bit issues ironed out, and you can read all about the remaining problems in their online doc site.
I have to say it. C# does rock and I'm so happy about Mono doing so well.
.NET framework that are clearly hacked together just to make it work. Others were clearly designed by developers with very little understanding of object oriented development principles.
There are mistakes in how the C# language has been designed that really bug me at times, but I've been developping in C# for about 2 years now and I've never been so productive in my life.
It has a lot of the advantages of Java, but with a better UI (and by better, I mean better looking AND better performance. The Java ones seem to be one or the other: Fast and Ugly or Slow and Pretty, and maybe even some slow and ugly ones).
I really hope Mono can keep up with the Longhorn development because I really expect the library design to be better. There are a lot of aspects of the
But complaints aside, overall it's excellent and as I said, I've never been so productive! As an independent contractor, that means a lot to me.
C# is better than Java in almost every way:
You may hear about these "features" from pro-CLR people:
The only advantages the Java language has (that I can think of) are:
It's true that C# is mostly copied from Java. They didn't add any novel ideas. They just improved it incrementally (and screwed up a little too). But after everything is accounted for, it's clearly a better language. You can talk about "maturity" and "industry support" all you want, but some people are just happy to be using a superior language.
BTW, both "maturity" and "industry support" wont be problems for C#. It's not hard to design a mature language and set of class libraries when you have a working example to learn from. Also, Microsoft has mature designers working on the CLR and that counts for something too. As for "industry support", you have got to be joking. When they make the CLR come pre-installed on Longhorn, it will instantly become an industry standard. Even now it's available directly through Windows Update. The whole XAML/Avalon thing is not even ready yet but Amazon.com has already used it to build a prototype. It's depresing, but true: anything that comes out of Microsoft will have a completely unfair advantage over any competing products. Macromedia is next.