This page lists some ideas for Mono GSoC projects that students can apply for. Additionally, we encourage students to submit their own interesting Mono-related project proposals. In past years, roughly 20% of the accepted proposals were original ideas from students instead of from our suggestions. You can submit more than one proposal, so you can submit your own ideas as well as apply for one from this list - but only one can be chosen, of course!

You can use the following links to jump to sections that you're interested in:

Other Ideas

If a project is not listed here, but you think you have a great idea, feel free to contact the Mono team, mentors and org admins to discuss or suggest your own project ideas.

Over the past years we have picked projects that were not listed here because they were great ideas, and we had students that were passionate about those projects. In the end, most of these projects were a success.

Do not be afraid to pick up a project that would be interesting and also help the Mono universe.

You can find some additional ideas on the MonkeySquare ideas page, and on the Gnome ideas page (Mono-based projects in Gnome: Banshee, Blam, Tasque, Tomboy, GBrainy, Mistelix, F-Spot, ChronoJump, SparkleShare, LongoMatch).

Class Libraries and Bindings

Cocos3D for XNA

Complexity: Medium

Area: Graphics, C#, XNA

Cocos3D is a set of API extensions to Cocos2D that brings 3D capabilities to the popular game engine. There is a cross platform C# version of Cocos2D called Cocos2D-XNA. The objective of this project is to port the 3D extensions from Objective-C/OpenGLES 2.0 to C# and the XNA APIs.

The C#/XNA Cocos2D is available here: https://github.com/totallyevil/cocos2d-xna

The Cocos3D is available here: https://github.com/cocos3d/cocos3d

Mentors: Miguel de Icaza

Ogre Bindings

Complexity: Medium

Area: C#, C++, Graphics

Working with the new C++ binding generator that produces C#, create a binding for the Ogre toolkit that runs on Linux.

Mentors: Miguel de Icaza, Joao Matos

Three.js port to C#

Complexity: Medium

Area: C#, Graphics

Port the popular Javascript Three.js library to C#.

Unlike Three.js, we won't initially support multiple backends, we will only have one (OpenGL or MonoGame) and will defer the backend until later.

Mentors: Miguel de Icaza

Mono Runtime

Implement a replacing write barrier for sgen

Complexity: Medium

Area: GC, IL, Assembly

Right now sgen uses a non-replacing write barrier, we want to switch to a replacing one and have fast paths to do so.

Deliverable: Implement replacing barriers with IL then add JIT support for them and implement those for x86, amd64 and arm.

Mentors: Mark Probst

More and better benchmarks for our suite

Complexity: medium

Area: C#

We have a benchmark suite that we mainly use to benchmark our GC, but it's not very comprehensive and many of the benchmarks are very simplistic. Ideally we'd have something along the lines of the DaCapo or SPECjava benchmarks. The goal here is not to implement new benchmarks, but to find existing code that can be turned into benchmarks, and/or adapt or convert benchmark suites of non-CLR languages.

Deliverables: A number of complex, more real-world benchmarks integrated into our suite

Mentors: Mark Probst

MonoDevelop / Xamarin Studio

Revamped Syntax Highlighting System

Complexity: Medium/Hard

Area: Parsers, Text Editor

The syntax highlighting in MonoDevelop is done by defining a grammar as xml file to colorize tokens. Some highlightings are extended with hand written code. The highlighting system can be made faster, more extensible (atm it's difficult to write semantic highlightings) and more scaleable . You will first need to understand how our highlighting files are defined and how the semantic highlighting currently works. After that a new implementation approach needs to be implemented. One of our current drawbacks are that regular expressions could be integrated better - for example span begin/end constructs aren't atm regular. In fact everything should be based on regular expressions. Esp. important is to have a system that allows to plug in semantic highlightings and highlightings should be embeddable. (Semantic highlighting works inside of asp.net files for example)

Deliverables: An extensible syntax highlighting system that reads our xml files or a similar format. It should be scalable even for large files (lazy analysis) and much faster than the current implementation (speed tests included).

Mentors: Mike Krüger

Source Analysis

Complexity: Medium

Area: Parsers, C#

The IDE supports source analysis using NRefactory to parse, understand and analyze source code. There are almost unlimited possibilities what can be done to analyze or restructure source code. The system is very flexible. We already support a set of actions and code analyzation rules. But we need even more - if you like source code analysis or refactoring it's your chance to work in this area.

Deliverables: As much code actions & code issues as possible (we've some ideas for them in our bug tracker)

Mentors: Mike Krüger

On the Fly Formatting Engine

Complexity: Hard

Area: Parsers, C#

The on the fly indentation in Xamarin Studio needs a rewrite. The current implementation is a bit flaky and doesn't respect many formatting rules. The engine should respect all formatting settings and give the user a good typing flow. The engine should format code while typed as sell as possible. There is already an implementation for that but it needs more work. The goal is to implement a really good indentation engine that is fast and scales, which is not that simple.

Deliverables: A working indenter & formatting engine with many unit tests. Some groundwork has already been done.

Mentors: Mike Krüger

CSS Support

Complexity: Medium

Area: C#, CSS

Full CSS support would be very useful for developers writing web apps and embedding HTML pages in desktop and mobile apps. This includes code completion, code folding, syntax highlighting, document outline, etc. It should work in standalone CSS files and inline in HTML, CSHTML and ASPX files. CSS is relatively simple, so there would be potential to investigate more interesting and advanced features such as support for browser profiles, checking for common errors, and pads for interactive editing of styles.

Deliverables: CSS editing support in standalone files and inline in HTML/CSHTML files.

Mentors: Michael Hutchinson, Bojan Rajkovic

Javascript Support

Complexity: Hard

Area: C#, Javascript

Full Javascript support would be very useful for developers writing web apps and embedding HTML pages in desktop and mobile apps. This includes code completion, code folding, syntax highlighting, document outline, etc. It should work in standalone JS files and inline in HTML, CSHTML and ASPX files. The code completion should be capable of handling common JS frameworks such as JQuery. There are several open-source managed JS/AS parsers that could perhaps be used.

Deliverables: JS editing support in standalone files and inline in HTML/CSHTML files.

Mentors: Michael Hutchinson, Bojan Rajkovic

Improve C/C++ Binding

Complexity: Hard

Area: C#, C, C++

The C/C++ binding is an undermaintained area of Xamarin Studio. The first part of this project would be to generally polish it and fix bugs, perhaps adding support for the clang and mingw32 compilers. The second part would be to replace the ctags parser with libclang, and generally improve code completion and code navigation.

Deliverables: Negotiable, but should substantially improve C/C++ code completion.

Mentors: Michael Hutchinson, Joao Matos (triton)

Improve C/C++ build support in XBuild

Complexity: Medium

Area: C#, C, C++

The C/C++ build support in xbuild was much improved in GSoC 2011 but still needs some work to better integrate other compilers than MSVC. The first part of this project would be to generally polish it and fix bugs, and add support for the Clang and GCC compilers. This involves adding a mapping from the VS-compatible parameters to the respective command line options on those compilers. The second part would be to improve the C++ binding in MonoDevelop (see entry above) to use this and be able to compile and load and save MSBuild C++ projects from the IDE in Windows and OSX/Linux.

Deliverables: Negotiable, but should substantially improve C/C++ build support.

Mentors: Joao Matos (triton), Atsushi Eno

Make ASP.NET Awesome in Xamarin Studio

Complexity: Easy

Area: C#, ASP.NET

Xamarin Studio ASP.NET support is still maintained but has not been very actively developed in some time. There's lots of room for polishing it and adding minor but useful features - for example, deploying to remote servers, being able to choose which web browser to launch when running/debugging, C# tooltips and navigation in Razor files, etc. There's a lot of flexibility in this project to propose which features you want to work on - it doesn't even have to include the aforementioned examples.

Deliverables: Polish ASP.NET addin, implement some number of minor features.

Mentors: Michael Hutchinson, Bojan Rajkovic

Windows .NET 4.0 debugging

Complexity: Hard

Port the .NET debugging addin to the new debugging APIs in the Microsoft .NET 4.0 runtime, add support for 64-bit debugging, and generally polish the .NET debugging support.

Deliverables: reliable debugging for 64-bit and 32-bit Microsoft .NET 4.0.

Mentors: Jeff Stedfast

Color Scheme Editor

Complexity: Easy/Medium

Area: Text Editor

The current color style editor is hard to use and is missing some features. It would be nice to have a color style editor that works like http://studiostyl.es/schemes/create. Furthermore it would be nice to have an editor mode where you can just adjust some colors and other colors are chosen using an algorithm providing good contrasts. The implementation should be done using xwt - a great cross platform development library.

Deliverables: an awesome color scheme editor

Mentors: Mike Krüger

Netduino support for Xamarin Studio

Complexity: Medium

Area: IDE, Build, Netduino

References: Netduino.com, http://forums.netduino.com/index.php?/forum/12-mono/

Netduino is an Open Source microcontroller that runs the .NET Micro Framework (.NET MF - www.netmf.com). Currently, there is semi-functional alpha support to write code targeting the .NET Micro Framework using MonoDevelop and the Microsoft .NET MF Bootloader. However, there are several issues that can be fixed and the toolchain overall needs an improvement. This project would entail fixing the issues so that building apps to target Netduino in Xamarin Studio and then deploying them would be a relatively painless experience.

Deliverables: A Xamarin Studio Add-In that allows you to build against the .NET MF and then deploy to a connected Netduino.

Mentors: Bryan Costanich, Nina Vyedin, Alex Corrado, Alex Rønne Petersen

Tools and Compilers

Port the Clang C++/CLI compiler to POSIX platforms

Complexity: Easy

Area: C#, C, C++, C++/CLI

Platforms: Windows / Visual Studio 2012

Right now the C++/CLI compiler uses Mono.Cecil to read the metadata of the managed assemblies. This causes a problem because we have no existing compiler apart from the Microsoft one to bootstrap it. You will modify the compiler (mostly the SemaCLI.cpp file) to use the Mono unmanaged metadata reading APIs and port the compiler.

Deliverables: Compiler compiles and runs examples in OSX / Linux.

Mentors: Joao Matos (triton), Alex Rønne Petersen

Implement missing CLI features in the Clang C++/CLI compiler

Complexity: Hard

Area: C#, C, C++, C++/CLI

Platforms: Windows / Visual Studio 2012

Right now the C++/CLI compiler has support for a lot of CLI features but is still missing support for things like exceptions, events, literal and init only fields, static constructors and other more exotic features. You will need familiarity with the ECMA-372 standard, Clang IR generation code and CLI metadata concepts.

Deliverables: Negotiable, but should at least add a couple of missing features.

Mentors: Joao Matos (triton), Alex Rønne Petersen

Implement mixed-mode calls in the Clang C++/CLI compiler

Complexity: Hard

Area: C#, C, C++, C++/CLI

Platforms: Windows / Visual Studio 2012

Right now the C++/CLI compiler emits CIL code for native and managed classes. You will modify Clang frontend to emit native classes as native code and managed classes as CIL code and emit calls to the Mono runtime when making transitions from native to managed.

Deliverables: Negotiable, but should substantially improve C++/ code completion.

Mentors: Joao Matos (triton), Alex Rønne Petersen

Implement "stack optimizations" in the LLVM CIL backend

Complexity: Medium

Area: C++, C++/CLI, LLVM

References: http://elc.yonsei.ac.kr/publications/treegraphs.pdf

Right now the CIL code generated by the LLVM CIL backend is very naive and generates a lot of spills and loads. You will modify the backend to implement some optimizations so the code keeps values in the stack that will be used later and try to minimize the number of operations on the stack. would be doable.

Deliverables: Negotiable, but should at the very least have optimizations on the basic block level (vs. optimizations across basic blocks).

Mentors: Joao Matos

GTK#

Improve GTK# binding support on the desktop

Complexity: Medium

Area: C#, C, GLib libraries

There is an ongoing effort to automate the generation of C# bindings on the GNOME desktop by leveraging the new GObject introspection data that is now available for most libraries. GObject introspection data includes xml files and typeobject files (binary) describing the APIs a library exposes. The bindinator project (https://github.com/andreiagaita/bindinator) takes this information and produces gapi files that can then be used with GTK# gapi tools for generating C# bindings.

The task is to finish the bindinator project so that it can generate bindings automatically, preferably with no manual intervention (if possible, sometimes some manual tweaking of bindings is needed to improve the api, fix corner cases or provide backward compatibility with existing bindings). The bindinator is currently at a point where it should be able to generate Webkit-Gtk bindings automatically.

The importance of this project cannot be overstated: having up to date bindings of all major libraries on the desktop is essential for developers to create apps with C# and keeping it alive and kicking in the Linux desktop and across platforms.

Deliverables: Have the core gtk libraries bound (it can be by finishing existing bindings in GTK# and adding new ones via the bindinator) plus Webkit-GTK and GStreamer libraries, with a process in place so that package owners and/or distro package managers can generate new bindings easily.

Mentors: Andreia Gaita, Jérémie Laval

Integrate GTK# bindinator with MonoDevelop

Complexity: Medium

Area: C#, MonoDevelop, ASP.NET

The idea would be to implement something similar to .NET 2.0 WebServices where you can register a WSDL file (Web References) in your project and have the backing code automatically for you. This project would do the same thing by adding a GIR References folder where people can drop in a .gir and have the binding automatically generated for them. The only file needed to compile the project would thus be the .gir file.

Additionally, an ASP.NET website providing a common repository of those GIR files (curated by the community) will be created for use within MonoDevelop. This could be integrated with Cydin (MD addins gallery) which would need to be modified for it or, if not practical, a custom gallery should be created. Once the website is in place, it should be integrated within MonoDevelop so that the available GIR files are directly accessible from the IDE.

Deliverables: A MonoDevelop addin allowing automatic integration with the bindinator. A new gallery website to allow retrieval of GIR file directly from the Web (based on Cydin or custom). Integration from within MonoDevelop with this gallery.

Mentors: Andreia Gaita, Jérémie Laval

F#

Refactoring support for F#

Complexity: Medium/Large

Area: F#

Description: Several projects have considered the need for F# refactoring tools. This project would look at adding the capability to Xamarin Studio/Monodevelop, possibly via a modified version of the F# compiler DLL for AST support. This would in turn enable a wide range of improvements to the F# editing support.

Deliverables: An integration of refactoring support into the IDE, preferably based on a reusable rich interface to the F# AST.

Mentors: Robin Neatherway

Improve Xamarin Studio F# experience

Complexity: Medium

Area: F#

Description: There are a number of rough edges in the F# experience currently. Smoothing these would help adoption. One example is a number of bugs in the tooltip code. New features requested by the community include (i) presenting a type signature when attempting to jump to definition of external code, (ii) automatically resolving missing references based on heuristics and (iii) offering skeleton implementations of interface methods. Other improvements to be suggested by prospective students.

Deliverables: Negotiable, but offering a significant improvement to the current experience.

Mentors: Robin Neatherway

Language interface Type Providers

Complexity: Medium/Large

Area: F# / Python / Java

Description: Recent exciting project are the FunScript project (https://github.com/ZachBray/FunScript) and the R type provider (https://github.com/BlueMountainCapital/FSharpRProvider), allowing strongly typed access to other languages from within F#. Many other languages remain! The prospective student should investigate suitable options for similar treatment and offer a proposal supporting the choice of language. IronPython is one possibility to consider. Interacting with Java is another via one of several routes:

- Import JVM types use IKVM to access them and target .NET

- Import JVM types target Java through quotations and compile for JVM

- Import JVM types target Java Byte Code through quotations and compile for JVM

Deliverables: Complete type provider(s) with documentation and

tutorials showing the facilities offered. Preferably at least one

video demonstration.

Mentors: Zach Bray, Robin Neatherway

Applications

Awesome MonoDoc Editor

Complexity: Medium

Area: Application, design, cross-platform

MonoDoc is the documentation format used by every component of the Mono project. We use several frontends on various platforms like Web (go-mono.com/docs), Linux/Windows (GTK#) and Mac (MonoMac). Currently the only way to edit documentation is through raw editing of the produced XMLs.

We would love a sexy editor that was specialized for docs. That editor would be abstracted as much as possible from the backend so that, while it gives access to every style attribute available in MonoDoc, it could be easily ported to other platforms. Additionally, the student should implement at least an XWT frontend on top of the cross-platform core to show it off. A great "stretch goal" would be demonstrating platform-specific additional behavior (e.g., an iOS browser with the ability to mark text for editing / rewrite).

Deliverables: A C#, GUI-toolkit independent editor component, and one or two frontend implementations (among MonoMac, GTK#, Web, and iOS)

Mentor: Larry O'Brien

Contacting the Mono Team

If you have questions or suggestions that you want to make in real-time and talk to a member of the team, please join us on IRC on the server "irc.gnome.org" in channel "#monosoc", "#monodev" or the "#mono" channel. Various mentors and students from past years are usually there and can answer some quick questions about the program and about Mono.

The mailing lists are a very important communication channel, students should use them to get more information and feedback about ideas and proposals. Community engagement is essential for a successful summer of code, so get involved!

For any questions you may have about the program itself and to talk to the Mono GSoC admin, you can use soc@xamarin.com.

Mailing Lists

http://lists.ximian.com/mailman/listinfo/mono-devel-list A mailing list dedicated to discussions about developing Mono itself, such as development of the runtime, class libraries, and related Mono projects.

http://lists.ximian.com/mailman/listinfo/monodevelop-devel-list Discussion on the development/implementation of MonoDevelop.

A complete breakdown of all Mono mailing lists is available at Mailing Lists.