Table of contents

    The Class Library

    The Class Library is be compatible with Microsoft’s .NET implementation. We will write as much code as possible in C#. We may need to interface with code written in C to gain access to the functionality of libraries like libart, Gtk+, and libc.


    We welcome contributions to the the Class Library. To get started, check the status page for information about which APIs are being worked on, and how to get in touch with individual maintainers.

    If you want to work on a class, first check the Classes Distribution to see if it is not implemented yet, if not, check the class status pages to see if someone is already working on it, and maybe contact them.

    If nobody is working on it, mail with the class you want to implement and CC

    You can also track live the activities of the Mono git module by subscribing to the mono-cvs-list


    The Class Library resides in the `mcs’ module in the directoy `class’.

    Each directory in the directory represents the assembly where the code belongs to, and inside each directory we divide the code based on the namespace they implement.

    For example, the “corlib” directory contains mscorlib:


    Inside that directory the namespaces appear:


    And we use a file per class in each of those directories.


    The class library is being licensed under the terms of the MIT license. This is the same license used by the X11 window system.

    Class Library testing

    We need to write regression tests that will verify the correctness of the class library, compiler, and JIT engine.

    Please write your regression tests using NUnit

    Coding conventions

    See our Coding Guidelines document for details on the coding conventions.

    Missing implementation bits

    If you implement a class and you are missing implementation bits, please use the MonoTODO attribute and a description of what is missing to be implemented, for example:

       [MonoTODO ("Finish this routine")]
       string Greet () {
           throw new NotImplementedException ();

    Tagging buggy code

    If there is a bug in your implementation tag the problem by using the word “FIXME” in the code, together with a description of the problem. Do not use XXX or obscure descriptions, because otherwise people will not be able to understand what you mean.

    Tagging Incomplete Specifications

    Sometimes the specification will be lame (consider Version.ToString (fieldCount) where there is no way of knowing how many fields are available, making the API not only stupid, but leading to unreliable code). In those cases, use the keyword “LAMESPEC”.


    Frequently asked questions about the class library:

    I am writing a new class that overrides one of the system classes, and I am getting a 1595 warning from the compiler. Should we use a different namespace?

    There is a quick solution to the problem, you can pass the command line argument /nowarn:1595 and this will effectively let you use your implementation of the code, while overriding the ones from the system assemblies