The Mono Handbook - About

The Mono Handbook > About

The Mono Handbook, 0.1

This document is maintained in mono cvs, module "monkeyguide".
It's released under the GNU Free Documentation License.

The Mono Handbook | Mono Homepage | Credits | License


The Mono Handbook - Contributing

The Mono Handbook > Contributing

DocWriters: There are lots of things to do:

  • C# tutorial
  • NAnt
  • Basic classes documentation
  • Adavanced classes documentation
  • Many parts in Gnome.NET area.
If you want to contribute, please drope me a note. ( johannes@jroith.de )

To avoid duplication, if you want to contribute first look if somebody else already has taken this chapter.

The Mono Handbook is available in mono cvs, module "monkeyguide"
or at http://www.go-mono.org/monkeyguide.

The Mono Handbook | Mono Homepage | Credits | License


The Mono Handbook

Preface
About this document
Contributing
Target audience

PART 1 - Introduction

CHAPTER 1 - Mono

  • 1.1 What is .NET?
  • 1.2 What is Mono?

CHAPTER 2 Architecture

  • 2.1 .NET Framework Architecture
  • 2.2 Mono Implementation
  • 2.3 Comparing Mono and the .NET Framework
  • 2.4 Mono enabled platforms

PART 2 - Installing Mono

CHAPTER 3 Getting Started

  • 3.1 Installation overview & considerations
  • 3.2 Choosing an Integrated Development Environment (IDE)

CHAPTER 4 Installation

  • 4.1 Linux
  • 4.2 Windows
  • 4.3 MacOS X
  • 4.4 FreeBSD

CHAPTER 5 Configuring the IDE

  • 5.1 Emacs
  • 5.2 Eclipse
  • 5.3 #Develop

PART 3 - Using Mono

CHAPTER 6 Runtime Environment

  • 6.1 Introduction
  • 6.2 Using Mono
  • 6.3 Using Mint

CHAPTER 7 C# & VB Compiler

  • 7.1 Introduction
  • 7.2 Using the C# compiler
  • 7.3 Using the VB.NET compiler

CHAPTER 8 Assembler & Disassembler

  • 8.1 Introduction
  • 8.2 Mono Disassembler
  • 8.3 Mono Assembler

CHAPTER 9 Other Tools

  • 9.1 Useful tools: NUnit, NAnt, and NGen
  • 9.2 MonoDoc
  • 9.3 The Mono debugger

PART 4 - Developing Applications with Mono

CHAPTER 10 Mono programming languages

  • 10.1 C#
  • 10.2 Basic.NET

CHAPTER 11 Streams & Files

  • 11.1 Introduction
  • 11.2 Read / Write Textfiles
  • 11.3 Read / Write Binary Files

CHAPTER 12 Collections / Dynamical Arrays

  • 12.1 The ArrayList
  • 12.2 BitArray

CHAPTER 13 Math

  • 13.1 Collections
  • 13.2 Text
  • 13.3 RegularExpressions

CHAPTER 14 Others

  • 14.1 Console Class
  • 14.2 Enviroment Information
  • 14.3 Controlling the Garbage Collector
  • 14.4 Text
  • 14.5 RegularExpressions

PART 5 - Using advanced technologies

CHAPTER 15 Threading

  • 15.1 Introduction
  • 15.2 Start & Stop threads
  • 15.3 Syncronisation

CHAPTER 16 Remoting support in Mono

  • 16.1 Introduction
  • 16.2 Remoting tutorial
  • 16.3 Examples
  • 16.4 References

CHAPTER 17 Component Interoperability

  • 17.1 Windows COM
  • 17.2 Gnome Bonobo

CHAPTER 18 XML

  • 18.1 Introduction
  • 18.2 XPath tutorial
  • 18.3 Xml DOM (XmlDocument)
  • 18.4 Xsl transformations

CHAPTER 19 ADO.NET

  • 19.1 Introduction
  • 19.2 Databases supported by Mono
  • 19.3 Programming with ADO.NET
  • 19.4 Tools
  • 19.5 Code Examples

PART 6 - Developing GUI Applications with Mono

CHAPTER 20 System.Windows.Forms

  • 20.1 Introduction
  • 20.2 Cross-platformness
  • 20.3 S.W.F Tutorial

CHAPTER 21 GNOME.NET - A much needed room to breathe

  • 21.1 Introduction
  • 21.2 Installation
  • 21.3 GNOME.NET Tutorials
    • Gtk#
    • Gnome#
    • Glade#
    • GConf#
    • Gda#
    • Gnome-db#
    • GStreamer#
    • Rsvg#
  • 21.4 Same Gnome - a Case
  • 21.5 GNOME.NET Documentation
  • 21.6 GNOME.NET FAQ

CHAPTER 22 QT#

  • 22.1 Introduction
  • 22.2 Installation
  • 22.3 C# bindings
  • 22.4 Qt# Documentation
  • 22.5 QT# FAQ

PART 7 - Mono Web technology

CHAPTER 23 Creating ASP.NET WebPages

  • 23.1 Introduction
  • 23.2 Comparing ASP.NET to other WebPage technologies
  • 23.3 Installation
  • 23.4 Programming with ASP.NET
  • 23.5 Programming for mobile devices

CHAPTER 24 Creating ASP.NET Web Services

  • 24.1 Introduction
  • 24.2 What is a WebService?
  • 24.3 Introduction to SOAP
  • 23.4 The Mono/ASP.NET SOAP implementation

PART 8 - Misc

CHAPTER 25 Embedding Mono

  • 25.1 Embedding in C
  • 25.2 Embedding in Perl

CHAPTER 25 Cross Platform Development

  • 26.1 Introduction
  • 26.2 Fast Cross-platform GUI
  • 26.3 10 rules to be cross-platform and .NET compatible

APPENDICES

  • A Code Samples used in the document
  • B Sample Applications
  • C Presentations
  • D Recommened Reading
  • E Links to other Resources
  • F FAQ
  • G Ecma Standards
  • H License
  • I Credits

The Mono Handbook | Mono Homepage | Credits | License


The Mono Handbook - Preface

The Mono Handbook > Preface

The Mono Handbook is a collection of guides and tutorials, that might help you to get started with mono. It covers the mono runtime, the C# language, tools like the debugger, certain parts of the class library, the Database layer ADO.NET, and the WebSite Framework ASP.NET, as well as GTK#. It is not meant as a complete documentation.

How to read this guide

You can read from the beginning to the end or you can skip around from topic to topic, no problemo.

The Mono Handbook | Mono Homepage | Credits | License


The Mono Handbook - Contributing

The Mono Handbook > Contributing

Monekyguide aims to target:

  • people comming from Windows, who know .NET and want to get known to the mono tools
  • people comming from Windows, who want to program Gnome 2 applications
  • people swiching from another language (C, Java, etc.)
  • newbie programmers, that want to learn coding

No matter how much you already know, this guide is for you. Experienced people can always skip boring chapters.

The Mono Handbook | Mono Homepage | Credits | License


The Mono Handbook - Working with ADO.NET...

The Mono Handbook > Working with ADO.NET...

Working with ADO.NET - Universal Database Access for mono

Contents

  • 1. Supported Databases
  • 2. Credits

I. Supported Databases

While Microsoft ships ADO.NET providers for MS SQL Server, SqlXML, OLE DB and - since 1.1 - ODBC and Oracle in the namespace System.Data, Mono is far ahead MS here. Besides the providers in System.Data, in the namespace Mono.Data currently holds providers for:
  • Postgres
  • MySQL
  • SqlLite
  • Sybase
  • TDS Generic
Mono's OLE DB implementation, based on LibGDA, has additonally support for (and others already listed):
  • Interbase
  • IBM DB2
  • MS Access
If your favorite Database is not listed here, on Unix Systems unixodbc can handle these (and others already listed) with appropriate Drivers:
  • Easysoft ODBC-ODBC Bridge
  • StarSQL
  • Informix
  • AdabasD
  • Empress
  • miniSQL
  • SQI
  • miniSQL
  • News Server
  • YARD SQL
  • RDBMS Linter SQL
  • Ovrimos Webbase
  • Mimer SQL
  • Ingres
  • SAPdb
Also more providers are planned:
  • DB2 (directly)
  • miniSQL
  • SapDB
  • BerkeleyDB
  • Firebird/Interbase
7 Databases direct and 18 indirect should be enough for all your database needs. Some of these providers require native libaries, but most will be pure C#, as development goes on. All providers share a common interface, so it's relatively easy to port from one DB to another. [TODO]

A. Credits

Authors: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - Working with ADO.NET...

The Mono Handbook > Working with ADO.NET...

Working with ADO.NET - Universal Database Access for mono

Examples

A. Credits

Authors: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - Working with ADO.NET...

The Mono Handbook > Working with ADO.NET...

Working with ADO.NET - Introduction

Introduction

The .NET framework ships with a namespace, System.Data, that is not part of the ECMA class library. Mono has implemented it however. This namespace is also often called with it's marketing term "ADO.NET". The name commes from ADO, the ActiveX Data Objects, Microsofts latest Database layer. ADO.NET builds on top of it, partially. The mono implementation does not.

ADO.NET is an API to access Data sources of any kind, but especially relational Databases.

Microsoft ships the .NET Framework with Database providers for MS SQL Server, Oracle, ODBC, Ole-DB and XML.
Mono does ship all of these, but additionally native providers for MySQL, PostgreSQL, and IBM DB2.

Those Databases not available directly can be accessed through either ODBC or OLE-DB. Both are implemented on Windows and Unix systems. All those databases share a common interface, that makes them easy to use, and speeds up porting. There is also a xml provider, that enables you to access xml files as a database.

This chapter will look at the databases available, differences in the providers, how to install & program with it and will give you some examples.

A. Credits

Authors: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - Working with ADO.NET...

The Mono Handbook > Working with ADO.NET...

Working with ADO.NET - Universal Database Access for mono

by Johannes Roith (johannes@jroith.de)

Contents

  • 1. What is a Database
  • 2. My choice: MySQL
  • 3. Installation & First Steps with MySQL
    • 3.1 Installation on Windows
    • 3.2 Installation on Linux
  • 4. Database Design
    • 4.1 Database Theory
      • 4.2.1 Normal Forms
      • 4.2.2 Relations
    • 4.3 Primary Key & Foreign Key
    • 4.4 Data Types
    • 4.5 Indizes
  • 5. Learning SQL
    • 5.1 Simple SELECTs
    • 5.2 SELECT Data from relational Databases
    • 5.3 Editing Data
    • 5.3.1 INSERT
    • 5.3.2 UPDATE
    • 5.3.3 DELETE
    • 5.4 Advanced SQL
  • 5. Monos Database layer
    • 5.1 Connecting to the Database
    • 5.2 Explanaition of various classes
  • 6. Programming a book database
  • 7. SQL-Reference

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - Working with ADO.NET...

The Mono Handbook > Working with ADO.NET...

Working with ADO.NET - Universal Database Access for mono

IV. Tools

SQL# CLI

A command-line tool written in C# to execute SQL commands, test connection strings, and connect to various ADO.NET providers in Mono. The SQL# CLI can be found in mcs/tools/SqlSharp/SqlSharpCli.cs

This can be quite useful, to check if you have errors in your code, or it's a problem with the database. That's all, that can be sayed about it.

A. Credits

Authors: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - Resources

The Mono Handbook > Resources

Credits

Maintainers

Johannes Roith
Martin Willemoes Hansen

Authors

Johannes Roith
Martin Willemoes Hansen
Alejandro Sánchez Acosta
Pablo Baenay
Felix Faassen
Cesar Octavio Lopez Nataren
Norman Lorrain

Translators

Luyan

The Mono Handbook | Mono Homepage | Credits | License


The Mono Handbook - ECMA

The Mono Handbook > ECMA

ECMA Documentation.

You can get the documentation for the ECMA specs from:

  • C# Language Specification
  • Common Language Infrastructure

Older copies of the standard are available here:

  • At MSDN
  • Dot Net Experts
  • Intel
  • Monash University

These contain specifications for the assembler, the metadata, byte codes supported by the CLI virtual machine, the C# language and the core class libraries.

For details on the .NET class libraries, you can visit the Microsoft's Developer Network:

  • .NET Framework Class Library

The Mono Handbook © Copyright 2002 by Johannes Roith


The Mono Handbook - FAQ

The Mono Handbook > FAQ

Mono FAQ

From Mono Homepage. This document should be synced from time to time.

Contents

  • Basics
  • The Ximian Role in the Mono project
  • Mono and GNOME
  • Building GUI applications with Mono
  • Mono and Microsoft
  • Mono platforms
  • Mono and the Portable.NET Project
  • Web Services
  • Mono and ASP.NET
  • Mono and ADO.NET
  • MonoDoc
  • Development Tools and Issues
  • Mono and Java
  • Extending Mono
  • Portability
  • Reusing Existing Code
  • Mono and GCC
  • Performance
  • Licensing
  • Patents
  • Miscellaneous Questions
  • Mono Common Problems
  • A. License: GNU Free Documentation License

A Spanish translation is also available

Basics

Question 1: What is Mono exactly?

The Mono Project is an open development initiative sponsored by Ximian that is working to develop an open source, Unix version of the Microsoft .NET development platform. Its objective is to enable Unix developers to build and deploy cross-platform .NET Applications. The project will implement various technologies developed by Microsoft that have now been submitted to the ECMA for standardization.

Question 2: What is the difference between Mono and the .NET Initiative?

The ".NET Initiative" is a somewhat nebulous company-wide effort by Microsoft, one part of which is a cross-platform development framework. Mono is an implementation of the development framework, but not an implementation of anything else related to the .NET Initiative, such as Passport, software-as-a-service, or corporate re-branding.

Question 3: What technologies are included in Mono?

Mono contains a number of components useful for building new software:

  • A Common Language Infrastructure (CLI) virtual machine that contains a class loader, Just-in-time compiler, and a garbage collecting runtime.

  • A class library that can work with any language which works on the CLR.

  • A compiler for the C# language. In the future we might work on other compilers that target the Common Language Runtime.

Windows has compilers that target the virtual machine from a number of languages: Managed C++, Java Script, Eiffel, Component Pascal, APL, Cobol, Perl, Python, Scheme, Smalltalk, Standard ML, Haskell, Mercury and Oberon.

The CLR and the Common Type System (CTS) enables applications and libraries to be written in a collection of different languages that target the byte code

This means for example that if you define a class to do algebraic manipulation in C#, that class can be reused from any other language that supports the CLI. You could create a class in C#, subclass it in C++ and instantiate it in an Eiffel program.

A single object system, threading system, class libraries, and garbage collection system can be shared across all these languages.

Question 4: Where can I find the specification for these technologies?

You can find the information here:

C# http://www.ecma.ch/ecma1/STAND/ecma-334.htm

CLI http://www.ecma.ch/ecma1/STAND/ecma-335.htm

Question 5: Will you implement the .NET Framework SDK class libraries?

Yes, we will be implementing the APIs of the .NET Framework SDK class libraries.

Question 6: Will you offer an ECMA-compliant set of class libraries?

Eventually we will. Our current focus is on inter-operating with the Microsoft SDK, but we will also offer an ECMA compliant set of libraries.

Question 7: What does the name "Mono" mean?

Mono is the word for `monkey' in Spanish. We like monkeys.

Question 8: Is Mono usable?

The JIT engine is usable on Intel x86 machines. An interpreter can be used on other non-Intel x86 machines.

The class libraries are mature enough to run some real applications (the compiler for instance, and every day more and more applications are natively developed with Mono).

Question 9: When will you ship it?

Different parts of Mono will achieve usability at different stages, once we are comfortable with the compiler, we will release "Mono Core", which contains everything needed to develop applications with the base class libraries, this will happen soon and in the meantime you can download daily snapshots of our work. Also the full ASP.NET support is close to completion.

Other higher level class libraries (ASP.NET, ADO.NET, WinForms) will be released when they become stable.

Question 10: What major components will you include in Mono?

Hopefully everything that Microsoft ships on their Framework (ADO.NET, ASP.NET, WinForms), and we encourage third party developers to create reusable components that work on both Mono and Windows.

Question 11: How can I contribute?

Check the contributing section.

Question 12: Aren't you just copying someone else's work?

We are interested in providing the best tools for programmers to develop applications for Free Operating Systems. We also want to help provide the interoperability that will allow those systems to fit in with other standards.

For more background, read the Mono Project white paper. the project.

Question 13: Miguel said once that Mono was being implemented in COBOL. Is that true?.

No. It was a joke.

The Ximian Role in the Mono Project

Question 14: Why is Ximian working on .NET?

Ximian is interested in providing the best tools for programmers to develop applications for Free Operating Systems.

For more information, read the project rationale page.

Question 15: Will Ximian be able to take on a project of this size?

Of course not. Ximian a supporter of the Mono project, but the only way to implement something of this size is for the entire free software community to get involved. Visit the contributing page if you'd like to help out.

Question 16: What pieces will Ximian be working on?

We will devote most of our resources to work on the pieces which are on the critical path to release a development and execution environment. Once the project is at a stage where it is useful in the real world, it will achieve a critical mass of developers to improve it further.

Question 17: Will Ximian offer Mono commercially?

When Mono is ready to be shipped Ximian will offer a commercial support and services for Mono.

Question 18: Does Ximian provide consulting services around Mono?

Yes, Ximian does provide consulting services around Mono to make it suitable to your needs. Porting the runtime engine, customizing it, working on specific classes or tuning the code for your particular needs.

Question 19: Will you wait until Mono is finished?

Mono will ship on various stages as they mature. Some people require only a subset of the technologies, those will ship first.

More advanced features will take more time to develop. A support time line will be available in June 2002.

Mono and GNOME

Question 20: How is Mono related to GNOME?

In a number of ways. This project was born out of the need of providing improved tools for the GNOME community, and will use existing components that have been developed for GNOME when they are available. For example, we plan to use Gtk+ and Libart to implement Winforms and the Drawing2D API and are considering GObject support.

Question 21: Has the GNOME Foundation or the GNOME team adopted Mono?

Mono is too new to be adopted by those groups. We hope that the tools that we will provide will be adopted by free software programmers including the GNOME Foundation members and the GNOME project generally.

Question 22: Should GNOME programmers switch over to Mono now?

It is still far to early for discussions of "switching over." No pieces of Mono will be ready within the next six months, and a complete implementation is roughly one year away.

We encourage GNOME developers to continue using the existing tools, libraries and components. Improvements made to GNOME will have an impact on Mono, as they would be the "back-end" for various classes.

Question 23: Will Mono include compatibility with Bonobo components? What is the relationship between Mono and Bonobo?

Yes, we will provide a set of classes for implementing and using Bonobo components from within Mono. Mono should allow you to write Bonobo components more easily, just like .NET on Windows allows you to export .NET components to COM.

Question 24: Does Mono depend on GNOME?

No, Mono does not depend on GNOME. We use a few packages produced by the GNOME team like the `glib' library.

Question 25: But will I be able to build GNOME applications?

Yes, we will enable people to write GNOME applications using Mono.

Question 26: Do you have C# bindings for GNOME?.

Yes, we currently bind libgnome, libgnomecanvas, and libgnomeui -- although I dare say I have no idea how functional the bindings are outside of what I tested in the sample app. I imagine other libraries under the GNOME framework will be added on an as-needed (and as-requested) basis...although a truly good bonobo binding will have to wait on the CORBA remoting support which has been started recently.

GUI applications

Question 27: Will Mono enable GUI applications to be authored?

Yes, you will be able to build GUI applications. Indeed, that is our main focus. We will provide both the Windows.Forms API and the Gtk# API.

Question 28: What is the difference between Gtk# and System.Windows.Forms?

Gtk# is a set of bindings for the Gtk+ toolkit for C# (and other CIL-enabled languages). System.Windows.Forms is an API defined by Microsoft to build GUI applications.

Question 29: Will I be able to run my smart clients on systems powered by Mono?

As long as your applications are 100% .NET and do not make use of P/Invoke to call Win32 functions, your smart client applications will run on Mono platforms.

Question 30: Where can I learn more about Gtk#?

The following Question 31: What can I do with Gtk#?.

Gtk# is becoming very usable and you can create applications and applets like those you see in a GNOME desktop environment. It's easy to install so it's worth a try.

Question 32: How can I compile my HelloWorld.cs which uses Gtk#?.

Try: mcs --unsafe -o HelloWorld.exe -r glib-sharp -r pango-sharp -r atk-sharp -r gdk-sharp -r gtk-sharp -r gdk-imaging-sharp HelloWorld.cs

Question 33: Is there any way how to connect DataAdapter to some GTK# controls?

There is a sample file called `DbClient' in gtk-sharp/samples that you might to look at. It is a sample program in Gtk# that adds/updates/deletes information on a Postgress database. When we have the new table/tree widgets, I am sure someone would write an adapter for System.Data (in Gtk2 the tree/list widgets are written using a view/model, so you only need to write a model that maps to the database). You can have a look at gtk-sharp/sample/DbClient, where there is a GTK# application that uses System.Data. It does not use DataAdapter, but DataReader though.

Question 34: Do you have an estimate for when Windows.Forms will be released?

We do not know, volunteers are working on this, but there is no set date yet. The current approach is using the Wine Library to implement it.

Mono and Microsoft

Question 35: Is Microsoft helping Ximian with this project?

There is no high level communication between Ximian and Microsoft at this point, but engineers who work on .NET or the ECMA groups have been very friendly, and very nice to answer our questions, or clarify part of the specification for us.

Microsoft is interested in other implementations of .NET and are willing to help make the ECMA spec more accurate for this purpose.

Ximian was also invited to participate in the ECMA committee meetings for C# and the CLI.

Question 36: Is Microsoft or Corel paying Ximian to do this?

No.

Question 37: Do you fear that Microsoft will change the spec and render Mono useless?

No. Microsoft proved with the CLI and the C# language that it was possible to create a powerful foundation for many languages to inter-operate. We will always have that.

Even if changes happened in the platform which were undocumented, the existing platform would a value on its own.

Question 38: Are you writing Mono from the ECMA specs?

Yes, we are writing them from the ECMA specs and the published materials in print about .NET.

Question 39: If my applications use Mono, will I have to pay a service fee?

No. Mono is not related to Microsoft's initiative of software-as-a-service.

Question 40: Is the Mono Project is related to the Microsoft Hailstorm effort? Is Ximian endorsing Hailstorm?

No. The Mono Project is focused on providing a compatible set of tools for the Microsoft .NET development platform. It does not address, require, or otherwise endorse the MS Passport-based Hailstorm single sign-on system that is part of Windows XP and other services.

Question 41: Will Mono or .NET applications depend on Microsoft Passport?

No. MS Passport is unrelated to running .NET compatible applications produced with the Mono tools. The only thing you will need is a just-in-time compiler (JIT).

Question 42: What is a 100% .NET application?

A `100% .NET application' is one that only uses the APIs defined under the System namespace and does not use PInvoke. These applications would in theory run unmodified on Windows, Linux, HP-UX, Solaris, MacOS X and others.

Question 43: If Microsoft will release a port of their .NET platform under the `Shared Source' license, why should I bother with anything else?

The Shared Source implementation will be expensive and its uses will be tightly restricted, especially for commercial use. We are working towards an implementation that will grant a number of important rights to recipients: use for any purpose, redistribution, modification, and redistribution of modifications.

This is what we call Free Software

Question 44: Is Mono a free implementation of Passport?

No. Mono is just a runtime, a compiler and a set of class libraries.

Question 45: Will the System.Web.Security.PassportIdentity class mean that my software will depend on Passport? No. Applications may use that API to contact a Passport site, but are not required to do so.

As long as your application does not use Passport, you will not need Passport.

Question 46: Will Mono running on Linux make Passport available for Linux?

No. However, the Passport toolkit for Linux-based web servers is available from Microsoft.

Question 47: Will Mono allow me to run Microsoft Office on Linux?

No, it will not. Microsoft Office is a Windows application. To learn more about running Windows applications on Intel Unix systems refer to the Wine Project.

Question 48: Will I be able to compile a Microsoft VB.NET application and execute the resultant MSIL file under MONO on Linux without converting to C# and recompiling?

Once we have a complete VisualBasic runtime, yes.

Question 49: Can mono run the WebMatrix?

No. That requires System.Windows.Forms support which is not currently implemented.

Question 50: Does mono have something like Passport? Will mono have a server side Passport/Similar framework for XSP as well as client classes?

Not yet, but the client side API for authentication is not the problem. We will likely have a lot of other authentication APIs, like the Liberty Alliance APIs. The problem is people on the web provider end that might use this for authentication.

Mono Platforms

Question 51: What operating systems does Mono run on?

Mono is known to run on Linux, Unix and Windows systems.

Question 52: What architectures does Mono support?

Mono today ships with a Just-in-Time compiler for x86-based systems. It is tested regularly on Linux, FreeBSD and Windows (with the XP/NT core).

There is also an interpreter, which is slower that runs on the s390, SPARC and PowerPC architectures.

Question 53: Can Mono run on Windows 9x, or ME editions?

Mono requires Unicode versions of Win32 APIs to run, and only a handful of *W functions is supported under Win9x.

There is Microsoft Layer for Unicode that provides implementation of these APIs on 9x systems.

Unfortunately it uses linker trick for delayed load that is not supported by ld, so some sort of adapter is necessary. You will need MSLU and one of the following libs to link Mono to unicows.dll http://mono.eurosoft.od.ua/files/unimono.zip or alternatively search the net for "libunicows".

No changes to Mono source code required, the only thing is to make sure that linker will resolve imports to adapter library instead of Win32 libs. This is achieved by inserting -lunimono before -lkerner32/user32 in the linker's specs file.

Mono and Portable.NET

Question 54: What are the differences between Mono and Portable.NET?

Most of Mono is being written using C#, with only a few parts written in C (The JIT engine, the runtime, the interfaces to the garbage collection system).

It is easier to describe what is unique about Mono:

  • A Just-in-Time compiler engine. This is important for making your applications fast.

  • A self-hosting C# compiler written in C#, which is clean, easy to maintain.

  • Focus on the .NET Framework: we are tracking down the .NET Framework API definition, as we believe it is the API people will be most familiar with.

  • A multi-platform runtime engine: both a JIT engine and an interpreter exist. The JIT engine runs currently on x86 systems, while the interpreter works on SPARC, StrongARM, s390 and PowerPC systems.

  • Supports Linux, Windows and Solaris at this point.

  • The JIT engine is written using a portable instruction selector which not only generates good code (we are told that we are faster than Rotor, but it is hard to tell) but is also the foundation to re-target the JIT engine to other systems.

    The system employed is described in various compiler books and it is very similar to what is described in the book that covers LCC, the ANSI C retargetable C compiler.

  • The JIT engine supports in-lining, constant folding and propagation,

  • Full support for remoting in the runtime, but the class libraries are still behind.

  • The C# compiler, the JIT engine and the class libraries are mature enough that the whole system is self-hosting. This means that we develop Mono completely with itself at this point.

  • We are not yet done, and there is a lot of work left to be done

  • We have a great community of developers, without which Mono would not be possible.

  • We are working on an ahead of time compilation mode to pre-compile code for the target architecture (this is part of our new code generation effort).

Web Services

Question 55: How is Mono related to Web Services?

Mono is only related to Web Services in that it will implement the same set of classes that have been authored in the .NET Framework to simplify and streamline the process of building Web Services.

But most importantly, Mono is an Open Source implementation of the .NET Framework.

Question 56: Can I author Web Services with Mono?

You will be able to write Web Services on .NET that run on Mono and vice-versa.

Question 57: If Mono implements the SDK classes, will I be able to write and execute .NET Web Services with it? Yes. When the project is finished, you will be able to use the same technologies that are available through the .NET Framework SDK on Windows to write Web Services.

Question 58: What about Soup? Can I use Soup without Mono?

Soup is a library for GNOME applications to create SOAP servers and SOAP clients, and can be used without Mono. You can browse the source code for soup using GNOME's Bonsai.

Question 59: Can I use CORBA?

Yes. The CLI contains enough information about a class that exposing it to other RPC systems (like CORBA) is really simple, and does not even require support from an object.

We will be implementing CORBA inter-operation as an extension to the Mono classes so that we can integrate with Bonobo, just like Microsoft provides COM inter-operation classes and support mechanisms.

Question 60: Can I serialize my objects to other things other than XML?

Yes, although the serializing tools have not yet been planned, and you would probably have to implement them yourself.

Question 61: Will Mono use ORBit?

No. Mono will be using a new implementation of CORBA that isn't still started.

MonoDoc

Question 62: What is MonoDoc?

MonoDoc is a graphical documentation editor and viewer. Currently, MonoDoc consists of a Gtk# application and is in heavy development. There is also a Qt# version of it.

Development Tools and Issues

Question 63: Will it be possible to use the CLI features without using byte codes or the JIT?

Yes. The CLI engine will be made available as a shared library. The garbage collection engine, the threading abstraction, the object system, the dynamic type code system and the JIT will be available for C developers to integrate with their applications if they wish to do so.

Question 64: Will you have new development tools?

With any luck, Free Software enthusiasts will contribute tools to improve the developer environment. These tools could be developed initially using the Microsoft implementation of the CLI and then executed later with Mono.

Question 65: What kind of rules make the Common Intermediate Language useful for JITers?

The main rule is that the stack in the CLI is not a general purpose stack. You are not allowed to use it for other purposes than computing values and passing arguments to functions or return values.

At any given call or return instruction, the types on the stack have to be the same independently of the flow of execution of your code.

Question 66: Is it true that the CIL is ideal for JITing and not efficient for interpreters?

The CIL is better suited to be JITed than JVM byte codes, but you can interpret them as trivially as you can interpret JVM byte codes.

Question 67: Isn't it a little bit confusing to have the name of "XSP" (the same as in the Apache Project) for the ASP.NET support in Mono?.

In Mono, xsp is just the name of the C# code generator for ASP.NET pages. In the Apache Project, it is a term for the "eXtensible Server Pages" technology so as they are very different things, they don't conflict.

Question 68: What about using something like Jabber instead of the System.Messaging namespace?.

In short, MSMQ is not something like Jabber, but asynchronous messaging through queues. Useful queues do more than serialize messages, they are also platform bridges.

Question 69: Are you supporting XMLDocument and relatives?.

Currently, we aren't implementing them yet. It would require updates to most of the XmlNode derivatives so it's not a trivial task. We are currently focusing on getting XPath support working.

Question 70: Is there any plan to develop an aspx server for Mono?.

The web server turned out to be very simple compared to the rest of the work. Gonzalo has got the page generator mostly done (a module called xsp, who has nothing to do with the XSP term used in the Apache Project). Patrik has done a lot of the work to get the ProcessRequest to work. You can try to help in the final touches to the System.Web classes and writing regression tests for the widgets we have.

Question 71: Is there any way I can develop the class libraries using Linux yet?

Yes. Some class libraries can be developed on Linux. Search for Paolo's post (he lists which classes can be compiled fine now).

Question 72: Is there any way I can install a known working copy of mono in /usr, and an experimental copy somewhere else, and have both copies use their own libraries? (I'm still not very good at library paths in Linux)

Yes. Just use two installation prefixes.

Question 73: How should I write tests or a tests suite?

If you do a test suite for C#, you might want to keep it independent of the Mono C# compiler, so that other compiler implementations can later use it.

Question 74: Would it be too terrible to have another corlib signed as mscorlib?

We rename corlib to mscorlib also when saving the PE files, in fact, the runtime can execute program created by mono just fine.

Question 75: Is there a relatively straightforward way to repeat the steps taken by Paolo to get Mono completely self-hosted on Linux?

To build the compiler and class libraries in Linux, run:

  • make -f makefile.gnu. To install them, run:
  • make -f makefile.gnu install prefix=/opt/mono

If you want to produce and distribute a monocharge tarball, run: make -f makefile.gnu dist Of course you have to run these in the top level mcs directory.

Question 76: Is it possible to build a C# file to some sort of intermediate format which can linked into a final module, like the traditional .c -> .o -> .so path? You could do: mcs /target:module file1.cs, mcs /target:module file2.cs, mcs /target:exe file1.dll file2.dll /out:mybin.exe

Question 77: Is there any plans for implementing remoting in the near future?, When will work in System.Runtime.Remoting.dll start?

The remoting infrastructure is in place. Some of the channels and formatters are not.

Question 78: I'm wondering if there are any plans to start using nant to build the class lib + test lib. i think that every project need/should use an automated build process and nant + a couple of tools enables this. is the problem that the compiler can't run nant yet?

Maybe well be doing some sort of automated build process + testing when the summer finish.

Mono and ASP.NET

Question 79: Is Mono supporting ASP.NET?

Yes. The development of the support for ASP.NET comes in various stages, here is what Gonzalo has been working on: 1. The Parser. 2. Getting the parser to generate output compatible with ASP.NET. 3. Running the sample output with the real Microsoft runtime but using our generated page. 4. Running the sample with our classes with the .NET runtime. 5. Running our sample code with our classes with our runtime. This is the process we are following. Currently Gonzalo has reached point 5.

Question 80: Do I need install cygwin to work on ASP.NET in mono or Linux is enough since it is self host right now.

Linux is enough.

Question 81: Any plan to make ASP.NET in mono works with Apache in Linux?.

Yes, we have plans to do so, but we need to wait for Patrik's patches to HttpRuntime. Once that is there, writing a mod_mono should be trivial (look at mono/samples/embed for a sample embedded application).

Mono and ADO.NET

Question 82: What is the status of ADO.NET support?. Could I start migrating applications from MS.NET to Mono?.

You could start right now using the ADO.NET support in mono, of course, if you want to help filling the missing gaps while you develop your app :-) Well, what I mean is that we're not that far to having full ADO.NET support in Mono, and we've got a lot of working things, so if we could get more help, we'd finish it really soon :-)

Question 83: In developing the data architecture for the application are there and objects I should stay away from in order to insure the smoothest possible transition (minimum code rewrite) to Mono's ADO.NET implementation? (For example, strongly typed datasets versus untyped datasets, etc...)

We are implementing all the classes in Microsoft .NET's System.Data, so you can be sure that things will work the same in Mono as with the Microsoft implementation.

Question 84: Does Mono can to connect to Sybase by using Mono.Data.*?

Yes. use Mono.Data.SybaseClient. First of all you have to create a SybaseConnection, and then, from it, use it as any other IDbConnection-based class.

Mono and Java

Question 85: Why don't you use Java? After all, there are many languages that target the Java VM.

You can get very good tools for doing Java development on free systems right now. Red Hat has contributed a GCC front-end for Java that can take Java sources or Java byte codes and generate native executables; Transvirtual has implemented Kaffe a JIT engine for Java; Intel also has a Java VM called ORP.

The JVM is not designed to be a general purpose virtual machine. The Common Intermediate Language (CIL), on the other hand, is designed to be a target for a wide variety of programming languages, and has a set of rules designed to be optimal for JITers.

Question 86: Could Java target the CLI?

Yes, Java could target the CLI. We have details on a project that someone could take on to make this happen.

Microsoft has an implementation of the Java language called J# that can target the CIL execution engine.

Question 87: Is it possible to write a JVM byte code to CIL converter?

Yes, it is possible. Here are a few starting point:

    * A byte code representation is really a flattened forest of trees. Look at the Mono JIT engine to see how we compute the basic blocks (this is used to figure out the "trees").

    The forest is just an array of trees.

    Indeed, run the JIT engine with -d (mono -d prog.exe) and you will see how these trees look like.

    You will have to do something similar for Java.

    * Each "forest of trees" has a meaning. This meaning can now be translated into the equivalent "meaning" in CLR-land.

Question 88: Could mono become a hybrid CIL/java platform?

No. It is quite far from the philosophy of the project. The idea of Mono is, to have only _one_ VM, on which all can run. And if there existing a binary-converter from Java-.class to IL and if there existing something like J-Sharp on Mono, you can write programs in Java, which than can run on Mono. You do not need two bindings (like your example: GTK-Sharp _and_ Java-Gnome). You need only _one_ of it (GTK-Sharp). Thats the idea of Mono. An other point is, that there are no people, who use Open Source-JVMs. They all prefer Suns original. But for Unix there don't exist a .NET-Framework. So it is possible, that in the future Mono is the standard .NET for Unixes.

Question 89: Do you plan to implement a Javascript compiler?

Yes. Eto Demerzal has started a Rhino port to C#. After this is completed, we will begin developing the JavaScript compiler.

Question 90: Can Mono or .NET share system classes (loaded from mscore.dll and other libs) or will it behave like Sun's Java VM?

What you can do with mono is to load different applications in their own application domain: this is a feature of the CLR that allows sandboxing applications inside a single process space. This is usualy exploited to compartmentalize different parts of the same app, but it can also be effectively used to reduce the startup and memory overhead. Using different appdomains the runtime representation of types and methods is shared across applications.

Extending Mono

Question 91: Would you allow other classes other than those in the specification?

Yes. The Microsoft class collection is very big, but it is by no means complete. It would be nice to have a port of `Camel' (the Mail API used by Evolution inspired by Java Mail) for Mono applications.

You might also want to look into implementing CORBA for Mono. Not only because it would be useful, but because it sounds like a fun thing to do, given the fact that the CLI is such a type rich system.

For more information on extending Mono, see our ideas page.

Question 92: Do you plan to Embrace and Extend .NET?

Embracing a good technology is good. Extending technologies in incompatible ways is bad for the users, so we do not plan on extending the technologies.

If you have innovative ideas, and want to create new classes, we encourage you to make those classes operate correctly well in both Mono and .NET.

Question 93: Is there any way I can develop the class libraries using Linux yet?

Yes. Some class libraries can be developed on Linux. Search for Paolo's post (he lists which classes can be compiled fine now).

Question 94: Is there any way I can install a known working copy of mono in /usr, and an experimental copy somewhere else, and have both copies use their own libraries? (I'm still not very good at library paths in Linux)

Yes. Just use two installation prefixes.

Portability

Question 95: Will Mono only work on Linux?

Currently, we are doing our work on Linux-based systems and Windows. We do not expect many Linux-isms in the code, so it should be easy to port Mono to other UNIX variants.

Question 96: What about Mono on non Linux-based systems?

Our main intention at Ximian is to be able to develop GNOME applications with Mono, but if you are interested in providing a port of the Winforms classes to other platforms (frame buffer or MacOS X for example), we would gladly integrate them, as long they are under an open source license.

Question 97: What operating systems/CPUs do you support

Mono currently runs on Linux, Windows, Solaris and FreeBSD. There is a JIT engine available for x86 processors that can generate code and optimizations tailored for a particular CPU.

Interpreters exist for the SPARC, PowerPC and StrongARM CPUs.

Question 98: Does Mono run on Windows?

Yes. You can get pre-compiled binaries from http://www.go-mono.com/download.html

Question 99: Does Mono run on Linux?

Yes. You can get pre-compiled binaries from http://www.go-mono.com/download.html

Question 100: Will I require Cygwin to run mono?

No. Cygwin is only required to build Mono.

Question 101: Will Mono depend on GNOME?

It will depend only if you are using a particular assembly (for example, for doing GUI applications). If you are just interested in Mono for implementing a `Hello World Enterprise P2P Web Service', you will not need any GNOME components.

Question 102: Is anyone working on porting Mono to IA-64?

Nobody is working on such port.

Question 103: If I were about to start a Mono port to IA-64,would the same lburg code generator work for IA-64 also? or anything else need to be used for code generation(as the processor architecture is totally different from IA32)

The lburg approach can be use for any processor architecture. But you might think in another better approach.

Question 104: Do you plan to port Rhino to C#?.

Eto Demerzal has started a Rhino port to C#.

Question 105: Has anyone succeeded in building a Mac version of the C# environment. If so can you explain how?

You could try to check with the Darwin people, or the Fink people. Mono/C# is self hosting on Linux/PPC which is the hard part, so it should be relatively simple to get it to work on MacOS

Reusing Existing Code

Question 106: What projects will you reuse or build upon?

We want to get Mono in the hands of programmers soon. We are interested in reusing existing open source software.

Question 107: What about Intel's research JIT framework, ORP?

At this time, we are investigating whether we can use elements of ORP for Mono. ORP is a research JIT engine that has a clearly defined API that splits the JIT from the GC system and the actual byte code implementation.

We are using some pieces of ORP (Their code generation interface) and we use it as a source of inspiration for optimizations. Paolo and Dietmar consider ORP as being one of the best JIT engines out there (and their research work and papers are very useful if you are interested in JIT technology).

Question 108: What about using GNU Lightning?

We are not using GNU Lightning. Our JIT is using an instruction selector based on tree-pattern matching, and a code generation interface that is very tied to the current architecture.

Question 109: Will I be able to use Microsoft SQL Server 2000 or will I need to switch to a specific Open Source Database. Will I need to recode?

There should not be any need to recode.

Question 110: What do I need to watch out for when programming in VB.NET so that I'm sure to be able to run those apps on Linux?

Not making any PInvoke or DLL calls should and not using anything in the Microsoft.* namespaces should suffice. Also do not use any Methods/Classes marked as "This type/method supports the .NET Framework infrastructure and is not intended to be used directly from your code." even if you know what these classes/methods do.

Question 111: Will built-in reporting be supported for crystal reports? This is a heavily used part of our system.

Probably not. Crystal Reports are propriety. Someone may try to emulate the behavior, but no-one has yet volunteered.

Question 112: Who about writing to the registry? As I understand it, Linux does not have a counterpart to the registry. Should I avoid relying on that feature?

Try to avoid it. Although there would be a emulation for registry in Mono too. GNOME does have a registry like mechanism for configuration. But Even if gnome has a configuration system similar to the registry, the keys will not be equal, so you will probably end up having to do some runtime detection, and depending on this load an assembly that has your platform-specific hacks.

Question 113: System.Data.SqlClient with FreeTDS, will you port parts of these to C# and use them?

if their license is compatible with mono's, yes, we'd think about porting them. If not, we'll continue with the plan of using FreeTDS.

Mono and GCC

Question 114: Are you working on a GCC front-end to C#? A GCC back-end that will generate CIL images? What about making a front-end to GCC that takes CIL images and generates native code?

We are currently seeking volunteers for those projects. Visit the contributing section if you are interested.

Question 115: But would this work around the GPL in the GCC compiler and allow people to work on non-free front-ends?

People can already do this by targeting the JVM byte codes (there are about 130 compilers for various languages that target the JVM).

Question 116: Why are you writing a JIT engine instead of a front-end to GCC?

We want the JIT engine and runtime engine because they will be able to execute CIL executables generated on Windows, and so no recompilation will be necessary.

Performance

Question 117: How fast will Mono be?

We can not predict the future, but a conservative estimate is that it would be at least `as fast as other JIT engines'.

We would like to ship various JIT engines with Mono, just like Microsoft has done with their .NET development platform. We could provide a faster, JIT for fast load times but lower performance, and an and an optimizing JIT that would be slower at generating code but produce more optimal output.

The CIL has some advantages over the Java byte code: it is really an intermediate representation and there are a number of restrictions on how you can emit CIL code that simplify creating better JIT engines.

For example, on the CIL, the stack is not really an abstraction available for the code generator to use at will. Rather, it is a way of creating a postfix representation of the parsed tree. At any given call point or return point, the contents of the stack are expected to contain the same object types independently of how the instruction was reached.

Licensing

Question 118: Will I be able to write proprietary applications that run with Mono?

Yes. The licensing scheme is planned to allow proprietary developers to write applications with Mono.

Question 119: What license or licenses are you using for the Mono Project?

The C# Compiler is released under the terms of the GNU GPL. The runtime libraries are under the GNU Library GPL. And the class libraries are released under the terms of the MIT X11 license.

The Mono runtime and the Mono C# Compiler are also available under a proprietary license for those who can not use the LGPL and the GPL in their code.

For licensing details, contact mono-licensing@ximian.com

Question 120: I would like to contribute code to Mono under a particular license. What licenses will you accept?

We will have to evaluate the licenses for compatibility first, but as a general rule, we will accept the code under the same terms of the "container" module.

Question 121: Is the Mono

Patents

Question 122: Could patents be used to completely disable Mono (either submarine patents filed now, or changes made by Microsoft specifically to create patent problems)?

No. First, its basic functional capabilities have pre-existed too long to be held up by patents. The basic components of Mono are technologically equivalent to Sun's Java technology, which has been around for years.

Mono will also implement multi-language and multi-architecture support, but there are previous technologies such as UCSD p-code and ANDF that also support multiple languages using a common intermediate language. The libraries are similar to other language's libraries, so again, they're too similar to be patentable in large measure.

However, if Microsoft does patent some technology, then our plan is to either (1) work around it, (2) chop out patented pieces, (3) find prior art that would render the patent useless. Not providing a patented capability would weaken the interoperability, but it would still provide the free software / open source software community with good development tools, which is the primary reason for developing Mono.

Miscellaneous Questions

Question 123: You say that the CLI allows multiple languages to execute on the same environment. Isn't this the purpose of CORBA?

The key difference between CORBA (and COM) and the CLI is that the CLI allows "data-level interoperability" because every language/component uses the same data layout and memory management.

This means you can operate directly upon the data types that someone else provides, without having to go via their interfaces. It also means you don't have to "marshal" (convert) parameters (data layouts are the same, so you can just pass components directly) and you don't have to worry about memory management, because all languages/components share the same garbage collector and address space. This means much less copying and no need for reference counting.

Question 124: Will you support COM?

The runtime will support XPCOM on Unix systems and COM on Windows. Most of the code for dynamic trampolines exists already.

Question 125: Will Ximian offer certifications on Mono or related technologies?.

It's possible. But there is no plan about this. So the short answer is no.

Question 126: Are there any Boehm's GC binaries?

Yes. You can find RPMs here, though if your distribution provides the correct packages, you should use those. The suggested version of the Boehm GC is 6.1.

Question 127: How can I report a bug?

The best thing is to track down the bug and provide a simple test to reproduce the bug. You can then add the bug to the bugtracking system.

Please provide information about what version of mono you're using and any relevant details to be able to reproduce the bug. Note that bugs reported on the mailing-list may be easily forgotten, so it's better to file them in the bug tracking system.

Question 128: Does mcs support the same command line options as the MS C# compiler?

The Mono C# compiler now supports the same command line arguments as the Microsoft C# compiler does.

Question 129: How about getting searchable archives on lists.ximian.com?

You can perform a search on the mono-related mailing lists here.

Question 130: When using mono from cvs or from a snapshot, I get an error messaage saying that Mono and the runtime are out of sync. How do I fix that?

If you use mono from cvs, you need to be prepared for changes in the runtime internals. This means that you should keep a working setup before blindling updating (a working setup may just be the last released tarball or a recent binary snapshot). Usually, compiling corlib with mcs before recompiling the C runtime does the right thing (but occasionally you may need to do it the other way around).

Question 131: Why are you going for a GtkHtml implementation?

GtkHTML is just a lightweight HTML rendering engine that does not support CSS, so we need it to look decent for those of us that will be using the documentation in our day-to-day work on Linux. The Web-based interfaces lack the agility that you get from a native GUI tool to browse your documentation. Probably later on, we will write scripts and generate a full documentation set that is web-browsable, but we need a command-line and GUI tools that we can use natively on Linux when disconnected from the Web (and that has better interactions than a web page).

Question 132: Is there a command-line tool that allows me to access .NET interactively?

There are several but one that is free software and uses MCS is the one Dennis Lu from Rice University is working on; a REPL C# interpreter.

Question 133: Is it possible to use Visual C++ with Mono?.

Well, It's possible to run VC++ generated apps under Mono though.

Mono Common Problems

If you are having problems compiling or running Mono software or if you think that you found a bug, etc. Please visit the Mono Common Problems document and try there.

[AUTHOR: Johannes Roith is working on this]

[TODO]

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - License

The Mono Handbook > License

License

This document, The Mono Handbook, is copyrighted (c) 2003 by Johannes Roith, Martin Willemoes Hansen and the contributors mentioned on each page in the section "Credits".

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

The Mono Handbook | Mono Homepage | Credits | License


The Mono Handbook - Presentations

The Mono Handbook > Presentations

Presentations

Contents

  1. GUADEC 3
  2. .NET ONE 2002
  3. Miscelaneous
  4. Credits

GUADEC 3 April 2002
  • Mono (Spanish)

.NET ONE 2002
  • Keynote
  • The Mono C# compiler
  • Hosting the Mono Runtime
    • Quick hack to embed the mono runtime in a Perl module
  • The Mono JIT Compiler
  • Gtk# - Automated Library Binding Using Perl, XML and C#
  • Writing Portable GUI Applications for Win32 and UNIX with Gtk#
  • #Develop: Implementing a Class Browser and Code Completion
  • #develop: Implementing Extensible Editors

Miscelaneous
  • The Mono Project
  • Mono (ETH University) 2002
  • Mono (Zurich University) 2002
  • Mono (HispaLinux, Spanish) 2002

Credits

 Author: Martin Willemoes Hansen

© Copyright 2002 by Johannes Roith & Martin Willemoes Hansen


The Mono Handbook - Resources

The Mono Handbook > Resources

Resources

API References
  • gtk# API
  • MS Base Class API

Code samples
  • Sample gtk# applications

Whitepapers
  • Mono

Websites
  • www.go-mono.org
  • Mono for Debian

IRC
  • irc.gnome.org #mono
© Copyright 2002 by Johannes Roith & Martin Willemoes Hansen


The Mono Handbook - Resources

The Mono Handbook > Resources

Recomended Reading

Books

  • A Programmer's Introduction to C# by Eric Gunnerson
  • Advanced .NET Remoting by Ingo Rammer
  • ASP.NET in a Nutshell by G. Andrew Duthie & Matthew MacDonald
  • Programming ASP.NET by Jessy Liberty & Dan Hurtwitz

© Copyright 2002 by Johannes Roith & Martin Willemoes Hansen


The Mono Handbook - Resources

The Mono Handbook > Resources

Sample Applications

The best way to learn something new is often to look at samples. The more the better.
This tutorial has hundreds of samples (or will have at least), but there are some real applications available, that are worth a look.

MPhoto

  • Application for managing you digital photos (only in cvs)

Phonic

  • GTK# audio Player, makes use of Gstreamer

Platano Multimedia Player

  • Gtk# video/audio player, makes use of GStreamer

GSIRC

  • Gtk# cross platform IRC client

GnoMencoder

  • DVD ripping utility

Jump n Bump menu

  • A Graphical frontend to Jump n Bump

Bomb O Naval

  • A classic board game, where you will fight a great sea battle.

© Copyright 2002 by Johannes Roith & Martin Willemoes Hansen


The Mono Handbook - Code Samples

The Mono Handbook > Code Samples

Code Samples

All code samples used have a representation in the /samples directory.

You can compile all samples by typing "make" in /samples or make each directory on it's own.
All examples mention the path like that:

// HelloWorld - /hello/hello.cs
// Copyright 2002 by Johannes Roith

namespace Sample.hello {

        ...

}
The Mono Handbook © Copyright 2002 by Johannes Roith


The Mono Handbook - .Net Framework Architecture

The Mono Handbook > .Net Framework Architecture

.Net Framework Architecture

Contents

  • I. The Big Picture
  • II. Class Library
    • Namespaces
    • Assemblies
  • III. Common Language Infrastructure
  • IV. Common Language Specification
  • V. Bibliography
  • A. Credits

I. The Big Picture

When approaching something as complex as .Net, it helps to have some idea of how it relates to your work. The following diagram provides some context for where your application fits into the Mono / .Net framework.

Figure 1

NOTE: This is a greatly simplified view; we're ignoring ASP.NET and ADO.NET for now. We could also explain the difference between managed and unmangaged code.

Refer to the above diagram for the following sections.

II. Class Library

The class library provides a comprehensive set of facilites for application development. Primarily written in C#, it can be used by any language, thanks to the Common Language Specification.

The class library is structured into Namespaces, and deployed in shared libraries known as Assemblies.
When we speak of the .Net framework , we are primarily referring to this class library.

Namespaces

Namespaces are a mechanism for logically grouping similar classes into a hierarchical structure. This prevents naming conflicts. The structure is implemented using dot-separated words. The top level namespace for most of the .Net framework is System. Under the System namespace you'll find the following:

  • System.IO
  • System.Net
  • System.Net.Sockets
  • System.Reflection
  • System.Threading
  • ...and many others. For a complete list, see the Mono class library status page.
There are other top-level namespaces as well; Accessibility, and Windows are examples. You can also create your own namespaces: just prefix them with the name of your organisation. Microsoft.VisualBasic is an example.

Assemblies

Assemblies are the physical packaging of the class libraries. These are .dll files, but don't confuse them with Win32 shared libraries. Examples are
  • corlib.dll
  • System.dll
  • System.Data.dll
  • Accessibility.dll
Note that namespaces are often distributed among several assemblies. Again, see the Mono class library status page. An assembly can also be composed of several files.

III. Common Language Infrastructure

More commonly known as the Common Language Runtime, this is implemented by the Mono executable. This runtime is used to execute the compiled .NET application. The common language infrastructure is defined by ECMA standard ECMA-335.

To run your application, you must invoke the runtime with the relevant parameters.

IV. Common Language Specification

This is specified in ECMA-335,chapter 6. It defines the interface to the CLI; e.g. conventions such as the underlying types for Enum.

The Mono compiler generates an image that conforms to the CLS. This is the Common Intermediate Language. The mono runtime takes this image and runs it.

The ECMA standard formally defines a library that conforms to the CLS as a framework.

V. Bibilography

MSDN documentation for .Net SDK, framework is here.

O'Reilly C# in a Nutshell, Definitely recommended..

A. Credits

Author: Norman Lorrain (normanlorrain@hotmail.com)

The Mono Handbook | Mono Homepage | Credits | License


The Mono Handbook - ASP.NET

The Mono Handbook > WebSites and WebServices...

WebSites and WebServices with ASP.NET

I. Introduction

Could you imagine coding _everything_ in assembler?

Not?

Well, I don't feel comfortable as well. But HTML is easy, so how should this be comparable? It's comparable in that way, that current development tools like Java PHP or plain ASP work directly on top of the technical base, without any abstraction layer.

A calendar does consists of at least 100 lines of HTML with programming code mixed in. In ASP.NET a calendar looks like this:

<asp: calendar runat="server"/>
Cool! But the Browser can't read this. In fact this calendar consists of 100 lines, too, but they are encapsulated in an ASP.NET control, and for the developer accessible, like HTML tags. Developers can of course create their own controls.

Most WebPages for example have those banners at the top, with logo and sometimes navigation in it. This is a typical case for an ASP.NET control. So what ASP.NET wants to do, and what makes it different from other WebDevelopment eniroments, is, that HTML tags or complex objects, built of serveral HTML tags are accessible as objects.

A. Credits

Author: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - WebSites and WebServices...

The Mono Handbook > WebSites and WebServices...

Installation

Contents

  • I. Choose a WebServer
  • II. XSP
  • III. Apache Web Server

I. Choose a WebServer

The first step is to setup a webserver. Currently, there are two options.
  • XSP, a webserver, written in C#, that can make use of the ASP.NET classes.
  • Apache with mod_mono
While XSP is faster to setup, it requires no configuration, for production enviroments Apache is strongly recomended, because it offers smooth integration with existing web technologies, like PHP, and is much wider deployed.

II. XSP

1. Get XSP

Get XSP from CVS or untar a release (go-mono.org).

2. Installing XSP

Eventually untar, then "make" in /path/to/xsp/

3. Configuration is not needed, but possible.

Currently you can set the port value in server.config

It can easily be run, by typing "mono server.exe" in path/to/xsp/server/test.
You should put all your aspx files in path/to/xsp/server/test, too.

III. mod_mono

If not already done, you need to compile Apache2:

0. Install Apache 2, with loadable module support

Go to http://www.apache.org and download Apache 2,
the filename will be something like httpd-2.0.43.tar.gz

Unpack it :

tar xvfz httpd-2.0.43.tar.gz
cd httpd-2.0.43
./configure --prefix=/home/username/apache2 --enable-so
make
make install

1. Building and installing mod_mono

Go to http://www.apacheworld.org/modmono/ and download mod_mono or get it from CVS.
Untar, then run:

./configure --with-apache2=/home/username/apache2
make
make install

If everything goes well, you will have the following library:
/home/user/mono/mod_mono/src/.libs/libmod_mono.so

2. Building ModMono.dll

The ModMono.cs file is located in the src/ directory
This is the command I use to build ModMono.dll:

mcs ModMono.cs -target:library -reference:/home/user/mono/install/lib/System.Web.dll

3. Configuring Apache

Copy the file /home/user/mono/mod_mono/src/.libs/libmod_mono.so to /home/user/mono/install/apache2/lib/
Copy ModMono.dll to /home/user/mono/xsp/server/test/ModMono.dll

Edit /home/user/mono/install/apache2/conf/httpd.conf :

Listen 8080
LoadModule mono_module /home/user/mono/install/apache2/lib/libmod_mono.so
LoadModMonoDll /home/user/mono/xsp/server/test/ModMono.dll

Alias /mono /home/user/mono/xsp/server/test

<location /mono/*.aspx>
SetHandler application/x-httpd-mono
</location>

You can now start Apache with
/home/user/mono/install/apache2/bin/apachectl start

First ASP.NET page

After sucessful installation, point your browser to http://localhost:8080/index.aspx . There is a wide range of examples available, to test your server.

A. Credits

Author: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - WebSites and WebServices...

The Mono Handbook > WebSites and WebServices...

Introduction

I. Introduction

Besides typical Web pages, more and more applications are web-based. The main reason is, because the are easily to maintain, update, and to consume for the user. Also HTML has envolved and with CSS, great designs are possible. Those web applications are mostly either written in Java, ASP, PHP or - now - ASP.NET. Mono brings ASP.NET to Linux - together with Apache one of the most important platforms used on the web, today.

For those "web applications" ASP.NET is better suited than traditional tools like PHP or Java. While PHP and Java generate a form for example, by outputting HTML from tags, ASP.NET abstracts a form from HTML. It's accessible like a GUI form in client programming. This is a huge advantage.

A. Credits

Author: Johannes Roith (johannes@jroith.de)

© Copyright 2002 by Johannes Roith


The Mono Handbook - Programming with ASP.NET

The Mono Handbook > Programming with ASP.NET

Programming with ASP.NET Mobile

Contents

  • 1. Introduction
  • 2. Differences to ASP.NET
  • 3. Getting a WAP/HTML Emulator

  • 3. Useful Samples
    • 3.1 Headlines from several NewsSites
    • 3.2 Maintaining a personal Blog, while not at home
  • 4. List of Supported Devices

  • 5. Reference: ASP.NET Mobile Server Controls
    • 4.1 Command
    • 4.2 Form
    • 4.3 Image
    • 4.4 Label
    • 4.5 Link
    • 4.6 List
    • 4.7 MobilePage
    • 4.8 ObjectList
    • 4.9 Panel
    • 4.10 SelectionList
    • 4.11 StyleSheet
    • 4.12 TextBox
    • 4.13 TextView

A. Credits

Author: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - Programming with ASP.NET

The Mono Handbook > Programming with ASP.NET

Programming with ASP.NET

Introduction

This tutorial will teach you how to write Web Applications with mono, specially with C#. You should know about C# and it also might be helpful to know something about ADO.NET, monos database layer.

Contents

  • 1. Hello World!
  • 2. Introducing WebForms

  • 3. Example Project: MonoWebMail - ASP.NET Mail & Groupware solution
    • 3.1 Planning the Project
      • 3.2 Page Structure
      • 3.3 Database Design
    • 3.4 First page & custom Controls
    • 3.4 Using Application configuration files
    • 3.5 Implementing a simple User Management System

    • 3.6 Different Sub-Components
      • 3.6.1 Summary: Reading News Sites
      • 3.6.2 Calendar
      • 3.6.2 Send & recieve Mail
  • 4. ASP.NET Mobile Internet Toolkit
    • 4.1 Technical Background
    • 4.2 Mono Portal on your Mobile Phone or PDA!

  • 5. Reference: ASP.NET HTML Server Controls
    • 4.1 HtmlAnchor
    • 4.2 HtmlButton
    • 4.3 HtmlForm
    • 4.4 HtmlGeneric
    • 4.5 HtmlImage
    • 4.6 HtmlInputButton
    • 4.7 HtmlInputCheckBox
    • 4.8 HtmlInputFile
    • 4.9 HtmlInputHidden
    • 4.10 HtmlInputImage
    • 4.11 HtmlInputRadioButton
    • 4.12 HtmlInputText
    • 4.13 HtmlSelect
    • 4.14 HtmlTable
    • 4.15 HtmlTableCell
    • 4.16 HtmlTableRow
    • 4.17 HtmlTextArea
  • 7. ASP.NET Web Server controls
    • 5.1 AdRotator
    • 5.1 Button
    • 5.1 Calendar
    • 5.1 CheckBox
    • 5.1 CheckBoxList
    • 5.1 DataGrid
    • 5.1 DataList
    • 5.1 DropDownList
    • 5.1 HyperLink
    • 5.1 Image
    • 5.1 ImageButton
    • 5.1 Label
    • 5.1 LinkButton
    • 5.1 ListBox
    • 5.1 Literal
    • 5.1 Panel
    • 5.1 PlaceHolder
    • 5.1 RadioButton
    • 5.1 RadioButtonList
    • 5.1 Repeater
    • 5.1 Table
    • 5.1 TableCell
    • 5.1 TableRow
    • 5.1 TextBox
    • 5.1 Xml

A. Credits

Author: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - ArrayList

The Mono Handbook > Collections > ArrayList

ArrayList

Introduction

The ArrayList is a very powerful class, that is similiar to an array, but objects can be added and removed dynamically and are stored as Object. So you can add strings, integers or for example Points or Gtk# forms.

In order to add en element at the end of the List, simply use Add(). To add several elements, try AddRange().
To insert somewhere else try Insert() or InsertRange().

To Remove elements you must use Remove() and RemoveRange().

C# sample

// ArrayListSample.cs
// (C) Copyright 2003 by Johannes Roith

using System;
using System.Collections;

class ArrayListSample {

    static void Main()
    {

        ArrayList arraylist1 = new ArrayList();

    }
}

MonoBasic sample

// ReadTextFile.vb
// (C) Copyright 2003 by Johannes Roith

imports System
imports System.Collections

Public Module ReadTextFile {

    Public Sub Main ()

    End Sub

 End Module

Writing a Textfile

A more interesting Example. Gets Xml from the server, reads it and puts out a Textfile.

© Copyright 2002 by Johannes Roith


404 Not Found

Not Found

The requested URL /tutorial/html/en/base_classes/sfbinaryfiles.html was not found on this server.

Apache/1.3.26 Server at go-mono.com Port 80


404 Not Found

Not Found

The requested URL /tutorial/html/en/base_classes/sfintroduction.html was not found on this server.

Apache/1.3.26 Server at go-mono.com Port 80


The Mono Handbook - Streams & Files

The Mono Handbook > Streams & Files > Read / Write Textfiles

Read / Write Textfiles

Reading a simple Textfile

The File access classes are in the System.IO namespace, that needs to be included.
It's really easy, so I only give a C# and basic sample. It just prints a textfile with line numbers.

C# sample

// ReadTextFile.cs
// (C) Copyright 2003 by Johannes Roith

using System;
using System.IO;

class ReadTextFile {

    static void Main()
    {
           StreamReader file1;
        int i = 1;

        file = File.OpenText("readme.txt");

        while (file.Peek() != null)
        {
            Console.WriteLine(i + " " + file.ReadLine());
            i++;
        }

    }
}

MonoBasic sample

// ReadTextFile.vb
// (C) Copyright 2003 by Johannes Roith

imports System
imports System.IO

Public Module ReadTextFile {

    Public Sub Main ()

           StreamReader file1
        int i = 1

        file = File.OpenText("readme.txt")

        While (file.Peek() != null)

            Console.WriteLine(i + " " + file.ReadLine())
            i++

        End While

    End Sub

 End Module

Writing a Textfile

A more interesting Example. Gets Xml from the server, reads it and puts out a Textfile.

© Copyright 2002 by Johannes Roith


The Mono Handbook - Namespaces

The Mono Handbook > Basic namespaces >System

Basic namespaces: System

by Johannes Roith (johannes@jroith.de)

Contents

  • I. System.

All these Classes need to be described. Who wants to help? Helping is really easy and a straight forward task. It's enough if you pick only *one* class. Contact me at johannes@jroith.de.

I. System.Object

[TODO:GetType(), ToString(), GetHashCode(), Equals(), ReferenceEquals();MemberWiseClone();]

System.Console

Provides access to input and output.

Console.Write() : Writes output to the console.
Console.WriteLine() : Adds \n at the end of the line.

Both are overloaded serval time, so you can pass them Boolean, Int32, Char, Double, String, ...

Console.Read() : Read a single char.
Console.WriteLine() : Reads complete line.

// getname.cs

using System;

class consoletest {

    public static void Main(){

        string name;

        Console.Write("Please enter your name: ");
        name = Console.ReadLine();
        Console.WriteLine("Hello, " + name + "!");

    }

}

System.String

[TODO]

System.Uri

[TODO]

System.UriBuilder

[TODO]

System.Convert

[TODO]

System.GC

[TODO]

System.BitConverter

[TODO]

System.Version

This class is overloaded and can either generate a version number string (x.x.x.x) from 4 integers, or split a version string in it's four numbers.

Each number is then accessible as obj.Major, obj.Minor, obj.Revision, obj.Build.

// guidtest.cs
// Generates a version form 4 integers, Splits the numbers again from the string.

using System;

class versiontest {

    public static void Main(){

        Version v = New Version(1, 3, 12, 40);

        // v.ToString() is now  "1.3.12.40"
        Version v2 = New Version(v.ToString());

        Console.WriteLine("Major:"    + v2.Major);
        Console.WriteLine("Minor:"    + v2.Minor);
        Console.WriteLine("Revision:" + v2.Revision);
        Console.WriteLine("Build:"    + v2.Build);

    }

}

System.Guid

This class can generate a "Global Unique Indetifier", that is unique across time and location.

Important is, that the method NewGuid must be called, to generate an unique number.

// guidtest.cs

using System;

class guidtest {

    public static void Main(){

        string name;
        Guid myguid = New Guide();
        myguide = myguide.NewGuid();

        Console.WriteLine(myguide.ToString());

    }

}

System.Math

Offers 2 mathematical constants: e and pi

Offers many mathematical funtions:

  • Abs()
  • Acos()
  • Asin()
  • Atan()
  • Atan2()
  • Ceiling()
  • Cost()
  • Cosh()
  • Exp()
  • Floor()
  • IEEERemainder()
  • Log()
  • Log10()
  • Max()
  • Min()
  • Pow()
  • Round()
  • Sign()
  • Sin()
  • Sinh()
  • Sqrt()
  • Tan()
  • Tanh()
[TODO: Explain function and using]

[TODO: Write a big example, where they all can be used]

System.Enviroment

This class contains only static methods, that provide information about the OperatingSystem.

There is nothing to explain, instead of that here is a good commented example, printing all properties.

[TODO: Write Example]

// enviroment.cs

using System;

class Enviroment {

    public static void Main(){

        Console.WriteLine("Computer name: " + System.Enviroment.MachineName);

        // continue...
    }

}

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - Namespaces

The Mono Handbook > Basic namespaces >System

Basic namespaces: System.Collections

by Johannes Roith (johannes@jroith.de)

Contents

  • I. System.
  • A. License: GNU Free Documentation License

I. System.

[TODO: ArrayList, Stack and Queue, BitArray, HashTable, creating own collections, specialized collections]

© Copyright 2002 by Johannes Roith


The Mono Handbook > Basic namespaces >System

Basic namespaces: System.Text

by Johannes Roith (johannes@jroith.de)

Contents

  • I. System.Text.StringBuilder
  • A. License: GNU Free Documentation License

I. System.Text.StringBuilder

This namespace conatins one class, that is worth to be mentioned: System.Text.StringBuilder. You can insert, replace, remove or append strings.

[TODO]

© Copyright 2002 by Johannes Roith


The Mono Handbook - Namespaces

The Mono Handbook > Basic namespaces >System

Basic namespaces: System.Text.

by Johannes Roith (johannes@jroith.de)

Contents

  • I. System.Text.
  • A. License: GNU Free Documentation License

I. System.Text.

[TODO]

© Copyright 2002 by Johannes Roith


The Mono Handbook - Learning C#

The Mono Handbook > Learning C#

Component Interoperability with Windows COM

Mono is currently not developing Bonobo interoperability. However I expect this to come someday. This page will be updated then.

A. Credits

Authors: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2003 by Johannes Roith & Martin Willemoes Hansen


The Mono Handbook - Learning C#

The Mono Handbook > Learning C#

Component Interoperability with Windows COM

Mono is currently not developing COM interoperability. If noone takes this part it is not available.

The Mono Handbook - © Copyright 2003 by Johannes Roith & Martin Willemoes Hansen


The Mono Handbook - 10 golden rules to keep your programs cross-platform and .NET/mono compatible

The Mono Handbook > 10 golden rules to keep your ...

10 rules to be cross-platform and .NET compatible

by Johannes Roith (johannes@jroith.de)
  • Do not use absolute paths (e.g. c:\program files\yourapplication)
  • It's better to use GTK# than System.Windows.Forms.
  • Do only p/invoke against native libaries if really needed. Make sure, the library is available for Unix and Windows.
  • Do not read Registry keys, trough Microsft.Win32.Registry, that are maintained by Windows. (Run, RunServices, get system information, etc.)

© Copyright 2002 by Johannes Roith


The Mono Handbook - Cross platform applications with mono

The Mono Handbook > Cross platform applications with mono

Fast Cross-platform GUI

by Johannes Roith (johannes@jroith.de)

I. Your options

When it comes to GUI, the .NET Framework shows it's side, that makes code unportable. Microsoft does offer one toolkit, called System.windows.Forms. It's based on the Windows APIs, which make it look native. Mono is implementing it, for compatiblity reasons, but the implementation is based on wine, a windows emulator, and has several disadvantages. First, such an application can be executed with mono, but needs a special command, that em,bedds wine. It integreates bad with the rest of the system on other OS than Windows and certainly will not be ported to all platforms.

Secondly, and that's even more of a reason, it's not very powerful. While Windows programmer might be used to it - unlike both Linux desktops GUI toolkits - it does fix widgets with coordinates on the form. GTK#/Qt# use an intellegent boxing-system. The user can resize the form - it will be never to small. Internationalization is much easier, that way, because if the text doesn't fit in the room, the box is automatically made bigger.

The way Java did take is called Swing. Swing looks consitent (ugly) across all platforms. And it is slow. Very slow. In fact that's one of the reasons why people think Java is slow in general. But we have better options. There are two GUI toolkits ou there, one used by KDE desktop, one by Gnome. Both are ported to Windows and MacOS X. Gtk, the Gnome toolkit, is even ported to Framebuffer and BeOS. Gtk# (the C# binding to Gtk) is very fast, currently Qt# is even faster. Much faster than Swing.

So, what GUI to take? My personal favorite is GTK#. Why? The Windows and MacOS X versions of Qt are not free, currently. The developers are working on porting the X11 code to Windows. But currently it is not done. Besides that I'm a Gnome fan, and more used to the Gtk+ toolkit.

II. Learning about things

The Mono Handbook has a big section GNOME.NET. Not all of Gnome is multiplatform. But we have clearly marked, what is. The portable part is:

  • Gtk - Widgets & Co.
  • Gdk - Drawin
  • Pango - 1st class internationalisation support
  • Atk - accessiblity support for people with disablities
  • Glade - Forms, based on XML, that can be changed dynamically
  • Glade Interface Builder - Tools to easily create those XML files.
The next step is, to learn about these in chapter 18.

The Mono Handbook - © Copyright 2003 by Johannes Roith


The Mono Handbook - Cross platform applications with mono

The Mono Handbook > Cross platform applications with mono

Cross platform applications with mono

by Johannes Roith (johannes@jroith.de)

Introduction

Today applications need often run on a wide range of platforms. Though cross-platform C-compilers are available, it's still a lot of work to port, and binaries can't be shared across those platforms. This is one of the reasons, why Java got so popular. With the arrival of .NET many people (including me) immediatley liked it. But I always had a bad feeling using it, because I knew I was bound to one platform - Microsoft Windows.

The arrival of mono solved this issue in a perfect way. Although many people believe Java is somehow more portable, they're wrong. All mono including the big, big class library is 100% cross platform compatible between Windows and Linux. There are some libraries, that mono depends on, but more and more get replaced by 100% C# code (like for example the MySQL and PostgreSQL data providers.

Thanks to binary compatiblity you can simply copy a binary compiled on Windows to Linux. Examples are a complete compiler (MCS) and others. Sometimes application need to p/invoke against native libaries, but this is also the case with Java, and it will get fewer and fewer, the more libraries get ported to C#.

That being said you can easily destroy that portablity, if you use certain unportable code parts. This chapters will tell you anything you kneed to know, and then maybe you just copy your application developed on Windows to Linux or MacOS X and it will just work.

The Mono Handbook - © Copyright 2003 by Johannes Roith


The Mono Handbook - Embedding

The Mono Handbook > Embedding Mono

Embedding the Mono runtime, preliminary version

by Paolo Molaro, Miguel de Icaza

Contents

  • I. Introduction
  • II. Embedding the runtime
  • III. Exposing C code to the CIL universe
  • VI. Invoking Methods in the CIL universe
  • V. Invoking a Method
  • VI. Samples

I. Introduction

This document describes how to embed the Mono runtime in your application, and how to invoke CIL methods from C, and how to invoke C code from CIL Slides for Paolo's presentation at .NET ONE on the embedding API are available here: Hosting the Mono Runtime.

Embedding the runtime.

Embedding the runtime consists of various steps:

  • Compiling and linking the Mono runtime

  • Initializing the Mono runtime

  • Optionally expose C code to the C#/CIL universe.

These are discussed in detail next.

Compiling and Linking

To embed the runtime, you have to link your code against the Mono runtime libraries. To do this, you want to pass the flags returned by pkg-config to your compiler:

        pkg-config --cflags --libs mono

Like this:

        gcc sample.c `pkg-config --cflags --libs mono`

You can separate the compilation flags from the linking flags, for instance, you can use the following macros in your makefile:

        CFLAGS=`pkg-config --cflags mono`
        LDFLAGS=`pkg-config --libs mono`

Initializing the Mono runtime

To initialize the runtime, call mono_jit_init, like this:

        MonoDomain *domain;

        domain = mono_jit_init ("domain-name");

That will return a MonoDomain where your code will be executed. You can create multiple domains. Each domain is isolated from the other domains and code in one domain will not interfere with code in other domains. This is useful if you want to host different applications in your program.

Then you can load an assembly containing code into the domain:

        MonoAssembly *assembly;

        assembly = mono_domain_assembly_open (domain, "file.dll");
        if (!assembly)
            error ();

In the above example, the contents of `file.dll' will be loaded into the domain. This only loads the code, but it will not execute anything yet. You can replace `file.dll' with another transport file, like `file.exe'

To start executing code, you must invoke a method in the assembly, or if you have provided a static Main method (an entry point), you can use the convenience function:

        retval = mono_jit_exec (domain, assembly, argc - 1, argv + 1);

If you want to invoke a different method, look at the `Invoking Methods in the CIL universe' section later on.

Shutting down the runtime

To shutdown the Mono runtime, you have to clean up all the domains that were created, use this function:

        mono_jit_cleanup (domain);

Applications that use threads.

The Boehm GC system needs to catch your calls to the pthreads layer, so in each file where you use pthread.h you should include the file.

Exposing C code to the CIL universe

The Mono runtime provides two mechanisms to expose C code to the CIL universe: internal calls and native C code. Internal calls are tightly integrated with the runtime, and have the least overhead, as they use the same data types that the runtime uses.

The other option is to use the Platform Invoke (P/Invoke) to call C code from the CIL universe, using the standard P/Invoke mechanisms.

To register an internal call, use this call in the C code:

    mono_add_internal_call ("Hello::Sample", sample);

Now, you need to declare this on the C# side:

        using System;
        using System.Runtime.CompilerServices;

    class Hello {
        [MethodImplAttribute(MethodImplOptions.InternalCall)]
        extern static string Sample ();
    }

Since this routine returns a string, here is the C definition:

        static MonoString*
        Sample ()
        {
            return mono_string_new (mono_domain_get (), "Hello!");
        }

Notice that we have to return a `MonoString', and we use the `mono_string_new' API call to obtain this from a string.

Invoking Methods in the CIL universe

Calling a method in the CIL universe from C requires a number of steps:

  • Obtaining the MonoMethod handle to the method.

  • The method invocation.

Obtaining a MonoMethod

To get a MonoMethod there are several ways.

You can get a MonoClass (the structure representing a type) using:

    MonoClass *
    mono_class_from_name (MonoImage *image, const char* name_space, const char *name);

and then loop in the returned class method array until you get the one you're looking for. There are examples of such searches as static functions in several C files in metadata/*.c: we need to expose one through the API and remove the duplicates.

The other, simpler, way is to use the functions in debug-helpers.h: there are examples of their use in monograph, mint and the jit as well. You basically use a string description of the method, like:

            "System.Object:GetHashCode()"
and create a MonoMethodDesc out of it with:
    MonoMethodDesc* mono_method_desc_new (const char *name, gboolean include_namespace);
You can then use:
    MonoMethod*     mono_method_desc_search_in_class (MonoMethodDesc *desc, MonoClass *klass);
    MonoMethod*     mono_method_desc_search_in_image (MonoMethodDesc *desc, MonoImage *image);
to search for the method in a class or in an image. You would tipically do this just once at the start of the program and store the result for reuse somewhere.

Invoking a Method

There are two functions to call a managed method:

    MonoObject*
    mono_runtime_invoke         (MonoMethod *method, void *obj, void **params,
                                 MonoObject **exc);
    and
    MonoObject*
    mono_runtime_invoke_array   (MonoMethod *method, void *obj, MonoArray *params,
                                 MonoObject **exc);
obj is the 'this' pointer, it should be NULL for static methods, a MonoObject* for object instances and a pointer to the value type for value types.

The params array contains the arguments to the method with the same convention: MonoObject* pointers for object instances and pointers to the value type otherwise. The _invoke_array variant takes a C# object[] as the params argument (MonoArray *params): in this case the value types are boxed inside the respective reference representation. From unmanaged code you'll usually use the mono_runtime_invoke() variant.

Note that this function doesn't handle virtual methods for you, it will exec the exact method you pass: we still need to expose a function to lookup the derived class implementation of a virtual method (there are examples of this in the code, though).

You can pass NULL as the exc argument if you don't want to catch exceptions, otherwise, *exc will be set to the exception thrown, if any. if an exception is thrown, you can't use the MonoObject* result from the function.

If the method returns a value type, it is boxed in an object reference. We have plans for providing an additional method that returns an unmanaged->managed thunk like this:

    void* mono_method_get_unmanaged_thunk (MonoMethod *method);
You'll be able to store the returned pointer in a function pointer with the proper signature and call that directly from C:
    typedef gint32 (*GetHashCode) (MonoObject *obj);

    GetHashCode func = mono_method_get_unmanaged_thunk (System_Object_GetHashCode_method);

    gint32 hashvalue = func (myobject);
It may not be possible to manage exceptions in that case, though. I need to think more about it.

Samples

See the sample programs in mono/sample/embed for examples of embedding the Mono runtime in your application.

© Copyright 2002 by Paolo Molaro, Miguel de Icaza


The Mono Handbook - Embedding

The Mono Handbook > Embedding Mono

Embedding the Mono runtime in Perl

by Paolo Molaro, Johannes Roith

Contents

  • I. Introduction
  • II. Embedding the runtime

I. Introduction

This document describes how to embed the Mono runtime in your Perl application. You can also get Paolo Molars's sample Mono module for Perl.

Mono can be embedded in every language, that allow C extensions/plugins, or is written in C. Unlike a CIL Perl compiler, such Perl code doesn't have all the advantages, that C# or Mbas code has. It doesn't run with the .NET Runtime and is not necessarily portable. The application is not executes by mono, but with the perl interpreter.

Because of that, this is especially used to use the powerful class library, GTK# or other C# classes of mono. For example with Paolos Perl binding, you don't need Gnome Perl bindings anymore. Perl can make use of GTK#. It can also access Databases through ADO.NET, make use of the XML classes, etc. It can't do ASP.NET for example, because it's not a cil application.

// Example Perl script, making use of
// the mono class library.

// © Copyright 2002 by Paolo Molaro

use blib;
use Mono qw(System::Console System::Environment);

System::Console::WriteLine ("from perl");
System::Console::WriteLine (10);

$user = System::Environment::get_UserName ();

print "the current user is $user\n";

Embedding the runtime

Now let's see how it is done.

The Mono Handbook - © Copyright 2002 by Paolo Molaro, Miguel de Icaza


The Mono Handbook - Gtk# FAQ

The Mono Handbook > Gtk# FAQ

Gtk# Frequently Asked Questions

  1. General
    1. What is Gtk#?
    2. Why isn't it called Gnome# or Gnome.Net?
  2. Compiling Gtk#
    1. What are the Dependencies to build Gtk# on X11 platforms?
    2. What about building on Win32 platforms?
  3. Developing with Gtk#
    1. Why can't mono find gtk-sharp.dll?
    2. Why can't my compiler find Gtk# classes?

1.1 What is Gtk#?

Gtk# brings the power and ease of .Net development paradigms to the free software GUI application development community. Gtk# provides a C source parser and C# code generator which can be used to produce .Net assemblies that bind to GObject based libraries. Among the libraries currently wrapped are gtk, gdk, atk, pango, gda, gnomedb, gconf, libgnomecanvas, libgnomeui, and libglade.

1.2 Why isn't it called Gnome# or Gnome.Net?

When the project was started, the idea was to wrap the Gtk+ libraries with a set of C# classes. It quickly became apparent that the source parser and C# code generator could be used to wrap any GObject based API. Contributors started wrapping their favorite GNOME libraries. Mailing lists and a sourceforge project were already open under the gtk-sharp nomenclature and no compelling technical reasons for renaming presented themselves. The decision was made to continue under the Gtk# name, even though the binding encompasses more than just Gtk, and more than just C#.

2.1 What are the Dependencies to build Gtk# on X11 platforms?

You'll need a .Net framework installed. Gtk# has been successfully used with both the mono and Portable.Net frameworks. The bare minimum requirement is a complete installation of the Gtk+-2.0 libraries. Keep in mind that if your Gtk+ installation is provided by binary packages, you will also need to install the *-devel packages. If you have additional GNOME-2.0 libraries installed, the configure script will detect their presence and the associated wrappers will be built. A summary of the libraries which will be built is printed at the end of the configure step.

2.2 What about building on Win32 platforms?

To build Gtk# on win32, you will need a working cygwin installation. Keep in mind that the default cygwin installation may not have all the tools you need. Cygwin provides the gnu make tool which builds the Gtk# library. You will also need the mingw-gcc compiler installed in order to build the Gtk# glue library. There are binary packages of the Gtk+-2.0 libs and dependencies available from the Gtk+ for Win32 project page. You will also need these libraries installed, along with their devel packages in order to build the glue library. Once you have this environment set up, expand the gtk-sharp source into a directory and in a cygwin shell window, cd to the gtk-sharp directory and execute the command "make -f makefile.win32".

3.1 Why can't mono find gtk-sharp.dll?

You most likely have installed Gtk# into a prefix other than where mono is installed. In order for the runtime to locate the Gtk# assemblies, you will need to add their location to the MONO_PATH environment variable. For the default installation prefix, this will mean executing the following command:
export MONO_PATH=/usr/local/lib:$MONO_PATH

3.2 Why can't my compiler find the Gtk# classes?

You need to provide an assembly reference in your compilation command. This will look like "mcs /ref:gtk-sharp foo.cs" if you are referencing classes in the Gtk or GtkSharp namespaces.

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - GNOME.NET - Installation

The Mono Handbook > Installation GNOME.NET

Gnome.NET - Installation

In order to write applications for Gnome with mono, you need to have Gtk# installed additionally to mono. Besides that you'll need the "Gnome Developer Platform" a big set of libaries that form the foundation of Gtk#. For some features it's useful to have the Gnome desktop installed.

Install Gnome

You'll need at least the Gnome Development Platform, but you will feel more integrated with the Gnome desktop. Both should be available for you distribution. If not (or you don't know where, or your ditribution is older), there is a very easy, but good package to build Gnome from source, GARNOME. I've built al least 2 times, and it works without problems. You can get it here.

The easiest option is to install the Ximian 2 Desktop. It's just a matter of typing one line in a terminal - a GUI setup will get the packages from the Ximian servers. At the time of this writing Ximian Gnome 2 is not available, yet.

Install Gtk#

To get started with GNOME.NET you need to install Gtk# wich contains bindings to gtk+2.x and various other bindings for GNOME specific libraries. Gtk# binaries are not completely platform independent, as they use a smalll C glue library. On Debian, it is recommended to install the Debian packages from here. You can get the source from the homepage gtk-sharp-sf.net.

On windows you can either download the zip file from the homepage, or a binary installer, that is designed to work with the mono installer.

Install Glade Interface Builder

This tools is not required, but can help you to easily create glade xml files for the GUI, using drag-and-drop.
Glade is a free user interface builder for GTK+ and GNOME. It is released under the GNU General Public License (GPL).

Glade can produce C source code itself. In C# you can use it through Glade#, that can read XML files produced by the Interface Builder.

Installation

You can download Glade sources and packages from the glade homepage
A windows port is available from here: Windows Port

The The Mono Handbook/Gnome.NET tutorial


The Mono Handbook - GNOME.NET - Introduction

The Mono Handbook > Introduction GNOME.NET

This part of The Mono Handbook is born out of a vision of a first place to go for High Level Gnome desktop programming.
The idea is to give application programmers an overview of the platform,
information about available development tools and sample code.

Who should read this chapter?

Programmers experienced with c#, who whish to get to understand and
develop desktop applications for the Gnome.NET platform.

How to read this chapter

You can read from the beginning to the end or you can skip around from topic to topic, no problemo.

The Mono Handbook - Gnome.NET tutorial


The Gnome.NET Tutorial

The Mono Handbook > GNOME.NET > C# bindings > GConf

GConf

by Rachel Hestilow (hestilow@ximian.com)

Introduction

Using GConf directly from an application is often inconvenient. Because the configuration key system effectively represents a string-based API, accessing GConf values leaves your application open to runtime errors from a single typo. Even if you store your keys in constants (as is recommended), you still wind up maintaining two lists of keys: one in the schema, and one in your app.

Another problem is that the GConf value types are very limited: string, float, int, bool, and list. When storing common value types such as colors or enumerations, one has to serialize these values to and from strings.

Finally, providing graphical dialogs for your settings can be a very tedious process. For each config element exposed in your UI, you have to manually hook up the "changed" signal on the UI to a custom handler setting the GConf value. Inversely, one must initially populate the dialog based on previously-set GConf values. Complicating all of this is the GNOME HIG, which specifies that all preference dialogs be instant-apply if possible.

GConf# addresses these issues with two new utilities: SchemaGen, and the GConf.PropertyEditors library.

SchemaGen

SchemaGen is a new tool which generates a custom API for the settings in a gconf schema file. Given a schema, it generates two classes, Settings and SettingKeys. Settings provides static properties for each specified gconf setting. These properties map directly to the values in the gconf database. Settings also specifies static events for each setting indicating when the setting has changed, and a generic Changed event which notifies when any of your settings have changed. Finally, for every property in Settings, SchemaGen creates a read-only property of the same name in SettingKeys specifying the GConf key used to access this property. SettingKeys is not needed if you are only using the Settings class, but it is very useful when attaching PropertyEditors, or when accessing GConf directly.

SchemaGen also provides for limited marshalling to and from the GConf value types. It currently defines marshallers for System.Drawing.Color and for enumerations. This is done by specifying a cstype directive in the GConf schema.

Example

First, we need to write a GConf schema specifying our settings.

<gconfschemafile>
 <schemalist>
  <schema>
   <key>/schemas/apps/gconfsharp/sample_app/toolbar_alignment</key>
   <applyto>/apps/gconfsharp/sample_app/toolbar_alignment</applyto>
   <owner>sample_app</owner>
   <type>string</type>
   <cstype class="Sample.Alignment">enum</cstype>
   <locale name="C">
    <short>Toolbar alignment</short>
    <long>Where the toolbar should be. Can be one of Top, Bottom, Left, Right.</long>
   </locale>
   <default>Top</default>
  </schema>
  <schema>
   <key>/schemas/apps/gconfsharp/sample_app/text_color</key>
   <applyto>/apps/gconfsharp/sample_app/text_color</applyto>
   <owner>sample_app</owner>
   <type>string</type>
   <cstype>color</cstype>
   <locale name="C">
    <short>Text color</short>
    <long>Text color</long>
   </locale>
   <default>#000000</default>
  </schema>
  <schema>
   <key>/schemas/apps/gconfsharp/sample_app/enable_text_color</key>
   <applyto>/apps/gconfsharp/sample_app/enable_text_color</applyto>
   <owner>sample_app</owner>
   <type>bool</type>
   <locale name="C">
    <short>Show colored text</short>
    <long>Show colored text</long>
   </locale>
   <default>false</default>
  </schema>
 </schemalist>
</gconfschemafile>

Note how we specify both the cstype and type for the enum and color. This is because GConf doesn't know anything about cstype.

We save this to sample.schema, and install it with the command:

env GCONF_CONFIG_SOURCE="" gconftool-2 --makefile-install-rule sample.schema

GConf generates a warning because it doesn't recognize cstype, but it is nothing to worry about.

We're now ready to run SchemaGen. Installing the schema before running SchemaGen is not required, but you should make sure to install it before running your application, because GConf# will throw an exception if GConf can't find your settings.

SchemaGen's full executable name is gconfsharp-schemagen. It takes a namespace and the schema filename as parameters, and outputs to the console. Here is the command used to generate Settings.cs for sample.schema:

gconfsharp-schemagen Sample sample.schema > Settings.cs

Now we're ready to write a small program using our new settings.

namespace Sample
{
   using System;
   using System.Drawing;

   public enum Alignment
   {
     Top,
     Bottom,
     Left,
     Right
   }

   class X
   {
      public static void Main (string args[])
      {
         Alignment align = Settings.ToolbarAlignment;
         Console.WriteLine ("Alignment is: {0}", align);
     Settings.ToolbarAlignment = Left;
     Console.WriteLine ("Color is: {0}", Settings.TextColor);
     Console.WriteLine ("Color is enabled: {0}", Settings.TextEnableColor);
      }
   }
}

As you can see, our GConf settings are now nicely encapsulated, and are as easy to access as any other .NET properties.

Property Editors

Property Editors are objects which act as intermediaries between GConf and Gtk+ widgets. They are analoguous to the Controller of the MVC design pattern. Property editors do two things:

  • They listen to GConf notifications, and update the widget to reflect any changes in a GConf setting.
  • They connect to the various "changed" signals on a widget, and update GConf to reflect the widget's current state.

This means that the widget and GConf are always in sync, no matter if the value is set through Gtk+ or through GConf. GConf# defines a number of Property Editors which correspond to common widget/setting combinations -- for example, a CheckButton representing a boolean setting.

GConf# also provides a utility class called EditorShell. EditorShell exposes a simple API to automatically construct PropertyEditors for a Glade UI.

As a historical note, and in the interests of giving credit where credit is due, it should be noted that GConf Property Editors are not unique to GConf#. They were originally conceived and implemented by Bradford Hovinen for use in the GNOME Control Center. Although the APIs are somewhat similar, the original version was written in C and was limited to internal use in the Control Center. Similarly, Hovinen's work on GConf Property Editors were based on Dietmar Maurer's Bonobo-Conf Property Editors.

Example

For this example we'll assume you have written a Glade UI for the settings in the previous example. It employs three elements: an option menu named "toolbar_menu", a checkbox named "enable_check", and a color picker named "colorpicker". Given our Glade.XML object, all we have to do is set up the EditorShell.

Glade.XML gxml = ...
GConf.PropertyEditors.EditorShell shell = new GConf.PropertyEditors.EditorShell (gxml);

shell.Add (SettingKeys.ToolbarAlignment, "toolbar_menu", typeof (Sample.Alignment));
shell.Add (SettingKeys.EnableTextColor, "enable_check");
shell.Add (SettingKeys.TextColor, "colorpicker");

That's all that is needed to implement the preferences dialog. Note how we didn't have to specify what type of property editor to use. The EditorShell uses introspection to create the correct Property Editor for all the types of widgets it knows about. Also note that because ToolbarAlignment is an enum, we had to pass its type in so that the Property Editor can store its value correctly. By default, Property Editors assume that the order of elements in an OptionMenu (or RadioButton) correspond to the order of values in an enum. If this is not the case, you can pass in an additional parameter to Add: an array of integers, each array element being the integer representation of an enum value. This array represents the order of values in your GUI element.

Now, a really good preference dialog would "ghost out" the color picker if the "Enable text color" option is disabled. This requires a small addition to our previous code:

shell.AddGuard (SettingKeys.EnableTextColor, "color_box");

Again, for the purposes of the example, "color_box" is the name of the HBox containing the label and color picker corresponding to TextColor.

The Mono Handbook - © Copyright 2002 by Johannes Roith & Martin Willemoes Hansen


The Gnome.NET Tutorial

The Mono Handbook > GNOME.NET > C# bindings > Glade#

Glade - Rapid Application Development with Gnome 2

by Johannes Roith (johannes@jroith.de)

Contents

  • 1. Introduction
  • 2. Creating the UI
  • 3. It's time to start coding
  • 4. Available Widgets
  • 5. Using Glade in our Project
  • 6. Didn't you say something about this self-contained thing?

    Introduction

     In the previous chapter, you learned how create a Gnome GUI. If you've worked with Visual Studio, Delphi/Kylix or Visual Basic you might be missing the easy way of dragging widgets on forms.

    You're right, after all, what we want to do is creating good applications faster with mono. Development , where the programmer gets assistance in non-coding tasks from (visual) tools and focuses on the real work is called RAD - Rapid Application Development. Gnome offers a set of such technologies, known as Glade.

    Glade consists of 2 part:
    • Glade - a grafical editor to create forms and save them in XML files.
    • libglade (called Glade# in Gtk#) - a library to load the XML at runtime
      and dynamically create the form.
    That means, the user will need have libglade installed, and the xml file must be distributed with the application. Glade# is the C# binding for libglade and even offers some advanced features - like self-contained glade files - that are only available in Gtk#.

    Language independence has always been a goal in Gnome Development. For that reason the Glade Interface Builder exports xml, that can be used with any language with glade bindings. This benefit is bought with little more effort compared to Visual Studio, as the code can't be generated automatically.

    Creating the UI
    Before we try to use glade with our Project, first get some experience with it. Fire up the Glade Interface Designer. You will be greeted by three windows: the main window, a properites and a palette window, containing icons. Click Project - New and select "Gnome Project".

    To create a new window click on the first icon in the palette-window. The new window is shown in the list. You can modify Type, Position, Caption, and other things in the Properties window.

    If you want your application to quit, if the window is closed you'll have to connect a signal with an event handler. Select "Signals" and add a handler for "delete_event" and call it "OnWindowDeleteEvent".

    Take a button and drop it on the window. As you know, gtk+ has the concept of invisible boxes, to position widgets, and for that reason the button will fill the whole window. Modify some properties and add a signal handler for "clicked" and call it "OnButton1Clicked".

    Save to a new directory. Glade will put 2 files there: [projectname].glade and [projectname].gladep, wich does only save some information for the Interface Builder. The "interesting" file is the .glade file, that you can open in any text editor. It's plain XML and looks like that:

    <?xml version="1.0" standalone="no"?> <!--*- mode: xml -*-->
<!DOCTYPE glade-interface SYSTEM "http://glade.gnome.org/glade-2.0.dtd">

<glade-interface>

<widget class="GtkWindow" id="window2">
  <property name="visible">True</property>
  <property name="title" translatable="yes">window2</property>
  <property name="type">GTK_WINDOW_TOPLEVEL</property>
  <property name="window_position">GTK_WIN_POS_NONE</property>
  <property name="modal">False</property>
  <property name="resizable">True</property>
  <property name="destroy_with_parent">False</property>

  <child>
    <widget class="GtkButton" id="button1">
      <property name="border_width">10</property>
      <property name="visible">True</property>
      <property name="can_focus">True</property>
      <property name="label" translatable="yes">button1</property>
      <property name="use_underline">True</property>
      <property name="relief">GTK_RELIEF_NORMAL</property>
    </widget>
  </child>
</widget>

</glade-interface>

    It's time to start coding

     The code is similiar to previous chapters. What has changed is, that most of the code is move to the GladeTest constructor. That's because the main-method is static and therefor doesn't belong to any class. Altough possible, moving code to Main() would only lead to more complicated code.
    namespace GladeSamples {
    using System;

    using Gtk;
    using Gnome;
    using Glade;
    using GtkSharp;

        public class GladeTest
    {
        public static void Main (string[] args)
        {
            new GladeTest(args);
        }

        /* If you want to access the glade objects you have to "import" them.
         * This is not required, but else you can only work with the
         * pre-defined signal handlers */
        [Glade.Widget]
        Button button1;

        public GladeTest (string[] args)
        {
            Application.Init();

            /* This loads the glade file glade.glade,
             * selects window2 and connects it to the current object,
             * which is the class GladeTest here. */
            Glade.XML gxml = new Glade.XML ("file.glade", "window2", null);
            gxml.Autoconnect (this);

            button1.BorderWidth=10;

            Application.Run();
        }

        /* Connect the Signals defined in Glade */
        public void OnWindowDeleteEvent (object o, DeleteEventArgs args)
        {
            Application.Quit ();
            args.RetVal = true;
        }

        public void OnButton1Clicked (System.Object obj, EventArgs e)
        {
            Console.WriteLine ("Button 1 clicked");
        }
    }
}

    compile with:
    mcs /unsafe -r gtk-sharp.dll -r glade-sharp.dll glade.cs

    Of course, include the Gnome and Glade namespaces.
    using Gnome;
using Glade;
    The first part inits the Application.
    Then the glade xml file is connected. The first param is the file, the second the main widget (here: the window). The second line connects gxml to the current object.
    Glade.XML gxml = new Glade.XML ("file.glade", "window2", null);
gxml.Autoconnect (this);
    Altough glade will show all widgets and cares about the events defined, most likely you will want to change properties, or add events during the runtime. For that to work you have to connect a new object to the glade widget. This example also sets the BorderWidth.
    [Glade.Widget]
Button button1;
button1.BorderWidth=10;
    That's it.

    Available Widgets

     All available widgets are devided in 4 categories. If you want your application to be independent of gnome and portable to windows, or Mac OS X, use only Gtk+ and Gtk+ Additional. If you don't need that flexibility I strongly encourage you to make also use of the Gnome category. That includes Font-Selector, Druids, Iconlists and other useful things.

    Glade can be extened, for example gnome-db extensions are available.

    Using Glade in our Project

     After explaining how it works, like in the other chapters we want to go on with our little Project, introducing the new learned technology and extending the knowledge. This chapter removes the few UI bits, done by hand and adds an Interface using Glade.

    [TODO]

    Didn't you say something about this self-contained thing?

     Yes, I did. And it's quite a good feature. Now, that we're using Glade our application consists not only of 1, but 2 files. Luckily, the CLR has a way, to embedd any file in the executable, like images or text files. Glade offer an additional constructor to load the glade file from a resource, so you don't have to distribute it. The only difference is the "null" before the filename.
    Glade.XML gxml = new Glade.XML (null, "file.glade", "window2", null);
gxml.Autoconnect (this);
    You have then to compile the file in, with the resource switch.
    mcs /unsafe /resource:glade.glade -r gtk-sharp.dll -r glade-sharp.dll  glade.cs


The Mono Handbook - GNOME.NET - Gnome#

The Mono Handbook > GNOME.NET > C# bindings > Gnome#

Gnome#

Contents

  • 1. Introduction
  • 2. Getting Started
    • 2.1 Hello World in Gnome#
    • 2.2 Adding Contents

  • 3. Popular & useful widgets
    • 3.1 The "About" dialog
    • 3.2 Druid

  • 4. The Gnome Canvas
    • 4.1 Introduction
    • 4.2 Hello World
    • 4.3 CanvasElement: Ellipse

  • 5. Credits

Credits

Author: Charles Iliya Krempeaux (charles at reptile.ca)
Author: Martin Willemoes Hansen (mwh at sysrq.dk)
Author: Johannes Roith (johannes at jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith & Martin Willemoes Hansen


The Mono Handbook - Gstreamer

The Mono Handbook > GNOME.NET > C# bindings > GStreamer

GStreamer

Contents

  • 1. Introduction
  • 2. Basic concepts
    • 2.1 Initializing
    • 2.2 GstElement
    • 2.3 Plugins
    • 2.4 GstPad
    • 2.5 Connecting elements
    • 2.6 Bins
    • 2.7 Buffers
    • 2.8 Element states
  • 3. Building an application
  • 4. Advanced concepts
  • 5. Xml in GStreamer

Credits

Author: Johannes Roith (johannes@jroith.de)
Misc: Heavily based on the gstreamer tutorial by Wim Taymans, Steve Baker, Andy Wingo

The Mono Handbook - © Copyright 2002 by Johannes Roith & Martin Willemoes Hansen


The Mono Handbook - GNOME.NET - GTK#

The Mono Handbook > GNOME.NET > C# bindings > GTK#

GTK#

Contents

  • 1. Introduction
  • 2. Getting Started
    • 2.1. Hello World in GTK
    • 2.2. Events
    • 2.3. Stepping Through Hello World
  • 3. Packing Widgets
    • 3.1. Theory of Packing Widgets
    • 3.2. Details of Boxes (!)
    • 3.3. Packing Demonstration Program
    • 3.4. Packing Using Tables(!)
    • 3.5. Table Packing Example
  • 4. Widget Overview
    • 4.1. Casting (!)
    • 4.2. Widget Hierarchy
    • 4.3. Widgets Without Windows
  • 7. The Button Widget
    • 7.1. Normal Buttons
    • 7.2. Toggle Buttons
    • 7.3. Check Buttons
    • 7.4. Radio Buttons
  • 8. Adjustments
    • 8.1. Creating an Adjustment
    • 8.2. Using Adjustments the Easy Way
    • 8.3. Adjustment Internals (!)
  • 9. Range Widgets
    • 9.1. Scrollbar Widgets
    • 9.2. Scale Widgets (!)
    • 9.2.1. Creating a Scale Widget (!)
    • 9.2.2. Functions and Signals (well, functions, at least) (!)
    • 9.3. Common Range Functions (!)
    • 9.3.1. Setting the Update Policy (!)
    • 9.3.2. Getting and Setting Adjustments (!)
    • 9.4. Key and Mouse bindings
    • 9.5. Example
  • 10. Miscellaneous Widgets
    • 10.1. Labels
    • 10.2. Arrows
    • 10.3. The Tooltips Object
    • 10.4. Progress Bars(*)
    • 10.5. Dialogs
    • 10.6. Rulers(*)
    • 10.7. Statusbars(*)
    • 10.8. Text Entries(*)
    • 10.9. Spin Buttons(*)
    • 10.10. Combo Box(*)
    • 10.11. Calendar(*)
    • 10.12. Color Selection(*)
    • 10.13. File Selections
    • 10.14. Tree/list control
  • 11. Container Widgets
    • 11.1. The EventBox
    • 11.2. The Alignment widget
    • 11.3. Fixed Container
    • 11.4. Layout Container
    • 11.5. Frames
    • 11.6. Aspect Frames
    • 11.7. Paned Window Widgets
    • 11.8. Viewports
    • 11.9. Scrolled Windows
    • 11.10. Button Boxes
    • 11.11. Toolbar
    • 11.12. Notebooks

    The following is pushed back. Let's focus on getting 1 - 11 done. Other stuff can wait.

  • 12. Menu Widget
    • 12.1. Manual Menu Creation
    • 12.2. Manual Menu Example
    • 12.3. Using ItemFactory
    • 12.3.1. ItemFactory entries
    • 12.3.2. Creating an ItemFactory
    • 12.3.3. Making use of the menu and its menu items
    • 12.4. Item Factory Example
  • 13. Undocumented Widgets (-- Removed temporary --)
  • 14. Setting Widget Attributes
  • 15. Timeouts, IO and Idle Functions
    • 15.1. Timeouts
    • 15.2. Monitoring IO
    • 15.3. Idle Functions
  • 16. Advanced Event and Signal Handling
    • 16.1. Signal Functions
    • 16.1.1. Connecting and Disconnecting Signal Handlers
    • 16.1.2. Blocking and Unblocking Signal Handlers
    • 16.1.3. Emitting and Stopping Signals
    • 16.2. Signal Emission and Propagation
  • 17. Managing Selections
    • 17.1. Overview
    • 17.2. Retrieving the selection
    • 17.3. Supplying the selection
  • 18. Drag-and-drop (DND)
    • 18.1. Overview
    • 18.2. Properties
    • 18.3. Functions
    • 18.3.1. Setting up the source widget
    • 18.3.2. Signals on the source widget:
    • 18.3.3. Setting up a destination widget:
    • 18.3.4. Signals on the destination widget:
  • 19. GLib
    • 19.1. Definitions
    • 19.2. Doubly Linked Lists
    • 19.3. Singly Linked Lists
    • 19.4. Memory Management
    • 19.5. Timers
    • 19.6. String Handling
    • 19.7. Utility and Error Functions
  • 20. GTK's rc Files
    • 20.1. Functions For rc Files
    • 20.2. GTK's rc File Format
    • 20.3. Example rc file
  • 21. Writing Your Own Widgets (-- Removed temporary --)
  • 22. Scribble, A Simple Example Drawing Program
    • 22.1. Overview
    • 22.2. Event Handling
    • 22.3. The DrawingArea Widget, And Drawing
    • 22.4. Adding XInput support
    • 22.4.1. Enabling extended device information
    • 22.4.2. Using extended device information
    • 22.4.3. Finding out more about a device
    • 22.4.4. Further sophistications
  • Credits
  • A. GTK Signals
  • A.1. Gtk.Object
  • A.2. Gtk.Widget
  • A.3. Gtk.Data
  • A.4. Gtk.Container
  • A.5. Gtk.Calendar
  • A.6. Gtk.Editable
  • A.7. Gtk.Notebook
  • A.8. Gtk.List
  • A.9. Gtk.MenuShell
  • A.10. Gtk.Toolbar
  • A.11. Gtk.Button
  • A.12. Gtk.Item
  • A.13. Gtk.Window
  • A.14. Gtk.HandleBox
  • A.15. Gtk.ToggleButton
  • A.16. Gtk.MenuItem
  • A.17. Gtk.CheckMenuItem
  • A.18. Gtk.InputDialog
  • A.19. Gtk.ColorSelection
  • A.20. Gtk.StatusBar
  • A.21. Gtk.Curve
  • A.22. Gtk.Adjustment
  • B. GDK Event Types
  • C. Code Examples

Credits

 Author: Johannes Roith (johannes@jroith.de)
Author: Alejandro Sánchez Acosta (raciel@es.gnu.org)
Misc: This chapter does use some content from the GTK+ Tutorial by Tony Gale, Ian Main, & the GTK team

The Mono Handbook - © Copyright 2002 by Johannes Roith & Martin Willemoes Hansen


The Mono Handbook - GNOME.NET - Rsvg#

The Mono Handbook > GNOME.NET > C# bindings > Rsvg#

Rsvg#

Contents

  • 1. Introduction
  • 2. Background
    • 2.1. Vector Graphics vs. Pixmap Graphics
  • 3. Getting Started
    • 3.1. Hello World in Rsvg#
  • 4. Something Useful
    • 4.1 Creating an SVG File Viewer
  • 5. Credits

Credits

Author: Charles Iliya Krempeaux (charles at reptile.ca)

The Mono Handbook - Copyright © 2002-2003 Mono Handbook Team


The Mono Handbook - GNOME.NET - Gtk# Documentation

The Mono Handbook >Gtk# Documentation GNOME.NET

Gtk# Documentation

DO NOTE EDIT!! This file is taken from Rachel Hestilow's documentation and is generated automatically.
It's from June 25 2002, a bit outdated, but there will be an update.

Documentation on the following assemblies is available:
  • glib
  • atk
  • pango
  • gdk
  • gtk
  • gnome

© Copyright 2002 by Johannes Roith & Martin Willemoes Hansen


The Mono Handbook - GNOME.NET - Same Gnome

The Mono Handbook > Same Gnome GNOME.NET

by suggestion of Miguel de Icaza:

How to build a full application

  • 1. Creating your UI using glade.
  • 2. Connecting the Glade code to C#
  • 3. Making the program go.
  • 4. Using the Canvas/Drawing.
  • 5. Creating a configuration dialog box with Glade.
  • 6. Loading configuration settings from GConf.
  • 7. Storing scores on a database.
  • 8. Internationalization.
  • 9. Adding an About Box and a logo
  • 10. Making the executable self-contained
  • 11. Creating a custom widget.
The Mono Handbook - Gnome.NET tutorial


The Mono Handbook - Eclipse

The Mono Handbook > IDEs > Eclipse

Eclipse for developing Mono applications

Contents

  1. Introduction
  2. Installation
  3. Using Eclipse
  4. Credits

Introduction

When you visit Eclipse's web page, you may wonder what Eclipse is: some Java library, an IDE, just and editor? The answer is: all of the three. The Eclipse Platform (as this white paper states) is designed for building integrated development environments (IDEs) that can be used to create applications as diverse as web sites, embedded Java programs, C++ programs, and Enterprise JavaBeans. What does it mean? That apart from initially having just an editor with a few shortcuts for doing several common programming tasks easier, you can extend the IDE to any language creating plug-ins that can run on any OS that Eclipse is ported to.

With the multi-language nature of Mono, this seems to be a very important project for future development of applications in this framework. But even now it can be a very helpful IDE for developing C# applications. There is already a basic C# plug-in for Eclipse, that although lacking some interesting features, implements auto indenting and syntax highlighting for this language. Another extra point is that Eclipse can use the Gtk2 toolkit on GNU/Linux. This is great for Gnome users, as it adapts better to the environment.

Installation

First things first. You must get Eclipse from the download section. Choose any release you want to download and you'll be presented with different packages of the Eclipse platform. Unless you are planning to work in a plug-in for Eclipse, downloading the Platform Runtime Binary for your OS will suffice (and will save you lots of bandwith). Also remember that you will need a Java runtime environment (JRE), that you can get following the instructions in the download page, or from Sun's site.

The installation of the Eclipse platform is very quick and simple. You just have to unzip the downloaded file in a directory, and from there running the eclipse executable (you must have the JRE path in your PATH environment variable). The loading process is rather slow, but not slower than a few other native applications out there.

Next you will want to install Improve's C# plug-in. Follow the instructions on the plug-in site.

Optionally, if you plan to be working on C/C++ code any time, you can download the C Development Environment from the Tools Project. Just unzipping the plug-in on the Eclipse directory will suffice.

Using Eclipse

You can start a new C# project just by going to "File->New->Project" and choosing 'Simple' on the dialog presented. Your newly created project will appear at the Navigator on the left. You can now start creating the layout of your project. You can do this by using the context menu on the Navigator or by using the "File->New" menu. To create a C# file you must use "New->C# File". The file will be filled with a simple template of a C# program.

Let's say you want to import the newly created project to a CVS repository you have access to. On the context menu of the Navigator you have the "Team->Share Project" item. By clicking on it you will get the chance to configure the CVS repository settings, and then you will be presented with the Synchronize view to see the files that will be added, and then you can choose which ones to add to version control and which to ignore.

To check out a CVS module follow this procedure. Go to "Window->Open Perspective->CVS Repository Exploring", then right click on the "CVS Repositories" window and choose "New->Repository Location" and fill in the dialog with your login settings. You can then expand the CVS tree, right-click on a directory and choose "Check Out As Project".

From now on you can experiment with the rest of the features. You will be surprised at how stable and intuitive this application is.

Acknowledge: some things were used from this post on www.gnomedesktop.org.

Credits

 Author: Pablo Baena
© Copyright 2002 by Johannes Roith & Martin Willemoes Hansen


The Mono Handbook - Emacs

The Mono Handbook > IDEs > Emacs

Emacs

Contents

  1. Introduction
  2. Modes
  3. Credits

Introduction

 Emacs is a general purpose editor ie. not an IDE specificaly designed for .net and c#.
It is my experience that Emacs along with Glade and the Mono tools makes a powerfull and productive development environment.

Strengths about emacs:

  • Has support for almost every programming language you can mention
  • Is portable and thus available at all major computing platforms.
  • Easily extendable.
  • Its free software.
For more information about emacs refer to this

Modes

 By default there is no c# mode available in emacs (21.2). Luckily there is some third party modes available here:
  • davh.dk
  • www.cybercom.net

Credits

 Author: Martin Willemoes Hansen
© Copyright 2002 by Johannes Roith & Martin Willemoes Hansen


The Mono Handbook - SharpDevelop

The Mono Handbook > IDEs > SharpDevelop

SharpDevelop

Contents

  1. Introduction
  2. Installation
  3. Credits

Introduction

 #develop (short for SharpDevelop) is a free IDE for C# and VB.NET projects on Microsoft's .NET platform. It is open-source (GPL). While Eclipse is perhaps a bit more feature rich SharpDevlop is really fun to work with. The only disadvantage is, that it doesn't run on Linux/Mono, because it builds on System.Windows.Forms, that are not ready, yet.

Strengths about SharpDevelop:

  • Completely written in C#
  • Compile C# and VB.NET in the IDE out-of-the-box
  • Open source, GPL licensed
  • Lightweight IDE
  • Code completion
  • Forms designer
  • User interface translated to many languages
  • Everything templated: add new project or file types, or even compilers to SharpDevelop
  • Write C#, ASP.NET, ADO.NET, XML, HTML code
  • Project or File-based development (Project Scout & File Scout)
  • Rich project options
  • Syntax highlighting for C#, HTML, ASP, ASP.NET, VBScript, VB.NET, XML
  • Intelligent braces
  • Bookmark your code
  • Code template support
  • Feature-rich Find & Replace dialogs
  • Easily extensible with external tools
  • Easily extensible with Plug-Ins
  • ... and much more
For more information about SharpDevelop and download refer to this

Installation

 #Develop comes with a double-click installer on windows. It requires the .NET Framework.

Credits

Author: Johannes Roith
The Mono Handbook | © Copyright 2003 see Credits | License | Credits


The Mono Handbook - GNOME.NET - Introduction

The Mono Handbook > Choosing an Integrated Development Environment (IDE)

Choosing an Integrated Development Environment (IDE)

by Johannes Roith (johannes@jroith.de)

Available Choices

Currently there are 3 free, GPLed development enviroments available for use with mono.
  • Emacs
  • Eclipse
  • SharpDevelop

Comparing

Everyone has his own needs, but at least one IDE should fit your needs. I've put together the pros and cons of all of them.

Emacs

+ very powerful
+ multiplatform

- difficult for newcomer

Eclipse

+ powerful
+ multiplatform
+ easy to use
+ widely proven

- needs big and proprietary SUN Java JDK
- very slow on a PII 350 and maybe even on new machines

SharpDevelop

+ powerful
+ easy to use
+ perfectly suited for C#
+ Many designers and assistants.

- only runs on windows.

The Mono Handbook | Mono Homepage | Credits | License


The Mono Handbook - GNOME.NET - Introduction

The Mono Handbook > Installation on FreeBSD

Installation on FreeBSD

by Johannes Roith (johannes@jroith.de)

Mono is maintained in ports/lang/mono.

cd /usr/ports/lang/mono
make
make install

make clean

© Copyright 2002 by Johannes Roith & Martin Willemoes Hansen


The Mono Handbook - GNOME.NET - Introduction

The Mono Handbook > Installation on Linux

Installation on Linux

Contents

  1. Binary install on RedHat & RPM based systems
  2. Binary install on Debian
  3. Install from Source
  4. Garbage Collection
  5. Linux Kernel Support for Binaries
  6. Credits

Binary install on RedHat & RPM based systems

To get Mono running you will need to download rpms made for your distribution from a few sources.
  • From http://www.go-mono.org/download
    libgc-6.1-1.i386.rpm
libgc-devel-6.1-1.i386.rpm
mono-0.23-1.i386.rpm
mono-devel-0.23-1.i386.rpm
  • If you want to use GTK#, from ftp://ftp.gnome-db.org/pub/gnome-db/
    libgda-0.10.0-1.i386.rpm
libgnomedb-0.10.0-1.i386.rpm
    And from http://gtk-sharp.sourceforge.net/
    gtk-sharp-0.7-1.i386.rpm

Binary install on Debian

Alp Toker maintains the Mono packages for Debian GNU/Linux and Debian-based systems running the stable and unstable distribution across several harware architectures.

To make use of the archive, append these lines to /etc/apt/sources.list and run apt-get update:

Debian GNU/Linux 3.0 stable (woody)

deb http://www.debianplanet.org/mono stable main
deb-src http://www.debianplanet.org/mono stable main

Debian GNU/Linux unstable (sid)

deb http://www.debianplanet.org/mono unstable main
deb-src http://www.debianplanet.org/mono unstable main

Installation and usage

The runtime and its dependencies can be downloaded and installed using apt-get install mono. On platforms that are not yet supported by the faster JIT engine, the interpreter will be automatically installed and set as the default runtime.

Sources can be downloaded using apt-get source packagename. Other packages worth mentioning are gtk-sharp, the GUI toolkit, and csharp-elisp, a C# mode for emacs. The complete list of packages can be searched using apt-cache search keywords. See the Mono for Debian site for further information.

Install from Source

There are several ways to get Mono running on your computer. This document will discuss only one of those: downloading the source tarball and utilising the make utilities to get mono up and running. There is only one mono package to worry about if you are just after a 'base' install of mono: the mono runtime. This package, found under the name "mono-x.xx" has got a compiled version of the compiler built in.

You'll be able to complete everything in this document if you just install the runtime, but taking a look at the compiler package is well worth the effort. The compiler is written in C# and is 'self hosting' which means it is able to compile itself.

As of this moment, it is my understanding that there are still some issues with the 'self hosting' bit of the compiler on linux, although this is expected to work in later versions of mono. If you are just interested in finding out how mono will work under linux, I would not worry about the self-hosting bit for now. The self-hosting of the compiler will be the topic of a future howto.

See the mono download site for the source of the tarballs.

This page also lists the current versions of the software mono depends on. Make sure that your system has all the required versions, otherwise mono won't compile.

At a minimum for mono 0.12, you'll need to:

  • download and install pkg-config.

  • download and install glib 1.3.

Installing the tarballs is done via GNU autoconf and automake. The general upshot of running autoconf and automake is that you can type ./configure and then make to do the build. Typing make install completes the installation of mono on your system.

To build the mono runtime package, unzip the tarball to some useful location. I tend to use /usr/src as the location, but you could really do it anywhere. For the install process, it is also a good idea to be 'root'. The installation process will shuttle some executables into /usr/local/bin (more about that later).

Unzipping the tarballs will have created two directories in /usr/src/, one called something like mono-x.xx and the other mcs-x.xx. The one called 'mono' is the runtime environment, and this contains all that is initially needed to run mono and investigate its inner workings.

To start building the mono runtime, first type ./configure. You will see an output like this:

[root@taurus mono-0.12]# ./configure
loading cache ./config.cache
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
checking for a BSD compatible install... (cached) /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... (cached) yes
checking for working aclocal... found

snip ....

checking BASE_DEPENDENCIES_CFLAGS...  -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
checking BASE_DEPENDENCIES_LIBS...  -lglib-2.0
checking for GC_malloc in -lgc... (cached) no
configure: warning: Compiling mono without GC.
checking if off_t is 64 bits wide... no
checking if _FILE_OFFSET_BITS=64 gives 64 bit off_t... ok

snip ...

creating Makefile
creating mono/Makefile
creating mono/utils/Makefile
creating mono/metadata/Makefile
creating mono/dis/Makefile
creating mono/cil/Makefile
creating mono/arch/Makefile
creating mono/os/Makefile
creating mono/os/win32/Makefile
creating mono/os/unix/Makefile
creating mono/arch/x86/Makefile
creating mono/arch/ppc/Makefile
creating mono/arch/sparc/Makefile
creating mono/arch/arm/Makefile
creating mono/interpreter/Makefile
creating mono/tests/Makefile
creating mono/benchmark/Makefile
creating mono/monoburg/Makefile
creating mono/monograph/Makefile
creating mono/jit/Makefile
creating mono/io-layer/Makefile
creating mono/handles/Makefile
creating runtime/Makefile
creating scripts/Makefile
creating man/Makefile
creating doc/Makefile
creating docs/Makefile
creating config.h
config.h is unchanged

        GC:     auto

[root@taurus mono-0.12]#

This means that the configure script has now created all the makefiles necessary to complete the build on your system. Note the "GC: auto" at the end of the list of commands. GC stands for "garbage collection" and it will be addressed in a later section of this document.

You are now ready to start the mono "build" process. To kick this off, you can type make at the command prompt. You'll see something like this:

[root@taurus mono-0.12]# make
make  all-recursive
make[1]: Entering directory `/usr/src/mono-0.12'
Making all in mono
make[2]: Entering directory `/usr/src/mono-0.12/mono'
Making all in utils
make[3]: Entering directory `/usr/src/mono-0.12/mono/utils'
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include   -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include   -I../.. -I../../mono
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE   -g -Wall
-Wunused -Wmissing-prototypes -Wmissing-declarations
-Wstrict-prototypes  -Wmissing-prototypes -Wnested-externs
-Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings
-c mono-hash.c

and this will continue for a while. On my 1 GHz Duron with 256 MB of RAM the total build process takes about three minutes. All the terrible flags after gcc have essentially been set by the configure script and there is no need to worry about these.

To finally install mono, you can type make install to get a working version of mono. This command will copy the scripts that run the executables to a place where the operating system will be ale to find them. This location is /usr/local/bin on my system.

Garbage Collection

To make the mint interpreter work with garbage collection, you first need to install a garbage collection package on your system. Mono works with Boehm Garbage collection, which is found at http://www.hpl.hp.com/personal/Hans_Boehm/gc/.

To get garbage collection to work, I downloaded the source tarball into /usr/src/ and typed ./configure followed by make and make install.

There is one glitch to work around. The header file for the garbage collection gc.h is found in the /usr/src/gc6.0/include directory (at least on my system). The mono build process will break on this location: it is looking for the header file in some other place called /usr/include/gc/ and won't be able to find the correct header file.

The solution is to build a symbolic link between these two locations as follows

[root@taurus include]# ln -s /usr/src/gc6.0/include/ /usr/include/gc

after which you'll be able to list the directory contents as if they were in /usr/include

[root@taurus include]# pwd
/usr/include
[root@taurus include]# ls /usr/include/gc
cord.h                gc_backptr.h  gc_inline.h             javaxfc.h
ec.h                  gc_cpp.h      gc_local_alloc.h        leak_detector.h
gc                    gc_gcj.h      gc_mark.h               new_gc_alloc.h
gc_alloc.h            gc.h          gc_pthread_redirects.h  private
gc_amiga_redirects.h  gc_inl.h      gc_typed.h              weakpointer.h
[root@taurus include]#

To get mono to work with garbage collection, you'll have to rebuild the environment. This is done easily by typing make distclean to clean up any existing executables.

Continue the build by typing ./configure, and look at the last line. It should read:

snip...

creating config.h

        GC:     boehm

[root@taurus mono-0.12]#

The GC: boehm tells you that garbage collection has been turned on. Now to compile the runtime, you type make and make install as previously.

You now have mono working with Garbage Collection.

Although my experimentation is incomplete as of this time, I have found some issues with running Garbage Collection continuously, and my recommendation would be to turn it off for now.

To turn garbage collection off again, you have to go to the /usr/src directory where you extracted the tarball. Enter the gc6.0 directory and type make uninstall to uninstall Garbage Collection. Then in your mono directory, type make distclean followed by ./configure, make and make install.

Linux kernel support for binaries

You can make your mono .exe files executable by following these steps:

  1. Enabling binfmt in your kernel.
  2. Adding the line below to your fstab:
    binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc none
  3. On boot run the cmd below:
    echo ':CLR:M::MZ::/usr/bin/mono:' > /proc/sys/fs/binfmt_misc/register
  4. chmod +x foobar.exe
Another way to accomplish the above is to wrap the
mono .exe file it in a shell script, like this:
#!/bin/sh
/usr/bin/mono "$@"
Of course you should change /usr/bin/mono to the path your mono is. To get it done easily just replace /usr/bin/mono with the output of: which mono

Credits

 Author: Hinne Hettema
Author: Jaime Anguiano Olarra
Author: Johannes Roith johannes at jroith.de
Author: Martin Willemoes Hansen

The Mono Handbook | Mono Homepage | Credits | License


The Mono Handbook - GNOME.NET - Introduction

The Mono Handbook > Installation on MacOS X

Installation on MacOS X

by Johannes Roith (johannes@jroith.de)

What you need to start

Apple Development (Free registration required).
Fink at Sourceforge.

First of all you'll need to make sure you've got the Apple development tools installed. If you have got them on CD install them, if not you'll have to go to the Apple web site and get them from there. A free registration is required.

Next you need to get a couple of other things:

  • pkg-config
  • glib2

The easiest way to get these is by using Fink which makes it very easy. Get the latest version of fink, and run it.

sudo dselect

Find the packages (pkg-config is installed as part of fink) and let fink do it's job.

Mono

Mono website: downloads, help, and info.

Get the 0.18 release of Mono from the Mono web site. You need the mono-0.18.tar.gz source. Unpack the files into a directory of your choice, *nix people might like to choose /usr/local/src, Mac people might like Documents/mono, it doesn't make any difference.

A few things to note first... mono doesn't actually work on OS X (yet), but mint does (a little anyway). So you should be able to compile most C# programs that compile with mono, but don't expect everything to work.

Patch for OS X

Download the patch, and get the os x tramp.c file.

There are few changes required to get mono to work on OS X. Easy way to do this is to download the patch file from here and apply it.

patch -p1 < mono-0.18-osx.diff.patch

Second, you need a different tramp.c file. After you've applied the patch replace the mono-0.18/mono/arch/ppc/tramp.c file with the new one. (Big thanks to John Duncan for this file)

cp tramp-macosx.c mono-0.18/mono/arch/ppc/tramp.c

Compile Mono

Now it starts to get easy.... From the mono directory just type:

./configure --prefix=/usr/local

If you want mono installed somewhere other than /usr/local, put something else after the --prefix. Next type:

make

Install Mono

MCS compiler wrapper.

Another easy bit (providing all the above went ok...)

sudo make install

To get mcs (the Mono C# Compiler) to work, you will need to change the mcs file that gets created in /usr/local/bin. It tries to use mono which doesn't compile so either change the mcs file to look as shown below:

#!/bin/sh
/usr/local/bin/mint /usr/local/bin/mcs.exe "$@"

Or you can download it from here. Make sure the file has execute permissions.

chmod a+x mcs

Test Your Installation

Hello World C# program for a quick test of the mcs compiler and mint interpreter. You can also get the compiled version if you want.

As a simple test to make sure what you have now works, you can download the Hello World program and compile it with the command

mcs helloworld.cs

You will see a warning saying that non-atomic functions are used, but don't worry about that. Just type the next line to run your program:

mint helloworld.exe

© Copyright 2002 by Johannes Roith & Martin Willemoes Hansen


The Mono Handbook - Installation overview

The Mono Handbook > Installation overview

Installation overview & considerations

by Johannes Roith (johannes@jroith.de), Hinne Hettema, Jaime Anguiano Olarra

This covers the installation of mono on your platform, as well as the installation and configuration of an IDE

Installation overview

Mono is not finished--it is a project still under development. As a result, installation and configuration may not be as smooth as you will be used to from other Linux applications. Nevertheless, mono is in a state that will allow you to get it up and running and gain experience with it--which is, I would suggest, a very smart thing to do.

This document is limited in the following sense: it describes how to download a 'stable' version of mono as a 'tarball' and get it to run on your computer. I'm also assuming you run mono on Linux rather than on Windows. All the examples have been tested on a 'vanilla' Red Hat 7.3 installation.

This document will not cover:

  • How to self host the mcs compiler under linux.

This document is also less useful for two types of people.

  • If you are a very inexperienced linux user and want to know what mono is all about, there is an easier way to install mono. Go to mono.baselabs.org and download the rpm's ready for installation on your system. This site also runs a tutorial that is worth reading.

  • If you are a very experienced user wanting to contribute to the mono code, you should probably regularly do a CVS download. At the moment, the mono code grows very fast, and the 'stable' releases still appear too slowly.

This document is aimed at the mono beginner, and aims to present a complete view of a minimal installation, which will allow you to experiment with mono to some degree. It also describes some of those experiments. We expect that after reading this document you'll go on to do either of two things:

  1. Continue to contribute to the mono project in some shape or form. The website has some ideas and suggestions under the heading 'Contributing'.

  2. Continue to write applications that run in mono.

We hope this document will be useful to you in your first steps with mono. Happy hacking!

A note on the development of this document

This document is expected to grow into a full 'running mono howto' over time. As of yet, it does not really discuss some of the excellent efforts of others to package mono into an rpm or deb and prepare it for easy installation. It is our aim to include this in future versions of this document.


The Mono Handbook - GNOME.NET - Introduction

The Mono Handbook > Installation on Windows

Installation on Windows

by Hinne Hettema, Jaime Anguiano Olarra and Johannes Roith (johannes@jroith.de)

Contents

  • I. Obtaining Mono
  • II. Installing Mono on Windows, the easy way
  • III. Building Mono under Windows
  • IV. Troubleshooting

Obtaining Mono

In order to obtain the required software you just need to visit the Mono download page at http://www.go-mono.org/download or any of the related sites.

You'll be able to complete everything in this document if you just install the runtime, but taking a look at the compiler package is well worth the effort. The compiler is written in C# and is 'self hosting' which means it is able to compile itself.

This page also lists the current versions of the software mono depends on. Make sure that your system has all the required versions, otherwise mono won't compile.

Installing Mono on Windows, the easy way

Oh. This is a very easy task now. If you just want to take a look at the possibilities of Mono get the Mono installer from the site of Johannes Roith <johannes@jroith.de>:

http://mono.jroith.de. You can get a link in

the download section of the Mono site too: http://www.go-mono.org/download

Then you just need a Windows machine. Better use Windows 2000 Professional, NT4 or XP.

Once you've got it, run the installer.

Remember, building your own Mono runtime and compiler from the sources is strongly recommended. You won't discover the power of Mono until you get it made this way. If you feel hungry about real programming with Mono, proceed like in the next section.

Building Mono under Windows

  • 1.- Get Windows 2000 Professional or any Windows System supporting .NET SDK. Avoid using XP and the redistributable version of the SDK (necessary for WinME, etc).

  • 2.- Get the latest Cygwin distribution, be sure you install the GNU Build Tools packages. Take the openssh package if you plan to contribute to the project. If you feel insecure about the packages you need to install, install all of them, of course, Text, Admin, Games and Web are not necessary at all and you can pass of those. The fitness of your choice will depend of your knowledge on Linux and/or Cygwin. If in doubt install all.

  • 3.- Install the .NET SDK.

  • 4.- Install Cygwin.

  • 5.- Get http://www.go-mono.org/mono-build-w32.sh and put it into your home directory in the cygwin setup.

  • 6.- Enter your cygwin environment. If you have an account in the mono cvs, then export the variables as shown in http://www.go-mono.org/ccvs.html

             This means. Enter: export CVSROOT=user@mono-cvs.ximian.com:/cvs/public

             and export CVS_RSH=ssh

    If you have no account DO NOTHING.

  • 7.- Enter:

    export ACLOCAL_FLAGS="-I /usr/local/share/aclocal"
        and this: export PKG_CONFIG_PATH="/usr/local/bin"

  • 8.- Run the script (mono-build-w32.sh)

  • 9.- All should work fine know and you should see it download what necessary and build mono.

Troubleshooting

If you have noticed problems during step 8 and the execution stops because of errors as I cannot find that or such library or alike, try to:

  • 1.- Create a directory mono-temp for example.

  • 2.- Move and unzip all the zips the mono-build script downloads to /usr/local to that new directory. Do it one by one, copying the content of the created subdirectories (include, bin, etc) to their respectives in /usr/local. Take care, some libraries like libglib... must go into /usr/local/bin and not into /usr/local/lib.

  • 3.- Jump into the /usr/local/mono directory and run ./autogen.sh

  • 4.- Then run ./configure and after it: make and finally: make install.


The Mono Handbook - Learning C#

The Mono Handbook > Learning C#

Learning Programming with C#

Contents

  • 1. Introduction
  • 2. Before you start
    • 2.1 What is a program?
    • 2.2 How are programs created?
    • 2.3 What is C#?
    • 2.3 C# - an interpreted or compiled language?
    • 2.2 C# versus VB.NET
  • 3. Your first Application
    • 2.1 Hello World!
    • 2.2 Comments
    • 2.3 Namespaces
    • 2.2 Class Definition
    • 2.4 Main() method
    • 2.5 Compiling and running
  • 4. Data / Types
    • 2.1 Introduction
    • 2.2 Constants
    • 2.3 Variables
    • 2.3 constant Variables
    • 2.2 The essential Types
    • 2.4 Other Types
    • 2.5 Type convertion
  • 5. Operators
  • 6. Control structurs
  • 7. Arrays
  • 8. Input/Output
  • 9. Classes
  • 10. Inheritance
  • 11. Error processing

Credits

Authors: Johannes Roith (johannes at jroith dot de), PJ Cabrera (pjcabrera at pobox dot com)

This chapter uses some translated content from the C# Tutorial, written in Spanish for Mono Hispano (http://mono.es.gnome.org) by Alejandro Sanchez Acosta, Alvaro del Castillo San Felix, Eduardo Garcia Cebollero, Cesar Garcia Tapia, Sergio Gomez Bachiller, Roberto Perez Cubero, and Jaime Anguiano Olarra.

The Mono Handbook | Mono Homepage | Credits | License


The Mono Handbook - Learning MonoBasic

The Mono Handbook > Learning MonoBasic

Learning MonoBasic

Contents

  • 1 Using this tutorial
  • A Credits

1 Using this tutorial

[TODO]

B. Credits

The Mono Handbook - © Copyright 2003 by Johannes Roith & Martin Willemoes Hansen


The Mono Handbook - What is Mono?

The Mono Handbook > What is Mono?

What is Mono?

Contents

  • I. Preface
  • II. What is Mono?
  • III. The CIL and the promise of language independence
  • IV. Mono and GNOME
  • V. An upgrade to the development platform: Part I.
  • VI. Evolution, Gnumeric and GNOME.
  • VII. Why is Mono related to GNOME?
  • VIII. GNU was based on a proprietary technology
  • IX. Other uses of Mono
  • X. Mono features
  • A. Credits

Preface

Based on post from Miguel de Icaza's (miguel@ximian.com) on the gnome-hacker list in Febrary 2002.

Before starting, I would like to ask my readers to forget everything they have heard about .NET, because it is a marketing term used to describe many different Microsoft projects, and there is a lot of information both correct and incorrect about it floating around.

My goals with Mono are very specific, and I will address those shortly, but for the sake of getting things done, please forget everything you have heard about .NET.

What is Mono?

Mono is an implementation of 7 pieces of technology:
  • A compiler for a new programming language, similar to Java, called C#.
  • A compiler for the Basic programming language.
  • A compiler for the LOGO programming language.
  • A virtual machine for the Common Intermediate Language (CIL) byte codes.
  • A set of libraries that encapsulate useful routines and classes: from hash tables, to XML manipulation, to database management, to GUI applications, to web construction tools.

These are usually referred in the Microsoft world as the `.NET Framework' as opposed to .NET. When I say `.NET Framework' here, I am talking about these technologies.

Seasoned industry programmers will notice that the above is very much like Java and the Java VM. They are right, the above is just like Java.

The CIL has one feature not found in Java though: it is byte code representation that is powerful enough to be used as a target for many languages: from C++, C, Fortran and Eiffel to Lisp and Haskell including things like Java, C#, JavaScript and Visual Basic in the mix.

I wish I had the time to go in more detail, but for the sake of this argument, the above will suffice.

Although Ximian can only finance the work of a C# compiler (that is all the resource I have at my disposal), I want to encourage other people to work on free implementations of other compilers.

I want to encourage other developers to look at targeting existing compilers and interpreters to the CLI: JavaScript, Basic, Perl, Python, C++, and maybe even get gcc core to generate CIL bytecodes.

The CIL and the promise of language independence:

Bertrand Meyer (the father of Eiffel) wrote an interesting article that encapsulates my excitement about the possibilities of the CIL:

This technology allows programming languages to be considered on the basis of how they will perform for a given task, and not based on the runtime libraries that you will depend. Any software engineer should read this article:

So no longer should a software engineer pick Fortran, because that is the only language where his math libraries are available: he can now pick the right language for the problem at hand.

Mono and GNOME.

GNOME had always tried to have a good support for multiple programming languages, because we realize that no matter how much we loved C as a programming language, there was a large crowd of people out there that would like to use the GNOME libraries from their favorite programming language, which might not necessarily be C.

This strategy has paid off very well. There are healthy and striving Python, Perl, Guile and Ada communities out there that use the Gtk+ and Gnome bindings to build applications. From rapid prototyping to robust applications: we wanted to empower developers.

Keeping language bindings up to date and shipping them on time has always been a consuming process, because no matter how automated this process has turned out to be, there is still a considerable amount of manual work that needs to be done.

I do go into more details about this at the following places:

An upgrade to the development platform: Part I.

Microsoft has terrible APIs to code against. Anyone who has used Win32 and any combination of the various layered cakes that have been built on top of it has stuck to that platform only because of the size of the market, but it is one of the most horrible APIs ever built.

To make things worse, an evolution of APIs, components, memory management contracts and patched up versions of COM have made the platform horrible.

Microsoft has injected fresh air into their platform by building and designing a new programming platform that addresses all these pains. They have incorporated many ideas from Java, and they have extended it to address new needs that developers had. They took where Java left off.

Now, the Unix platform, GNOME included has some of these problems: our APIs have been evolving. Libraries have been built by disconnected groups (PNG, JPEG, Gtk+, Xml, Bonobo, CORBA spec apis, etc) and the end result is that a developer eventually has to learn more than he wanted to in the course of developing a large application.

Ximian funded for a long time the work on the Perl bindings, and we had a lot of work going into Bonobo (more than we do today) because we believed that this would help us achieve language independence and empower scripting language developers (that is why we were so psyched about CORBA/Bonobo support all this time).

When C#, the CLR and the class libraries were launched, we looked at that, and we saw how they were solving the problem in a very nice way. At least it appealed to me and others from a purely technological standpoint. This new platform showed a lot of promise.

After much researching and debating, we decided that a couple of developers at Ximian will join me in working on a free implementation of these specifications. These people came precisely from the cross-language interoperability area: Dick Porter had been working before on ORBit and our SOAP implementation; Dietmar Maurer came from the Bonobo development world and Paolo Molaro was working on Gtk+/Gnome/Bonobo bindings for Perl. This is the original Mono developer lineup.

Evolution, Gnumeric and GNOME.

I have written and maintained many lines of code as part of my GNOME work. Ximian has developed Evolution which consists of roughly 750,000 lines of code.

Large software projects expose a set of problems that can be ignored for smaller projects. Programs that have long life times have different dynamics when it comes to memory management than smaller programs.

There is a point in your life when you realize that you have written enough destructors, and have spent enough time tracking down a memory leak, and you have spend enough time tracking down memory corruption, and you have spent enough time using low-level insecure functions, and you have implemented way too many linked lists [1]

[1] indeed, GNOME uses Glib which is a massive step up from the Unixy libc APIs.

The .NET Framework is really about productivity: even if Microsoft pushes these technologies for creating Web Services, the major benefit of these is increased programmer productivity.

Evolution took us two years to develop and at its peak had 17 engineers working on the project. I want to be able to deliver four times as many free software applications with the same resources, and I believe that this is achievable with these new technologies.

My experience so far has been positive, and I have first hands experience on the productivity benefits that these technologies bring to the table. For instance, our C# compiler is written in C#. A beautiful piece of code.

It can be argued that I could be wrong, and that these technologies are too new. But my personal experience and the experience of some of my friends with this platform has been amazing. I want to share with others this simplicity. And I want to empower developers: I want to enable a whole class of developers to create great desktop applications that integrate with GNOME.

Why is Mono related to GNOME?

It is no secret that I have been working on Mono as a new platform for software development, and it is also not a secret that I want to help the GNOME project with Mono. This has been the plan since the project was announced in July.

Mono will use Gtk+, Gnome-Db, Libart, Gnome-Print and other GNOME technologies as part of its implementation of its class libraries, because that is what my team and I are familiarized with.

So when you copy your binary from Windows that was compiled with the Visual Studio.NET and run it on your Unix platform, it will just integrate nicely with your GNOME desktop.

We are also exploring a port to MacOS X, and for that particular case, we will integrate with Aqua, not with Gtk+, but you get the idea.

GNU was based on a proprietary technology.

GNU is a free re-implementations of Unix. Linux is a re-implementation of the Unix kernel. Before the advent of Linux and the Berkeley Unix, Unix was a proprietary technology, built by ATT (which back in the day, was a monopoly).

Still, developers took what was good from Unix, and reimplemented a free version of it. Down to the Unix programming language: C (which was also invented at ATT). Even C++ was invented at ATT.

Think of Mono as following the same process: we are bringing the best technology out there to our beloved free software platform. And at the same time it serves to be a magnificent upgrade on the development platform.

Other uses of Mono

Despite my love for Mono as a tool for writing GNOME applications and giving developers new tools to write code in less time, there is an extra advantage in having a free implementation of the .NET Framework for Unix:

  • Windows developers know how to write code for it.

  • Lets make it easy to bring developers from the Windows world into our platform.

  • Training materials, tutorials, documentation, tips and tricks are already available in large quantities, lets leverage this.

Mono features

Here are my top 10 features.
  • languages independence: you can use classes written in VB.NET in C# or MonoLOGO
  • platform independence: Mono applications are highly portable, and binary compatible across platforms.
  • broad database support: MS SQL, MySQL, Postgres, OLE DB, ODBC, ... all in all up to 27 accessible databases.
  • speed: CIL is jitted, so much faster than interpreted languages (PHP), faster to jit than Java, only a bit slower than C.
  • garbage collector: So you can concentrate on the real work.
  • secure: applications can run in a sandbox.
  • web applications: every mono language can be used for websites. No need for special languages like PHP.
  • web services: support for SOAP.
  • XML support: mono has many classes to work with xml.
  • ritch class library: Cryptography, HTTP, Networking, DirectoryServices, ...
  • cross-platform GUI applications: GTK#, is very powerful and available for nearly all platforms.
  • Gnome, KDE and Windows applications: mono has complete gnome and qt bindings. System.Windows.Forms is also implemented.

A. Credits

Author: Johannes Roith (johannes@jroith.de)
Author: Miguel de Icaza (miguel@ximian.com)

The Mono Handbook | Mono Homepage | Credits | License


The Mono Handbook - What is .NET?

The Mono Handbook > What is .NET?

What is .NET?

.NET is a product family, shipped by Microsoft in 2001, as a response to the successful Java from Sun. It's not a clone, but a complete redesign, with some exciting new features, like language independence, great Database support, broad XML support, well designed WebServices and WebApplications support and a big upgrade to the VisualBasic language, including object orientation. To this family they also count Services and the Microsft Servers.

Microsoft .NET is in fact 3 things. It important to not confuse them.

  • The .NET Framework
  • Services (MyServices, Passport)
  • Other things with the label ".NET"
Mono is just an implementation of the .NET Framework. The .NET Framework is a "software platform", similiar to Java. The technical aspect will be discussed in "Architecture".

Language independence. Perhaps the most important factor is, that all langauges "are created eval". Yes, that's the right word. There are not one or two languages, that can be consumed by others, if you want to be independent from language. (A bit wired.) Example: All Gnome APIs are written in C. This ensures, that you can write an applicaton in Python, by accessing these C libraries through bindings. But you cannot access Python programs through C. In the .NET world this is possible. Write in C#, MonoBasic, or whatever, you can without any problems reuse those classes. Great!

Platform independence. .NET code is not compiled to machine code, but has an intermediate form. You can copy binaries across platforms just like in Java. Only native code invokation can stop this, but it will disappear, when time moves.

Class library..NET has a big, big class library, for almost any task. Especially the high-level classes are interesting. XML-Support, Database-Support, WebServices-Support and Webpages support are a few examples.

C# language. C# is a very beatiful, clean, effective language. VB.NET language. Microsoft has finally fixed the Basic language here. It is now just as feature-full as C# or any other .NET langauge is and Basic classes can be reused in C# like C# classes in Basic.

web applications.With ASP.NET Microsoft ships the next generation web page framework. It suffers from language independence, so finally you can write your we pages with pascal or C++ as well as LOGO and so on. Also it's the first framework to break with 100% HTML code programming and makes HTML accessible as objects, while also introducing complex things like claendars.

A. Credits

Authors: Johannes Roith (johannes@jroith.de)

The Mono Handbook | Mono Homepage | Credits | License


The Mono Handbook - Mono Implementation

The Mono Handbook > Mono Implementation

Mono enabled Platforms

Platforms supported

Mono is ported to Windows, MacOS X, FreeBSD and Linux and therefor covers 99% of the desktop market.
On the Server Windows and Linux on x86 should gain 70%. It is however needed to port to SPARC and Solaris.

The mono team is working on a new JIT, that is easy to port to different platforms.

Platform | Interpreter | Jitter (faster)
Windows | Yes | Yes
MacOS X | Yes | No
FreeBSD | Yes | Yes
Linux (X86) | Yes | Yes
Linux (PPC) | Yes | No
Linux (S390) | Yes | No

Desktops supported

Mono currently has support for:
  • The Gnome desktop enviroment
  • The KDE desktop enviroment
  • The Windows desktop enviroment (in progress)

There is on-going work to support Aqua on MacOS X.


The Mono Handbook - Mono Implementation

The Mono Handbook > Mono Implementation

Mono Implementation

Contents

  • I. Introduction
  • A. Credits

I. Technologies implemented

Besides the core .NET features, there are many under the hood, in the class library. This chapter will take a look at what work the mono project has done, and with what technologies yoiu can work.

C# language

Mono introduces a complete new language, called C#. It's very similiar to Java, but also has features from C++.
using System;

class HelloWorld {
    public static void Main() {
        Console.WriteLine("Hello, World!");
    }
}

VB language

The Basic language hasn't really changed over the years. VisualBasic.NET however fixes many issues, Basic is now as powerful, as C# or other languages. Mono ships with a CIL compiler, making the language just as worthy as C#. Thanks to language-independence classes written in MonoBasic can be used in C# as well. The lack of a good supported Basic implementation on Unix has finally be fixed.
Imports System

Module Test
    Sub Main()
        Console.WriteLine ("Hello World!")
    End Sub
End Module

LOGO language

Mono brings the LOGO language to the Gnome desktop (but also to Windows, MacOS, KDE). Like all mono languages it can make use of the class library, thus supporting Database and XML applications.

Print "|Hello world!|

ADO.NET

Mono provides a common interface to Databases, so chnaging will be very easy. The mono hackers put much work into this. You will hardly find a database not supported, either directly, or through ODBC or libgda. Very portable, works on all platforms.

ASP.NET

ASP.NET is the best Framework I've seen so far, for developing WebSites and -Services. It's language independent, too. Imagine a webpage written in pascal, LOGO, basic, C#, C++, ... . You can access all the class library features and it's very fast, because all libraries are compiled. ASP.NET also features WebForms, that make HTML elements accessible as objects and removes the lack of state in HTTP.

GTK#

With Ximian comming from a Gnome background, Mono has first class Gnome bindings. GTK+, but also Glade, gnome-db and GStreamer are supported. Those libraries are ported to most (if not all) Unixes, MacOS X and Windows and nicely integrate with the Gnome desktop. There is also on-going work to use native widgets on windows and MacOS X. Cross-platform is possible!

QT#

QT# has been started by the KDE community and provides a binding to the KDE developer libraries. The underlying libraries are available on Windows and MacOS X as well, but are only free on Unix.

XML

Mono has perfect support for Xml, with many parsers and processing libraries.

Tools

Mono offers a C and .NET debugger, with the ability to use console or GUI frontends, IL assembler and disassemblers. There are also several productivity applications, like a build tool and Unit testing from third--party projects.

Also there is to mention the mono documentation browser.

II. Classes implemented

III. Classes not implemented

While mono tries to implement all classes, those are either not started or have not progressed enough.
  • Microsoft.Win32
  • System.Windows.Forms
  • System.Messaging

IV. Mono's additional classes

While with about 3000 classes the .NET Framework is quite feature rich, there are serveral bits that are missing.
  • Platform independend GUI
  • More Databases
  • Mailer API
  • Many others
Mono tries to solve this, by introducing a new namespace, and offering the multiplatform GUI GTK+. Compatiblity is kept, all classes are known to run with the MS implementation.

I. Extended .NET: The Mono.* namespace

II. Extended .NET: Multiplatform GUI through Gtk#

II. Differences on Unix/Windows/MacOS X

The mono classes don't need to be ported. However if the underlying library isn't available for a certain platform, some classes might not work there.

  • System.Xml.Xsl depends on libxml2 (very portable)
  • System.Data.Odbc depends on unixodbc or odbc32 (not very portable, but available for windows, unix)
  • Mono.Data.Sqlite depends on sqlite (extremly small and portable)
  • Mono.Data.MySQL depends on libmysql (available for unix, windows; maybe 100% C# implementation in the future)
  • Mono.Data.PostgreSQL depends on libpostgres (available for unix, windows; maybe 100% C# implementation in the future)

A. Credits

Author: Johannes Roith (johannes@jroith.de)
The Mono Handbook © Copyright 2002 by Johannes Roith


The Mono Handbook - Qt# Introduction

The Mono Handbook > Introduction Qt#

Docs are available online from here: http://qtcsharp.sourceforge.net/apidocs/index.html

The Mono Handbook - © Copyright 2003 by Johannes Roith


The Mono Handbook - Qt# FAQ

The Mono Handbook > Qt# FAQ

Qt# Frequently Asked Questions

Contents

  • Contents
  • General Questions
    • What is Qt#?
    • Where can I obtain Qt#?
    • Who is developing Qt#?
    • Are the KDE classes supported?
    • On what platforms can Qt# be used?
    • Where can I find more information about Qt#?
    • How can I help?
  • Installation and Configuration
    • What additional packages are required to install and use Qt#?
    • What are these messages about ``** (process:447): WARNING **: Failed to load function qt_QObject.....'' when starting programs compiled with Qt#?
    • Why do I get an error ``Failed to load library libqtcsharp'' when starting programs compiled with Qt#, and how do I fix it?
  • Usage and Programming
    • How do I compile Qt# program?
    • How do I run a Qt# program?
    • My program compiles fine, but I am getting error messages about a ``Missing method .ctor in typeref index'. What's wrong?
    • Is it possible to create custom slots in Qt#?
    • What are the other limitation of Qt#?
  • About this document ...

General Questions

What is Qt#?

Qt# is a binding of the Qt toolkit to the C# programming lanaguage.

Where can I obtain Qt#?

The latest version can be obtained as part of kdebindings in the form of a snapshot or from CVS. When using CVS, it is only necessary to checkout kdebindings/qtc and kdebindings/qtcsharp.

Older versions of Qt# can be found here

Who is developing Qt#?

Adam Treat

Are the KDE classes supported?

Not yet. Support is planned for the KDE classes after the Qt classes are fully implemented.

On what platforms can Qt# be used?

Currently, Qt# works under Qt/X11. In the future, Qt# will support Qt/Windows and Qt/Embedded.

Where can I find more information about Qt#?

More information can be found at the Qt# website http://qtcsharp.sourceforge.net. Also consider joining the mailing list at http://lists.sourceforge.net/lists/listinfo/qtcsharp-list.

How can I help?

A TODO list is located on the Qt# website. If you would like to work on these or other tasks for Qt#, send email to the mailing list qtcsharp-list@lists.sourceforge.net.

Installation and Configuration

What additional packages are required to install and use Qt#?

Besides GCC, the following packages are required:

  • Qt >= 3.0
  • Qtc from kdebindings >= 3.0
  • Mono >= 0.12

Remember, of course, that if Qt# was obtained as part of kdebindings from CVS, Qtc will already be present. Just remember to build Qtc before Qt#.

What are these messages about ``** (process:447): WARNING **: Failed to load function qt_QObject.....'' when starting programs compiled with Qt#?

These messages, annoying though they might be, can safely be ignored. Qt-CSharp generates its bindings directly from the Qt headers rather than from the Qtc headers. An upcoming release of Qt-CSharp will eliminate these spurious messages.

Why do I get an error ``Failed to load library libqtcsharp'' when starting programs compiled with Qt#, and how do I fix it?

Mono is unable to load the shared library libqtcsharp.so. This might occur with versions of Qt# <= 0.3. Upgrading to a newer version from KDE snapshots or CVS should fix the problem.

Usage and Programming

How do I compile Qt# program?

Assuming that you are using Mono and that you have installed Qt.dll in the default directory Mono searched for libraries, you can simply run ``mcs -r Qt myprogram.cs'' to produce myprogram.exe. If you have placed Qt.dll elsewhere, you might try ``mcs -r /complete/path/to/Qt.dll myprogram.cs''.

How do I run a Qt# program?

To run the compiled program myprogram.exe, simply use ``mono myprogram.exe''.

My program compiles fine, but I am getting error messages about a ``Missing method .ctor in typeref index'. What's wrong?

Make sure that you are using the latest version of Mono. Earlier versions have problems with nested enums. If that does not solve the problem, report it to the mailing list.

Is it possible to create custom slots in Qt#?

Yes, but in version 0.3, only one custom slot is allowed. This limitation may be lifted soon.

What are the other limitation of Qt#?

The major limitations are that several Qt classes are missing, some of the type mappings are not optimal (e.g. string to QString), and KDE classes are not implemented.

The Mono Handbook - © Copyright 2003 by Johannes Roith


The Mono Handbook - Qt# - Installation

The Mono Handbook > Installation Qt#

Qt# - Installation

We need someone from the KDE community to take on that chapter, if there should be more information.

The Mono Handbook - © Copyright 2003 by Johannes Roith


The Mono Handbook - Qt# Introduction

The Mono Handbook > Introduction Qt#

Qt# - A cross-platform GUI toolkit for Mono is a set of classes that bind any CIL language to the Qt toolkit. The bindings are in alpha phase right now, but development is moving quickly. Qt# is free software, licensed under the terms of the GNU GPL.

Who should read this chapter?

Programmers experienced with c#, who whish to get to understand and
develop desktop applications for the KDE platform.

How to read this chapter

You can read from the beginning to the end or you can skip around from topic to topic.

The Mono Handbook - © Copyright 2003 by Johannes Roith


The Mono Handbook - Learning C#

The Mono Handbook > Learning C#

Remoting

Contents

  • 1 Temporary
  • A Credits

Introduction

For those who are interested in Remoting, here is a summary of the current status:

* The basic Remoting infrastructure (channels, sinks and all this) is not finished, but it is complete enough for testing. Since RemotingConfiguration is not yet finished, use RemotingServices.Marshal to publish an object, and Activator.GetObject() to get an object form a server.

* The TcpChannel is working, but it is currently not compatible with MS' tcp channel.

* BinaryFormatterProvider is also working. All formatting is done by BinaryFormatter, which is quite complete. It can serialize complex parameters and return values, including arrays, enums and delegates.

* Marshalling and unmarshalling of MarshalByRefObject instances is working, so you can pass object references between applications. Delegates are not working with MBR objects due to a problem with virtual methods and transparent proxy. I think Patrik is working to solve this (and many other things!)

I've prepared simple an example of a client application that connects to an object in a server application and calls some methods. I think it is the better way to show you what can remoting do and how to do it. To test it, compile like this:

mcs -t:library ServerObject.cs
mcs -r:ServerObject.dll -r:System.Runtime.Remoting.dll RemotingClient.cs
mcs -r:ServerObject.dll -r:System.Runtime.Remoting.dll RemotingServer.cs
Enjoy ! Lluis.
using System;
using System.Net;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;

namespace RemotingTest
{
        class RemotingClient
        {
                static void Main ()
                {
                        TcpChannel ch = new TcpChannel(0);
                        ChannelServices.RegisterChannel (ch);

                        // This gets the object from the server (a list of
ServerObject)

                        Console.WriteLine("Getting instance ...");
                        object remOb =
Activator.GetObject(typeof(ServerList),"tcp://localhost:1122/test.rem");

                        ServerList list = (ServerList)remOb;

                        // These are remote calls that return references to remote
objects

                        Console.WriteLine ("Creating two remote items...");
                        ServerObject item1 = list.NewItem ("Created at server 1");
                        item1.SetValue (111);   // another call made to the remote
object
                        ServerObject item2 = list.NewItem ("Created at server 2");
                        item2.SetValue (222);
                        Console.WriteLine ();

                        // Two objects created in this client app

                        Console.WriteLine ("Creating two client items...");
                        ServerObject item3 = new ServerObject ("Created at client 1");
                        item3.SetValue (333);
                        ServerObject item4 = new ServerObject ("Created at client 2");
                        item4.SetValue (444);
                        Console.WriteLine ();

                        // Object references passed to the remote list

                        Console.WriteLine ("Adding items...");
                        list.Add (item3);
                        list.Add (item4);
                        Console.WriteLine ();

                        // This sums all values of the ServerObjects in the list. The
server
                        // makes a remote call to this client to get the value of the
                        // objects created locally

                        Console.WriteLine ("Processing items...");
                        list.ProcessItems ();
                        Console.WriteLine ();

                        // Passing some complex info as parameter and return value

                        Console.WriteLine ("Setting complex data...");
                        ComplexData cd = new ComplexData (AnEnum.d, new object[]
{"some",22,"info"});
                        ComplexData res = list.SetComplexData (cd);
                        Console.WriteLine ("This is the result:");
                        res.Dump();
                        Console.WriteLine ();

                        list.Clear();
                        Console.WriteLine ("Done.");

                        ch.StopListening (null);

                }
        }
}
using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;

namespace RemotingTest
{
        class RemotingServer
        {
                static int Main ()
                {
                        Console.WriteLine("Starting Server");
                        TcpChannel ch = new TcpChannel(1122);
                        ChannelServices.RegisterChannel (ch);

                        ServerList ser = new ServerList();
                        RemotingServices.Marshal(ser,"test.rem");

                        Console.WriteLine("Server Running ...");
                        Console.ReadLine();

                        ch.StopListening (null);

                        return 0;
                }
        }
}
using System;
using System.Runtime.Remoting;
using System.Collections;

namespace RemotingTest
{
        // A list of ServerObject instances

        public class ServerList: MarshalByRefObject
        {
                ArrayList values = new ArrayList();

                public void Add (ServerObject v)
                {
                        values.Add (v);
                        System.Console.WriteLine ("Added " + v.Name);
                }

                public void ProcessItems ()
                {
                        System.Console.WriteLine ("Processing...");

                        int total = 0;
                        foreach (ServerObject ob in values)
                                total += ob.GetValue();

                        System.Console.WriteLine ("Total: " + total);
                }

                public void Clear()
                {
                        values.Clear();
                }

                public ServerObject NewItem(string name)
                {
                        ServerObject obj = new ServerObject(name);
                        Add (obj);
                        return obj;
                }

                public ComplexData SetComplexData (ComplexData data)
                {
                        System.Console.WriteLine ("Showing content of ComplexData");
                        data.Dump ();
                        return data;
                }
        }

        // A remotable object

        public class ServerObject: MarshalByRefObject
        {
                int _value;
                string _name;

                public ServerObject (string name)
                {
                        _name = name;
                }

                public string Name
                {
                        get { return _name; }
                }

                public void SetValue (int v)
                {
                        System.Console.WriteLine ("ServerObject " + _name + ": setting
" + v);
                        _value = v;
                }

                public int GetValue ()
                {
                        System.Console.WriteLine ("ServerObject " + _name + ": getting
" + _value);
                        return _value;
                }
        }

        // Some complex data for testing serialization

        public enum AnEnum { a,b,c,d,e };

        [Serializable]
        public class ComplexData
        {
                public AnEnum Val = AnEnum.a;
                public object[] Info;

                public ComplexData (AnEnum va, object[] info)
                {
                        Info = info;
                        Val = va;
                }

                public void Dump ()
                {
                        System.Console.WriteLine ("Content:");
                        System.Console.WriteLine ("Val: " + Val);
                        foreach (object ob in Info)
                                System.Console.WriteLine ("Array item: " + ob);
                }
        }
}

A. Credits

Authors: Lluis
Authors: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2003 by Johannes Roith & Martin Willemoes Hansen


The Mono Handbook - System.Windows.Forms

The Mono Handbook > System.Windows.Forms

System.Windows.Forms

Introduction

System.Windows.Forms (SWF or S.W.F) is Microsofts GUI toolkit shipped with the .NET Framework. It does definatly not aim to be cross-platform, but only wants to integrate best with Windows.

Nevertheless for compatiblity, and to have - just like for Gnome or KDE - a native toolkit, mono has implemented the API. It does work perfectly on Windows, just like you would expect it. However on Unixes or MacOS X, the situation is more difficult. The current implementation is built on top of wineLIB, and theoritically even complex things like ActiveX objects will work someday.

But wine is still an emulator, so I do not recommend to code against that API, if you want to stay cross-platform. There are enough alternatives out there. I have decided to put it in the tutorial, because it is a very useful API, when your application needs to run on windows only.

A. Credits

Authors: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - Threading

The Mono Handbook > Threading

Threading

Introduction

Multithread-Applications are Applications, that have not only one Application path, but several, that are executed side-by-side. That way an application can process a task, without stopping the user from performing other actions with the tool. A good example would be an app with search functionality, that let's the user still work, while searching.

How Threads work

A. Credits

Author: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - The Mono Assembler

The Mono Handbook > The Mono Assembler

The Mono Assembler

The Mono Assembler is - unlike the mono disassembler - written in C#. you can execute it by typing:

mono ilasm.exe <myfile.il>

The current code will be rewritten, and I will wait for that time, to describe this in more detail.

A. Credits

Author: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - The Mono runtime

The Mono Handbook > Assembler & Dissassembler

Assembler & Disassembler

.NET compilers like mcs or mbas do not compile to native code, but to the COMMON INTERMEDIATE LANGUAGE.

IL code looks like this:

// hello world dissassembled with monodis

.assembly extern mscorlib
{
  .ver 0:0:0:0
}
.assembly 'hello'
{
  .hash algorithm 0x00008004
  .ver  0:0:0:0
}
  .class private auto ansi beforefieldinit Hello
        extends [mscorlib]System.Object
  {

    // method line 1
    .method public hidebysig  specialname  rtspecialname
           instance default void .ctor()  cil managed
    {
        // Method begins at RVA 0x20ec
        // Code size 7 (0x7)
        .maxstack 8
        IL_0000: ldarg.0
        IL_0001: call instance void valuetype [corlib]System.Object::.ctor()
        IL_0006: ret
    } // end of method instance default void .ctor()

    // method line 2
    .method public static
           default void Main()  cil managed
    {
        // Method begins at RVA 0x20f4
        .entrypoint
        // Code size 11 (0xb)
        .maxstack 8
        IL_0000: ldstr "Hello Mono World!"
        IL_0005: call void class [corlib]System.Console::WriteLine(string)
        IL_000a: ret
    } // end of method default void Main()

  } // end of type Hello
There are two tools:

  • ilasm: The Mono Assembler can be given disassembled text, and it creates aan assembly file. This is very important, because many compilers don't create the assembly themselves, and depend on this tool. Of course it can be also seen as a form of a compiler.
  • monodis: The Mono Disassembler extracts code like shown above from an assembly.

Both tools will be described in detail in the next two sub-chapters.

A. Credits

Author: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - C# compiler Command-line options

The Mono Handbook > C# compiler Command-line options

C# compiler Command-line options

Contents

  • 1. Simple Compile
  • 2. Out Parameters
  • 3. Using Targets

Simple compile

Monos C# compiler is fully compatible the the MS compiler and has even the same switches.
// Hello World! : hello.cs

using System;

class Hello {
    static void Main() {
        Console.WriteLine ("Hello, World!");
    }
}
To compile, type
mcs hello.cs
This results in a file hello.exe, that you can execute with mono:
mono hello.exe

Out Parameters

To compile to another filename:
mcs /out:someothername.exe hello.cs

Using Targets

Exe

This is the default and will create a console application.
mcs /target:exe hello.cs

Winexe

This has no effect currently, when used with mono, but this might change, when mono will integrate with GUI filemangers like Nautilus. On the MS .NET Framework this causes the runtime not to open a console window, if not already opened.
mcs /target:winexe hello.cs

Library

to compile a library:
mcs /target:library hello.cs

Module

A module is not a complete application, but only for example one or two classes. Serveral module can be compiled to one application. This is useful if you want to compile one application out of a VB.NET module and a C# module.
mcs /target:module hello.cs

Other Options

--about

Displays information about the Mono C# compiler

-checked, -checked

Sets the default compilation mode to `checked'. This makes all the math operations checked (the default is unchecked).

-checked-

Sets the default compilation mode to `unchecked'. This makes all the math operations unchecked (this is the default).

-codepage:ID

Specifies the code page used to process the input files from the point it is specified on. By default files will be processed in the Latin-1 code page. The compiler will also automatically detect Unicode files that have an embedded byte mark at the beginning. The special ID "utf8" can be used to switch to utf8 and the ID "reset" restores the automatic handling of code pages.

-define:SYMLIST, -d:SYMLIST

Defines the symbol listed by the semi-colon sepa- reted list SYMLIST SYMBOL. This can be tested in the source code by the pre-processor, or can be used by methods that have been tagged with the Con- ditional attribute.

-debug, -debug+, -g

Generate debugging information. The debugging information is stored in a file with the extension .dbg (if you install system wide assemblies, you need to install this file as well). To get stack traces with debugging information, you need to invoke the mono runtime with the `--debug' flag.

-debug-

Do not generate debugging information.

--expect-error X L

The compiler will expect the code to generate an error named `X' in line `L'. This is only used by the test suite.

--fatal

This is used for debugging the compiler. This makes the error emission generate an exception that can be caught by a debugger.

--stacktrace

Generates a stack trace at the time the error is reported, useful for debugging the compiler.

-lib:PATHLIST

Each path specified in the comma-separated list will direct the compiler to look for libraries in that specified path.

-L PAT

Directs the compiler to look for libraries in the specified path. Multiple paths can be provided by using the option multiple times.

-nostdlib, -nostdlib+

Use this flag if you want to compile the core library. This makes the compiler load its internal types from the assembly being compiled.

-noconfig, -noconfig+

Disables the default compiler configuration to be loaded. The compiler by default has references to the system assemblies.

-nowarn:WARNLIST

Makes the compiler ignore warnings specified in the comma-separeted list WARNLIST>

-out:FNAME, -o FNAME

Names the output file to be generated.

--parse

Used for benchmarking. The compiler will only parse its input files. -resource:RESOURCE[,ID] Embeds to the given resource file. The optional ID can be used to give a different name to the resource. If not specified, the resource name will be the file name.

-linkresource:RESOURCE[,ID]

Links to the specified RESOURCE. The optional ID can be used to give a name to the linked resource.

-recurse:PATTERN, --recurse PATTERN

Does recursive compilation using the specified pat- tern. In Unix the shell will perform globbing, so you migth want to use it like this: bash$ mcs -recurse:'*.cs'

--timestamp

Another debugging flag. Used to display the times at various points in the compilation process.

-unsafe, -unsafe+

Enables compilation of unsafe code.

-warnaserror, -warnaserror+

Treat warnings as errors.

-warn:LEVEL

Sets the warning level. 0 is the lowest warning level, and 4 is the highest. The default is 2.

-r:ASSEMBLY1[,ASSEMBLY2], -r ASSEMBLY1[,ASSEMBLY2]

Reference the named assemblies. Use this to use classes from the named assembly in your program. The assembly will be loaded from either the system directory where all the assemblies live, or from the path explicitly given with the -L option. You can also use a semicolon to separate the assemblies instead of a comma.

-v

Debugging. Turns on verbose yacc parsing.

--

Use this to stop option parsing, and allow option- looking parameters to be passed on the command line.

A. Credits

Author: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - MCS: The Ximian C# compiler

The Mono Handbook > MCS: The Ximian C# compiler

C# & VB Compiler - Introduction

Contents

  • 1. MCS: The Ximian C# compiler
  • 2. mbas: Mono's Basic.NET Compiler
  • 3. Credits

MCS: The Ximian C# compiler

MCS is the Mono C# compiler. Interestingly, it's written in C# itself and therefor highly portable. (There is no need to port it.)

MCS is currently able to compile itself and many more C# programs (there is a test suite included that you can use). It is routinely used to compile Mono, roughly half a million lines of C# code. We are in feature completion mode right now. There are still a couple of areas that are not covered by the Mono compiler, but they are very very few at this point (security attributes), you can also browse the MCS bugs from Bugzilla. A test suite is maintained to track the progress of the compiler and various programs are routinely compiled and ran.

Mcs doesn't compile native code, but a kind of bytecode, that can be processed by the mono runtime, like the image shows:

History

MCS was able to parse itself on April 2001, MCS compiled itself for the first time on December 28 2001. MCS became self hosting on January 3rd, 2002. The Mono Runtime and the Mono execution engine were able to make our compiler self hosting on March 12, 2002.

Obtaining and running MCS

The Mono C# compiler is part of the `mcs' module in the Mono CVS you can get it from our Anonymous CVS server, or you can get nightly download page.
MCS is written in C# and uses heavily the .NET APIs. MCS runs on Linux with the Mono runtime and on Windows with both the .NET runtime and the Mono runtime.

CIL Optimizations.

The compiler performs a number of simple optimizations on its input: constant folding (this is required by the C# language spec) and can perform dead code elimination. Other more interesting optimizations like hoisting are not possible at this point since the compiler output at this point does not generate an intermediate representation that is suitable to perform basic block computation.

Adding an intermediate layer to enable the basic block computation to the compiler should be a simple task, but we are considering having a generic CIL optimizer. Since all the information that is required to perform basic block-based optimizations is available at the CIL level, we might just skip this step altogether and have just a generic IL optimizer that would perform hoisting on arbitrary CIL programs, not only those produced by MCS.

If this tool is further expanded to perform constant folding (not needed for our C# compiler, as it is already in there) and dead code elimination, other compiler authors might be able to use this generic CIL optimizer in their projects reducing their time to develop a production compiler.

Reporting Bugs in MCS

When you report a bug, try to provide a small test case that would show the error so we can include this as part of the Mono C# regression test suite. If the bug is an error or a warning that we do not flag, write a sample program called `csXXXX.cs' where XXXX is the code number that is used by the Microsoft C# compiler that illustrates the problem. That way we can also do regression tests on the invalid input.

Questions and Answers

Question 1: Why not write a C# front-end for GCC?

I wanted to learn about C#, and this was an exercise in this task. The resulting compiler is highly object-oriented, which has lead to a very nice, easy to follow and simple implementation of the compiler.

I found that the design of this compiler is very similar to Guavac's implementation.

Targeting the CIL/MSIL byte codes would require to re-architecting GCC, as GCC is mostly designed to be used for register machines. The GCC Java engine that generates Java byte codes cheats: it does not use the GCC backend; it has a special backend just for Java, so you can not really generate Java bytecodes from the other languages supported by GCC.

Question 2: If your C# compiler is written in C#, how do you plan on getting this working on a non-Microsoft environment.

We will do this through an implementation of the CLI Virtual Execution System for Unix (our JIT engine).

Our JIT engine is working for the purposes of using the compiler. The supporting class libraries are being worked on to fully support the compiler.

Question 3: Do you use Bison?

No, currently I am using Jay which is a port of Berkeley Yacc to Java that I later ported to C#. This means that error recovery is not as nice as I would like to, and for some reason error productions are not being caught.

In the future I want to port one of the Bison/Java ports to C# for the parser.

Question 4: Should someone work on a GCC front-end to C#?

I would love if someone does, and we would love to help anyone that takes on that task, but we do not have the time or expertise to build a C# compiler with the GCC engine. I find it a lot more fun personally to work on C# on a C# compiler, which has an intrinsic beauty.

We can provide help and assistance to anyone who would like to work on this task.

Question 5: Should someone make a GCC backend that will generate CIL images?

I would love to see a backend to GCC that generates CIL images. It would provide a ton of free compilers that would generate CIL code. This is something that people would want to look into anyways for Windows interoperation in the future.

Again, we would love to provide help and assistance to anyone interested in working in such a project.

Question 6: What about making a front-end to GCC that takes CIL images and generates native code?

I would love to see this, specially since GCC supports this same feature for Java Byte Codes. You could use the metadata library from Mono to read the byte codes (ie, this would be your "front-end") and generate the trees that get passed to the optimizer.

Ideally our implementation of the CLI will be available as a shared library that could be linked with your application as its runtime support.

Again, we would love to provide help and assistance to anyone interested in working in such a project.

Question 7: But would this work around the GPL in the GCC compiler and allow people to work on non-free front-ends?

People can already do this by targeting the JVM byte codes (there are about 130 compilers for various languages that target the JVM).

Question 8: Why are you writing a JIT engine instead of a front-end to GCC?

The JIT engine and runtime engine will be able to execute CIL executables generated on Windows.

You might also want to look at the GCC section on the main FAQ

mbas: Mono's Basic.NET Compiler

MBAS is a CIL compiler for the Visual Basic language, an extended version of VisualBasic.NET. It's based on the MCS compiler and still in heavy development, though many language features are already supported.

What works

  • Classes, Fields and Methods. Properties are still being worked on.
  • Module definition and Sub functionality (TODO: Function's) * Namespace Import, so can you reference, instantiate and call external assemblies
  • Parameter passing between Sub's. ByVal and ByRef parameters are being worked on.
  • Delegates
  • Object creation
  • Events - to a limited extent. You can declare a Class-Field as 'WithEvents' and dynamic events (i.e AddHandler MyButton.Click, Button1_OnClick). Please beware: just after committing the code, I discovered that the handler field in the AddHandler call is case-sensitive, a remnant of mBas' mcs heritage)
  • Statements supported are 'If..Then..Else' , 'While..End While' and assignment statements. Simple operators (+, -, *, /, >, <, =) should also work. Other statements (For..Next, etc.) should be quite trivial to implement.
A lot of this stuff is implemented rebuilding proper expressions and statements on top of the classes provided by mcs (look at the grammar - mb-parser.jay - and compare it with cs-parser.jay, if interested).

TODO-list

At this stage almost every element of the language must be still checked for conformance to MS'implementation. Help is particularly needed for those areas I know little of (mcs internals are still quite obscure to me). I'd like to implement class properties, the missing statements, exception handling, structures and actual event support (not necessarily in this order). Once we have all this stuff set up and reasonably bug-free, more work could be done on helper functions and Object-vars handling.

A. Credits

Author: Johannes Roith (johannes@jroith.de)
Author: Miguel de Icaza (miguel@ximian.com)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - Using the Mono Debugger

The Mono Handbook > Using the Mono Debugger

Using the Mono Debugger

by Johannes Roith (johannes@jroith.de)

Contents

  • 1. Execute
  • 2. Options
  • 3. Credits
A debugger is an important tool for development. Martin Baulig, the author of the mono debugger has probably written the best debugger on the planet ;-). It takes not only mono applications, but can also debug C native code. It is splitted in front- and backends, so a console version is available, as well as a grafical Gtk# frontend.

The Gtk# frontend:

Getting it

the mono debugger is in mono cvs module /debugger.

Using it

Start the debugger with
mono debugger.exe
[TODO]

Options

[TODO]

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - C# compiler Command-line options

The Mono Handbook > C# compiler Command-line options

MonoBasic compiler Command-line options

by Johannes Roith (johannes@jroith.de)

Contents

  • 1. Simple Compile
  • 2. Out Parameters
  • 3. Using Targets

Simple compile

Monos C# compiler is fully compatible the the MS compiler and has even the same switches.
// Hello World! : hello.vb

Imports System

Module Test
    Sub Main()
        Console.WriteLine ("Hello World!")
    End Sub
End Module
To compile, type
mbas hello.cs
This results in a file hello.exe, that you can execute with mono:
mono hello.exe

Out Parameters

To compile to another filename:
mbas /out:someothername.exe hello.cs

Using Targets

Exe

This is the default and will create a console application.
mcs /target:exe hello.cs

Winexe

This has no effect currently, when used with mono, but this might change, when mono will integrate with GUI filemangers like Nautilus. On the MS .NET Framework this causes the runtime not to open a console window, if not already opened.
mcs /target:winexe hello.cs

Library

to compile a library:
mcs /target:library hello.cs

Module

A module is not a complete application, but only for example one or two classes. Serveral module can be compiled to one application. This is useful if you want to compile one application out of a VB.NET module and a C# module.
mcs /target:module hello.cs

Other Options

  -? --help             Show this help list
     --about            About the MonoBASIC compiler
     --addmodule=PARAM  [NOT IMPLEMENTED YET]Reference metadata from specified module
     --baseaddress=PARAM [NOT IMPLEMENTED YET]The base address for a library or module (hex)
     --bugreport=PARAM  [NOT IMPLEMENTED YET]Create bug report file
     --checked          [Mono] Set default context to checked
  -d --define=PARAM     [NOT IMPLEMENTED YET]Declares global conditional compilation symbol(s). symbol list:name=value,...
     --debug            Emit debugging information
     --debug-args=PARAM [Mono] Debugger arguments
     --debug:full       Emit full debugging information (default)
     --debug:pdbonly    [IGNORED]Emit PDB file only
     --delaysign        [NOT IMPLEMENTED YET]Delay-sign the assembly using only the public portion of the strong name key
     --fatal            [Mono] Makes errors fatal
     --ignorewarn=PARAM [Mono] Ignores warning number PARAM
     --imports=PARAM    [NOT IMPLEMENTED YET]Declare global Imports for namespaces in referenced metadata files. import list:namespace,...
     --keycontainer=PARAM [NOT IMPLEMENTED YET]Specifies a strong name key container
     --keyfile=PARAM    [NOT IMPLEMENTED YET]Specifies a strong name key file
     --libpath=PARAM    [NOT IMPLEMENTED YET]List of directories to search for metada references (semi-colon delimited)
     --linkpaths=PARAM  [Mono] Adds path to the assembly link path
     --linkresource=PARAM [NOT IMPLEMENTED YET]Adds the specified file as an embedded assembly resource
  -m --main=PARAM       Specifies the Class or Module that contains Sub Main.It can also be a Class that inherits from System.Windows.Forms.Form.
     --noconfig         [Mono] Disables implicit references to assemblies
     --nologo           [NOT IMPLEMENTED YET]Do not display compiler copyright banner
     --nostdlib         [Mono] Don't assume the standard library
     --nowarn           Disable warnings
  -o --out=PARAM        Specifies the output file name
     --optimize         [NOT IMPLEMENTED YET]Enable optimizations
     --optioncompare:binary [NOT IMPLEMENTED YET]Specifies binary-style string comparisons. This is the default
     --optioncompare:text [NOT IMPLEMENTED YET]Specifies text-style string comparisons.
     --optionexplicit   [NOT IMPLEMENTED YET]Require explicit declaration of variables
     --optionstrict     [NOT IMPLEMENTED YET]Enforce strict language semantics
     --parse            [Mono] Only parses the source file (for debugging the tokenizer)
     --quiet            [NOT IMPLEMENTED YET]Quiet output mode
     --recurse=PARAM    [NOT IMPLEMENTED YET]Include all files in the current directory and subdirectories according to the wildcard
     --removeintchecks  [NOT IMPLEMENTED YET]Remove integer checks. Default off.
     --resource=PARAM   Adds the specified file as an embedded assembly resource
     --rootnamespace=PARAM [NOT IMPLEMENTED YET]Specifies de root namespace for all type declarations
  -r --reference=PARAM  References metadata from the specified assembly
     --stacktrace       [Mono] Shows stack trace at Error location
     --target=PARAM     Specifies the target type for the output file (exe [default], winexe, library, module)
     --timestamp        [Mono] Displays time stamps of various compiler events
     --tokenize         [Mono] Only tokenizes source files
     --unsafe           [Mono] Allows unsafe code
     --usage            Show usage syntax and exit
     --utf8output       [NOT IMPLEMENTED YET]Emit compiler output in UTF8 character encoding
  -v --verbose          Display verbose messages
     --warnaserror      Treat warnings as errors
     --win32icon=PARAM  [NOT IMPLEMENTED YET]Specifies a Win32 icon file (.ico) for the default Win32 resources
     --win32resource=PARAM [NOT IMPLEMENTED YET]Specifies a Win32 resource file (.res)
     --wlevel=PARAM     [Mono] Sets warning level (the highest is 4, the default)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - Using Mint

The Mono Handbook > Using Mint

Using Mint

Contents

  • 1. Execute
  • 2. Options
  • 3. Credits
The mint program is an interpreter for ECMA CLI byte
codes. It executes the bytecodes contains in program.exe
and optionally passes the arguments to it.

Execute

When available try to execute with mono. That's up to time times faster.

Dont forget the .exe!

mint <file.exe>

Options

The following Generic options are supported:

--help , -h

Displays usage instructions.

--config filename

Load the specified configuration file instead of the default one(s). The default files are /etc/mono/config and ~/.mono/config or the file specified in the MONO_CONFIG environment variable, if set.

--trace

Traces execution showing when methods are entered and left. --traceops Traces execution at the instruction level and displays the stack contents. --traceclassinit Shows when classes are initialized

--noptr

Suppresses printing of pointer addresses in trace output.

--profile

Performs runtime profiling of the code and displays statistics at the end of execution.

--opcode-count

Displays the number of opcodes executed.

--dieonex

Aborts execution upon hitting an exception.

--debug method

Debugs the method whose name is `method'. You can specify the method like this: `class:method' or `class::method'

--opcode-count

Displays the number of opcodes executed

A. Credits

Author: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - C# compiler Command-line options

The Mono Handbook > C# compiler Command-line options

Mono Command-line options

Contents

  • 1. Simple Compile
  • 2. Options

Execute

Dont forget the .exe!
mono <application.exe>
TODO: This is the printout of "man mono". It must be organized.

Options

--help , -h

Displays usage instructions.

--share-code

This mode makes the LoaderOptimization for Application Domains default to sharing code. This results in slower code, but enables code sharing across appli- cation domains. The default is to maximize for speed, but disallow JITed code sharing across domains. See System.LoaderOptimization for more information

--config filename

Load the specified configuration file instead of the default one(s). The default files are /etc/mono/config and ~/.mono/config or the file specified in the MONO_CONFIG environment variable, if set.

--noinline

Disables the code inliner.

DEBUGGING OPTIONS

The following options are used to debug, or perfo- mance test the JIT compiler:

--trace-calls

Shows method names as they are invoked.

--dump-asm

Displays the generated code as methods are invoked.

--dump-forest

Displays the basic blocks and the forest of trees that is created from a stream of CIL opcodes.

--compile name

Compiles the method on the given class (names- pace.name:methodname) or all classes in the given image (@imagename).

--ncompile

Compiles the method a number of times. If no argu- ment is specified, the method will be compiled a thousand times.

DEVELOPMENT OPTIONS

The following options are used to debug a JITed applica- tion. They're only useful when running the JIT in a debugger:

--debug

Writes out debug information in the given format or in the default format. See DEBUGGING FORMATS for details.

--debug-args args

Comma-separated list of additional arguments for the symbol writer. See DEBUGGING FORMATS for details.

--break method

Inserts a breakpoint before the method whose name is `method' (namespace.class:methodname). Use `Main' as method name to insert a breakpoint on the application's main method.

--precompile name

Compiles the given class (namespace.name), method (namespace.name:methodname) or all classes in the given image (@imagename) before executing the main application.

--profile

Collect profiling information and dump it at the end of the process.

DEBUGGING FORMATS

The following debugging formats are currently supported: stabs Writes out stabs debug information. dwarf Writes out dwarf debug information. mono Use a symbol file which has been created by MCS. It can be used to get source lines in stack traces. The "stabs" and "dwarf" formats support the following options:

filename=FILENAME

Write debugging information into FILENAME. This file must be run through the assembler to create an object file.

objfile=FILENAME

When automatically assembling the symbol file, write the resulting object file into FILENAME.

dont_assemble

Normally, the symbol file is automatically assem- bled to an object file when you call "mono_debug_make_symbols". Use this option to dis- able this behaviour.

install_il_files

Put the generated *.il files in the same directory than the assembly they came from. The default is to put them into the current working directory.

dont_update_il_files

Normally, the *.il files are recreated if their assemblies have changed when you call "mono_debug_make_symbols". Use this option to dis- able this behaviour.

dont_create_il_files

Update the *.il files if their assemblies have changed, but only if the file already exists.

A. Credits

Author: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - The Mono Disassembler

The Mono Handbook > The Mono Disassembler

The Mono Disassembler

Monos disassembler is written in C.

The monodis program is used to dump the contents a CIL
image (contained in .EXE files that contain extended
PE/COFF CIL code).

I. Simple use

It can you can execute it by typing:

monodis <myfile.exe>

II. Options

The following Generic options are supported:

--help , -h

Displays usage instructions.

--output=FILENAME

Write output into FILENAME.

--mscorlib

For non-corlib assemblies, use "mscorlib" as the assembly name. This is useful for round-tripping the IL with ilasm.

--assembly

Dumps the contents of the assembly table

--assemblyref

Dumps the contents of the assemblyref table

--classlayout

Dumps the contents of the classlayout table

--constant

Dumps the contents of the constant table

--event

Dumps the contents of the event table

--exported

Dumps the contents of the ExportedTypes table

--fields

Dumps the contents of the fields table

--file

Dumps the contents of the file table

--interface

Dumps the contents of the interface table

--manifest

Dumps the contents of the manifest table.

--memberref

Dumps the contents of the memberref table

--method

Dumps the contents of the method table

--methodsem

Dumps the contents of the methodsem table

--module

Dumps the contents of the module table

--moduleref

Dumps the contents of the moduleref table

--param

Dumps the contents of the param table

--property

Dumps the contents of the property table

--propertymap

Dumps the contents of the propertymap table

--typedef

Dumps the contents of the typedef table

--typeref

Dumps the contents of the typeref table If no flags are specified the program dumps the content of the image in a format that can be used to rountrip the code.

A. Credits

Author: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - Useful tools: NUnit, NAnt, and NGen

The Mono Handbook > Useful tools: NUnit, NAnt, and NGen

Useful tools: NUnit, NAnt, and NGen

by Johannes Roith (johannes@jroith.de)

Contents

  • I. The NUnit testing framework
  • II. The NAnt build tool
  • III. NGen - pre-compiling

I. The NUnit testing framework

Introduction

NUnit is a unit-testing framework for all .Net languages. Initially ported from JUnit, the current version, 2.0 is the second major release of this xUnit based unit testing tool for Microsoft .NET. It is written entirely in C# and has been completely redesigned to take advantage of many .NET language features, for example custom attributes and other reflection related capabilities. NUnit brings xUnit to all .NET languages.

Commandline options

Content copied from nunit.org

Forms Interface

The forms interface has two command line options. If the program is started without any command line parameters it automatically loads the most recently loaded assembly. It does not automatically run it just loads the assembly. The forms interface also keeps track of the 5 most recently loaded assemblies. To access these see the File->Recent Assemblies menu item.

The other option is to specify the assembly on the command line. The following will start the forms interface with the assembly: nunit.tests.dll

nunit-gui.exe /assembly:nunit.tests.dll

Console Interface

The console interface has a few additional options compared to the forms interface. The console program must always specify a command line parameter. The console interface always creates an XML representation of the test results. This file by default is called TestResult.xml and is placed in the working directory.

Note: By default the nunit-console program is not added to your path. You must do this manually if this is the desired behavior.

Specifying an Assembly

The console program must always have an assembly specified. To run the tests contained in the nunit.tests.dll use the following command:

nunit-console /assembly:nunit.tests.dll

Specifying an Assembly and a Fixture

When specifying a a fixture, you must give the full name of the test fixture along with the containing assembly. For example, to run the NUnit.Tests.AssertionTests in the nunit.tests.dll assembly use the following command:

nunit-console /fixture:NUnit.Tests.AssertionTests
   /assembly:nunit.tests.dll

Specifying the XML file name

As stated above, the console program always creates an XML representation of the test results. To change the name to "console-test.xml" use the following command line option:

nunit-console /assembly:nunit.tests.dll /xml:console-test.xml

Specifying the Transform file

The console interface uses XSLT to transform the test results from the XML file to what is printed to the screen when the program executes. The console interface has a default transformation that is part of the executable. To specify your own transformation named "myTransform.xslt" use the following command line option:

nunit-console /assembly:nunit.tests.dll /transform:myTransform.xslt

Note: For additional information see the XML schema for the test results. This file is in the same directory as the executable and is called Results.xsd. The default transform Summary.xslt is located in the framework source directory.

II. The NAnt build tool

[TODO]

III. NGen - pre-compiling

This tool is still in heavy development.

[TODO]

© Copyright 2002 by Johannes Roith


The Mono Handbook - The Mono runtime

The Mono Handbook > The Mono runtime

The Mono runtime

Contents

  • 1. Current JIT Engine
  • 2. New JIT engine
  • 3. Garbage Collection
  • 4. IO and threading
  • 5. Useful links
  • 6. PInvoke
  • 7. Remoting
  • 8. Porting
  • 9. COM and XPCOM

The Mono runtime implements a JIT engine for the CIL virtual machine (as well as a byte code interpreter, this is to quickly port it to new systems), the class loader, the garbage collector, threading system and metadata access libraries.

We currently have two runtimes:

  • mono: The Just In Time compiler implemented using a BURS instruction selector. We only support x86 machines in the JIT engine at this point.
  • mint: The Mono interpreter. This is an easy-to-port runtime engine.

Currently we are using the Boehm conservative garbage collector.

The Mono runtime can be used as a stand-alone process, or it can be embedded into applications (see the documentation in mono/samples/embed for more details).
Embedding the Mono runtime allows applications to be extended in C# while reusing all of the existing C and C++ code.

Paolo Molaro did a presentation on the current JIT engine and the new JIT engine. You can find his slides here

Current JIT Engine (January 12th, 2002)

The JIT engine uses a code-generator generator approach for compilation. Given the properties of CIL byte codes, we can take full advantage of a real instruction selector for our code generator.

The JIT engine implements a number of optimizations:

  • Opcode cost estimates (our architecture allows us to generate different code paths depending on the target CPU dynamically).
  • Inlining.
  • Constant folding. Although compilers typically do constant folding, the combination of inlining with constant folding gives some very good results.
  • Linear scan register allocation. In the past, register allocation was our achilles heel, but now we have left this problem behind.
There are a couple of books that deal with this technique: "A Retargetable C Compiler" and "Advanced Compiler Design and Implementation" are good references. You can also get a technical description of lbrug. A few papers that describe the instruction selector:
  • A code generation interface for ANSI C
  • Engineering efficient code generators using tree matching and dynamic programming.

New JIT engine.

We are working on a new JIT engine. The new JIT engine focuses on portability and in two intermediate representations that simplify the development of optimizations. This together with the Ahead-of-Time compilation will allow developers to deploy applications that match the speed of natively compiled code.

Garbage Collection

Currently we are using the Boehm conservative GC. Although our plans are to move to the Intel ORP GC engine, our plans on a next generation dual-JIT engine have to be taken into account.

We will be using the Intel ORP GC engine as it provides a precise garbage collector engine, similar to what is available on the .NET environment.

Although using a conservative garbage collector like Bohem's would work, all the type information is available at runtime, so we can actually implement a better collector than a conservative collector.

  • Garbage collection list and FAQ: http://www.iecc.com/gclist/
  • "GC points in a Threaded Environment": http://research.sun.com/techrep/1998/abstract-70.html
  • "A Generational Mostly-concurrent Garbage Collector": http://research.sun.com/techrep/2000/abstract-88.html
  • Details on The Microsoft .NET Garbage Collection Implementation: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/GCI.asp http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnmag00/html/GCI2.asp

IO and threading

The ECMA runtime and the .NET runtime assume an IO model and a threading model that is very similar to the Win32 API.

Dick Porter has been working on the Mono abstraction layer that allows our runtime to execute code that depend on this behaviour.

Useful links

Paolo Molaro found a few interesting links:

  • On compilation of stack-based languages: http://www.complang.tuwien.ac.at/projects/rafts.html
  • A paper on fast JIT compilation of a stack-based language: http://www.research.microsoft.com/~cwfraser/pldi99codegen.pdf
  • Vmgen generates much of the code for efficient virtual machine (VM) interpreters from simple descriptions of the VM instructions: http://www.complang.tuwien.ac.at/anton/vmgen

PInvoke

PInvoke is the mechanism we are using to wrap Unix API calls as well as talking to system libraries.
Initially we used libffi, but it was fairly slow, so we have reused parts of the JIT work to create efficient PInvoke trampolines.

Remoting

Mono has support for remoting and proxy objects, just like
.NET does. The runtime provides these facilities.

Porting

If you are interested in porting the Mono runtime to other platforms, you might find the pre-compiled
Mono regression test suite useful to debug your implementation.

COM and XPCOM

We plan on adding support for XPCOM on Unix and COM on Microsoft Windows later in our development process.

A. Credits

Author: Johannes Roith (johannes@jroith.de)
Author: Miguel de Icaza (miguel@ximian.com)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - XML

The Mono Handbook > XML

Xml

Introduction

Xml (EXtensible Markup Language) is a Web Standard formed by the W3C.

It can be used as a data or document file format, for example HTML is one or an Office file format (all OpenOffice.org files are Xml). The advantage is, that there are lots of tools and APIs available to deal with xml and it can be easily edited by hand.

Microsoft has claimed, that Xml would be a central file format in .NET.
Entsprechend big is the class library offered to work with Xml.

You can:

  • Read and write Xml documents with the Xml DOM
  • Read Xml documents with XPath, a very powerful Query language.
  • Use Xslt transformations
  • Work with Xml and ADO.NET

A. Credits

Authors: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - XML

The Mono Handbook > XML > XPath tutorial

Xml DOM

Contents

  • 1. Introduction

A. Credits

Authors: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - XML

The Mono Handbook > XML > XPath tutorial

XPath tutorial

Contents

  • 1. Introduction
  • 2. Using XPath with mono
  • 3. XPath Expressions
    • 3.1 Basic Path Syntax
    • 3.1 Advanced Path Syntax
    • 3.3 star *
    • 3.4 Expresion in square brackets
    • 3.5 Attributes
    • 3.6 Values of attributes as selection criteria
    • 3.7 count() function
    • 3.8 name() function
    • 3.9 string-length() function
    • 3.10 Combining several paths
    • 3.11 child axis
    • 3.12 descendant axis
    • 3.13 Example 13
    • 3.14 Example 14
    • 3.15 Example 15
    • 3.16 Example 16
    • 3.17 Example 17
    • 3.18 Example 18
    • 3.19 Example 19
    • 3.20 Example 20
    • 3.21 Example 21
    • 3.22 Example 22

A. Credits

Authors: Johannes Roith (johannes@jroith.de)
Misc: Based on work by Miloslav Nic (nicmila@systinet.com), Jiri Jirat (Jiri.Jirat@systinet.com)

The Mono Handbook - © Copyright 2002 by Johannes Roith


The Mono Handbook - XML - Xsl

The Mono Handbook > XML > Xsl Transformations

Xsl transformations

Contents

  • 1. Introduction
  • 2. Transformation Class
  • 3. Introduction to Xsl

A. Credits

Authors: Johannes Roith (johannes@jroith.de)

The Mono Handbook - © Copyright 2002 by Johannes Roith