From MonoDevelop

If you want to contribute on the development of MonoDevelop, implement your own tools based on the platform, create new add-ins for the IDE, or just know more about the project, you'll find some useful information in this page. Here are some interesting links to start with:

• Articles: A collection of articles written by the MonoDevelop community. You'll find technical documentation, tutorials and other useful information for learning about the MonoDevelop platform.

• TODO: A list of features we would like MD to have. If you want to contribute, just pick one of them and notify through the mailing list (http://lists.ximian.com/mailman/listinfo/monodevelop-list) that your are going to work on it.

• The quick guide to Development: Getting Started.

Table of contents

1 Extending MonoDevelop 2 Contribute 2.1 Reporting Bugs 2.2 Submitting Patches 2.3 Commit Rules 2.4 Coding Guidelines 2.5 A Note on Licensing 2.6 Working on the Website 3 Documentation

Extending MonoDevelop

MonoDevelop is not just an IDE, it's an extensible platform upon which any kind of development tool can be built (in fact, any kind of application).

The platform has a modular design, so you can freely choose the level of features that better fits your needs, and avoid unneeded dependencies. This is a general view of what MonoDevelop provides:

• The MonoDevelop Core: Is the core runtime of MonoDevelop. Together with some basic services, it provides the Add-in engine, which is fundamental to the platform, since almost everything in MonoDevelop is an add-in. It not only provides an API for loading add-ins, but also command-line and graphical tools for managing those add-ins.

• The Projects API: Using this API it is possible to develop applications that create, open, change, build and do whatever you need to do with MonoDevelop projects.

• The MonoDevelop IDE: This application puts together all the previous services to offer a powerful and extensible IDE for managing development projects.

There are many kind of projects you can build upon the MonoDevelop platform. Here are some examples:

• IDE extensions: You can implement add-ins which add new capabilities to the MonoDevelop IDE. Add-ins can create new pads, file viewers, add new menus and menu options, extend the project and class tree, etc.

• Project extensions: You can provide new types of projects with custom file formats and build rules. Any application making use of the Projects API will be able to read and manage your projects.

• Development tools: If you are building a development tool and don't want to integrate it into the IDE, you can create your own GUI (or just console UI) and still take advantage of the Projects API and the add-in engine.

• Other applications: If you just want to implement an application and take advantage of the MonoDevelop add-in engine, you just need to link to the MonoDevelop Core.

Contribute

MonoDevelop is always looking for contributors to help with development. If you have some time and want to help, there are instructions below.

Reporting Bugs

Reporting bugs is a very easy way to help contribute to any project. MonoDevelop bugs are be filed at bugzilla.novell.com.

To report a bug, follow the steps below:

1. Create a Bugzilla account (http://secure-www.novell.com/selfreg/jsp/createSimpleAccount.jsp?target=https%3A//bugzilla.novell.com/ichainlogin.cgi%3Ftarget%3Dindex.cgi%3FGoAheadAndLogIn%253D1).
2. Ensure the bug you are reporting hasn't already been fixed. Install the latest version of MonoDevelop using the "Current Development" instructions on the download page.
3. Review the open MonoDevelop bugs (http://bugzilla.novell.com/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=fulltext&long_desc=&classification=Mono&product=MonoDevelop+&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=anywords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=) and make sure that your bug hasn't been submitted already.
4. If it hasn't been submitted, submit a new MonoDevelop bug (http://bugzilla.novell.com/enter_bug.cgi?classification=&product=MonoDevelop+&submit=Use+This+Product).

Error traces gathered by running MD from a terminal are often helpful in tracking down a bug. For more information read the article on logging.

Submitting Patches

If you submit a patch, it's always best to create the patch against the current snapshot version of MonoDevelop. To do it:

1. Check out the source code from the repository (see Download).
2. Make the changes you want to make.
3. Write a ChangeLog entry for every change. There is a ChangeLog file at every assembly directory (that is, every subdirectory below Core/src and Extras).
4. Run 'svn diff > change.patch' at the directory of the assembly you changed (see here (http://lists.ximian.com/pipermail/mono-patches/2005-November/066456.html) for an example of patch).

If you cannot use this, then make sure you have the source for the latest release, and do the following:

1. Copy the file before you edit it.
2. Make the changes you want to make and save the file.
3. On the command line type diff -u oldfile.cs newfile.cs > vardec.patch. The name of the patch should be something quick which describes what you fixed.

If the patch fixes a bug, it's better to create a bug in bugzilla.novell.com and attach the patch to the bug. If you're patching against a pre-existing bug, just attach to the bug. Otherwise you can just send the patch to the MonoDevelop Mailing List (http://lists.ximian.com/mailman/listinfo/monodevelop-list).

The commit archive can be found here (http://lists.ximian.com/pipermail/mono-patches/).

If you have SVN commit rights, it is preferable to use the svnci script which is located in the top monodevelop directory. This script will ensure that the commit message for each subdirectory is the same as the change made to the according ChangeLog.

Commit Rules

There are a few rules to follow when committing code:

1. Always add a ChangeLog entry with a meaningful explanation. Every assembly has its own ChangeLog file.
2. Enter a meaningful explanation in the commit log message as well. That's usually the same message you write in the ChangeLog.
3. When entering a message describing a change, take into account that the goal is to explain why the change was done, rather than what was changed. For example, the message "Added property X" is in general useless since it is obvious looking at the patch.
4. Don't do commits which involve more than one assembly. Do one commit per assembly. As an exception, it is OK to commit a change involving several assemblies if the change done is the same for all files (for example, a global class rename, or tracking a change in the API).
5. Don't do reformatting commits, unless you're the original author of the code.
6. Never remove copyright notices from the code.
7. Never remove licensing info from code.
8. Never commit code you didn't write yourself or code that doesn't have a suitable license.

Coding Guidelines

New code written for MonoDevelop should follow the generic Mono Coding Guidelines (http://www.mono-project.com/Coding_Guidelines).

You should also follow our Human Interface Guidelines when designing windows and dialogs.

A Note on Licensing

All new code must be licensed under either a MIT X11 (http://www.opensource.org/licenses/mit-license.php) or LGPL (http://www.opensource.org/licenses/lgpl-license.php) license. Code licensed under the GPL (http://www.opensource.org/licenses/gpl-license.php) cannot be accepted.

Working on the Website

We are always looking for help on developing the Monodevelop web site. If you're interested, please contact lluis at ximian dot com. Currently, we're are looking for the following:

• Tutorials
• Screenshots
• Content writers

Any contributions you may have though would be appreciated. The list above is in no way all inclusive.

Documentation

Here is some documentation about the MonoDevelop project:

• Articles: A collection of articles written by the MonoDevelop comunity.

• Development Roadmap: What you need to know about the future plans of MonoDevelop development.

This page was last modified 23:35, 9 May 2008.

Content is available under GNU Free Documentation License 1.2.