Google Summer of Code (GSoC) (http://code.google.com/soc/) is a program that offers student developers stipends to write code for various open source projects. Google will be working with several open source, free software, and technology-related groups to identify and fund several projects over a three month period.

The following is a list of Mono project ideas that students can apply for. Additionally, we encourage students to submit their own interesting Mono-related project proposals. In 2007, 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. (Only one can be chosen of course!)

Please note that to apply for GSoC, you will need to go through the standard Google application process. You do not apply directly to the Mono Project. Any questions or comments about this page can be sent to Miguel (miguel@novell.com).

For inspiration, here are the projects from previous years:

• 2009 Projects (http://socghop.appspot.com/gsoc/org/home/google/gsoc2009/mono)
• 2008 Projects (http://code.google.com/soc/2008/mono/about.html)
• 2007 Projects
• 2006 Projects
• 2005 Projects (follow-up review (http://tirania.org/blog/archive/2006/Apr-13.html))

Important: Projects

If a project is not listed here, but you think you got yourself a great idea, feel free to contact our mentors, Miguel or to suggest your own project.

Over the past three 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.

Ground Rules

Language: Code must be written in the same language as the host of the project:

• GCC extensions in C
• Mono VM extensions in C
• Tools extensions in C#
• APIs in C#
• etc.

Licensing: All of the code submitted must be contributed under the terms of the MIT X11 license.

Acceptance criteria: The results must be maintainable and clean. If the code works as advertised but its a quick hack or something we would have to rewrite from scratch, we would not accept the project as completed.

We would rather have a maintainable, clean and incomplete piece of code that we could extend than a complete but unmaintainable piece of code.

Applying, suggestions

Remember that many people will apply to work on the Summer of Code and we cannot accept them all.

Keep in mind that those of us evaluating your application do not know you, we do not know what kind of experience you have, we do not know what you have done in the past, and we have to pick the best people suited for a particular task.

Hence, it is very important that you tell us in your application why you should be considered to implement a particular project. From the hundreds of requests that we got last year, in the first few hours we discarded all of the one-line requests that read something like:

I would like to work on project XYZ

Do not cut-and-paste the text from this page in your application. We know full well what the text here is. Instead explain to us your take on the problem "I could implement this using this and that", "I would need to research these areas", "I might need help sorting this out", etc.

We especially want to see:

• A concrete list of goals/deliverables for the time period.
• A rough estimate of the steps it will take to complete your project.
• A timeline showing how long you believe each step will take.
• Multiple people may apply for the same project, tell us why you are the best candidate.

During the summer of code, we will invest significant resources from existing team members to guide you, answer your questions, and help you architect the software in a way that is acceptable to Mono and that has a high chance of having an impact on the larger community of Mono users.

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 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.

Runtime

Improve and extend the logging profiler GUI

Extend the current logging profiler GUI to support all of it's operation mode and provide good visual feedback and exploration capabilities to the results.

This should be a Gtk# or Web-based application that consumes the profiler data and implements a UI for common profiler-based operations.

Priority: High.

Deliverable: An improved profiler GUI to enable better heap and performance evaluation.

Rewrite Remoting to use DynamicMethod

Complexity: Medium-Hard.

The current implementation of Remoting use System.Reflection.Emit to generate classes to optimize some remoting tasks. However the types are not GC'able due to the nature of how TypeBuilder and friends work. The idea is to re-implement this part of the code to use DynamicMethod, which would result in less memory utilization and allow for GC'able data.

Deliverable: Patches re-implementing the related parts of Remoting.

Mono.Simd ports

Complexity: Medium-Hard

Port the Mono.Simd API to any of the following architectures:

• AMD64
• VMX
• NEON

The VMX and NEON ports should be pretty straight forward as the whole machinery is there. It's a matter of adding the proper instruction intrinsics.

Add support for X86 to use SSE for FP math

Complexity: Medium-Hard

Add the required machinery to make mono emit SSE code for FP math. It should be dynamically detected, should play nicely with Mono.Simd and not preclude optimizations that are disabled under stack based FP.

Use Mono.Simd in the classlibs

Implement encrpyption, hashing and big num functionality in the class libraries.

Complexity: Medium-Hard

Deliverables:

-SHA1 -BigInteger basic ops -More stuff TBD

Improve and optimize ParallelFX

Complexity: Medium-Hard

Improve the ParallelFX library.

Build a test suite to assert it's performance and scalability up to 8 cores machines. Optimize as needed.

Add COM support for other COM runtimes

Complexity: Medium. Priority: Medium.

Currently Mono has support for Mainsoft's COM and Mozilla XPCOM, we would like to add support for OpenOffice's UNO to bridge their APIs using the native COM support in Mono.

See Three Com Interop Updates (http://jonathanchambers.blogspot.com/2007/02/three-com-interop-updates.html), COM Interop in SVN (http://jonathanchambers.blogspot.com/2006/07/com-interop-in-svn.html), COM Interop in Mono Progress (http://jonathanchambers.blogspot.com/2005/11/com-interop-in-mono-progress.html) and COM Interop in Mono (http://jonathanchambers.blogspot.com/2005/11/com-interop-in-mono-part-1.html) blog posts for more details.

Deliverable: Code that enables support for OpenOffice's UNO with an example program that connects to OO and performs some small task.

Applications

We are looking for improvements to the existing Gnome/Mono applications like F-Spot, Banshee, Gnome-Do, Tasque, Tomboy, Beagle and others.

Axiom Engine

The Axiom 3D Engine (http://axiomengine.sourceforge.net) is an open-source, cross-platform 3D graphics rendering engine for .NET and Mono. The engine is a high-performance C# port of the powerful OGRE engine.

Some ideas can be found on the Axiom wiki (http://axiomengine.sourceforge.net/wiki/index.php/HelpRequested). We're interested in things that will make it easier to write cross-platform games and 3D applications using Mono.

Mentors: please add new ideas and applications.

Students: feel free to suggest ideas and projects for the summer from those alternative web sites.

Moonlight/Silverlight related projects

Many of these projects are intended to help us create software that we can use to test drive our implementation, find problems with Moonlight, our SDK and the development process.

The software will live on its own, but expect to find challenges with our implementation.

PixelShader pipeline

Silverlight 3 introduces support for Pixel shaders (implementing the ps2.0 API). These shaders are not executed on the gpu, but are actually run thru a JIT and executed by the CLR. This project will implement a HLSL PS2.0 compatible parser that emits the pixel shaders as dynamic methods.

VDPAU VC-1/H.264 Support

The new NVidia VDPAU API supports decoding VC-1 and H.264 in hardware. Implement support for determining at runtime if a card is capable of leveraging this api, and offload the decoding to the GPU.

NOTE: A G98 nvidia card is required to implement the vc-1 decoder and will need to be provided by the student.

Silverlight 3 Demuxers

Implement demuxers into the Moonlight pipeline compatible with the new Silverlight 3 beta support for .mov, .f4v, .m4a and .mp4

Silverlight GUI Designer

Two summers ago Alan McGovern (of MonoTorrent fame) worked on LunarEclipse, an GUI editor for Siverlight XAML files. This editor was being built as Moonlight was being developed, so it was a great test for Moonlight and exposed many bugs and limitations on it.

This year, Moonlight is more mature and we would like to have this GUI designer completed, first in standalone mode.

Deliverables:

• Complete the editing features available for figures.
• Complete the recording and animation framework.
• Add support for loading and saving files.

Silverlight/Web-based "Garage-Band"-like application

Using Silverlight 2.0 build the UI for a Garage-Band like application (sequencing of instruments, showing audio, beats, select ranges, cut and paste) that would be fully implemented with Silverlight and Moonlight.

Important: Do not worry about actual music output for this project, we are only interested in the UI. The actual media hookup would take place later (and would likely require server-side provided on-demand audio generation).

Silverlight/Web-based video editing sofwtare

Using Silverlight 2.0 build the UI for video editing software (import clips, select regions, cut regions, combine regions, mix regions, do transitions, effects).

Deliverables:, assuming that all audio and video sources are available on the server (ie, do not worry about the actual storage and web presence, that will be sorted out independently):

• Preview area for the video
• Timeline editor
  • Cut, paste, slice, transitions.
• List of resources
• Show a timeline for the various clips

Silverlight/Moonlight Web-based: Suggest Your Own

Remember that all the Silverlight apps can be ran locally on the Linux desktop: what would be a great application that we could run unmodified on the web and on the client?

Platform Abstraction layer

Abstract the Moonlight engine away from having hard dependencies on Gtk+/Gdk/Glib and build a platform abstraction layer that will facilitate easy porting to other platforms like Windows and Mac. The successful completion of this project would include a reference implementation for 1 other platform.

Dirac Support

Silverlight 3 supports a pluggable media backend allowing developers to write new codecs in C#.

Develop the Dirac video decoding framework for Moonlight 3/Silverlight 3

Vorbis/Theora Support

Silverlight 3 supports a pluggable media backend allowing developers to write new codecs in C#.

Develop the Theora/Vorbis video decoding framework for Moonlight 3/Silverlight 3.

Ogg Container Support

Silverlight 3 supports a pluggable media backend allowing developers to write new demuxers for media formats in C#

Develop the OGG container format Moonlight 3/Silverligh 3.

Hosting Mono

The Mono runtime could be hosted into several open-source applications (e.g. extensibility, scriptability). Each one would be a different challenge with varying complexity levels. Got other hosting ideas/projects ? Let us know!

Inkscape

Create bindings to Inkscape so that Mono can be used to script Inkscape with any of the .NET provided programming languages.

Deliverables: Bindings that expose the Inkscape API to C# code as well as code to host the Mono runtime inside Inkscape.

Database Server

Develop a database server plugin to execute C# (or any .NET language) stored procedures. Mono can either be hosted inside the database engine or out-of-process.

Notes

• An open-source database server would be more useful than a proprietary one ;-)
• Like hosting Mono inside FireFox the security implications of managed storedproc limits the usefulness of this tool until our security manager is completed. However it is still useful for fully trusted code and will provide an excellent test environment for a secure Mono runtime.

Deliverable: A plugin that can execute basic C# statements as a stored procedure with examples.

ClickOnce

A ClickOnce (http://msdn.microsoft.com/msdnmag/issues/04/05/ClickOnce/) implementation could be done using either a managed or unmanaged host (e.g. Firefox). Besides a host this would require adding the missing pieces in the Mono class library (e.g. manifest support).

Since CAS is not supported in Mono its usefulness would be somewhat limited. However a basic use case, from an enterprise point of view, is to distribute/update applications on an intranet. In this case having only NoTrust (no execution) and FullTrust (execution) is a valid and interesting scenario.

Ideally the NoTrust/FullTrust decision would be based on host security policies (e.g. strongnames, url, ...) or by custom host logic.

Deliverable: A host environment and necessary Mono pieces to enable clicking on a link in a browser which will download, install, and run Mono applications.

MonoDevelop

MonoDevelop (http://monodevelop.com) is Mono's integrated development environment, and aims to provide all of the RAD features that users expect in a modern IDE. Its architecture is highly flexible, so new features can easily be implemented in an "add-in". Students would be expected to write a new add-in or complete an existing, unmaintained addin.

Note that it would be acceptable to combine several smaller projects into one proposal. Additional information on MonoDevelop's development can be found on the MonoDevelop website (http://monodevelop.com/Developers), with some more feature ideas.

If you are interested in discussing these projects, please contact the MonoDevelop mailing list or IRC channel (http://monodevelop.com/Help_%26_Contact). In IRC, ask for mhutch or lluis.

Misc

Class Designer Addin

Provide a class designer canvas based on Moonlight that allows users to visualise their class hierarchy via MD's built in code DOM, and stub out new code automagically. Should allow performing operations already made possible by MD's refactory tools such as adding and renaming members. Bonus points if it can load class designer files from VS2005+. N.B. #develop has some related code already.

Deliverables: A class designer canvas that can be used to view and make simple edits on the MonoDevelop project's classes.

Online Project/File Templates

This would consist of a simple web service for project/file templates, and integrating use of this service into the new file/project dialog. This would require a substantial rewrite of the new file dialog.

Deliverables: Implement a simple web service for serving templates. Rework the New File / New Project dialogs to improve their usability and add support for online templates. May have to include other tasks to make this a full-size project.

Interactive C#/F#/IronPython Console

Implement a console pad for embedding interactive shells, e.g C#, IronPython, IronRuby, F# etc. Such a pad exists for Boo already. Should have syntax highlighting and hooks for code completion. Might be useful for scripting MonoDevelop itself too.

Deliverables: Develop an abstract console pad infrastructure based on Mono.TextEditor, including support for running in a remote process, and code completion hooks. Implement a language addin for at least one .NET language, ideally C#. Might also include code completion support.

Bug tracker integration

Integration with an online bug tracker, ideally an abstract framework with a plugin for bugzilla.

Deliverables: Design and develop a framework for integrating with online bugtrackers: browsing bug lists, changing bug assignments and states, linking bugs from source code and from VCS messages. Should include Bugzilla support.

Documentation Addin

Integrate the MonoDoc documentation system into MonoDevelop to make it easy to generate and update documentation for a project. The main feature would be a contextual pad that allows editing MonoDoc documentation. It should use the MonoDevelop parser services to determine the current position in the editor, and show the documentation for that class/method/property etc. Possible extensions to this addin would include displaying the documentation inline in the text editor, allowing "refactoring" of documentation from XML comments into the MonoDoc system, and autocompletion of references within the documentation editor.

Deliverables: Develop an addin for addin MonoDoc support to a project, including compilation of the documentation, and some form of contextual viewing and editing of the docs.

Debugger Visualizers

Implement debugger visualizers for all common BCL and GTK data types, so that when viewing values in the debugger, common types can be displayed in a more readable format. For example, an IDictionary would be shown as a list of key-value pairs, maybe searchable; a GDK.Pixbuf would be rendered as a preview; and Gdk.Color would be shown as a color swatch.

Deliverables: Add debugger visualize support to the debugger addin. Proposal should include a list of data types for which visualizers will be added; you must design and implement visualizers for them.

Translation Resources Editor

An editor for Translation resources, particularly useful for ASP.NET where there is no (easy) Gettext availability.

Deliverables: Full support for translation resources for ASP.NET. Should extend or share code with the Gettext addin.

Profiling addin

Bring the profiling addin to a state where we can ship it. Add support for the mono logging profiler, and support statistical profiling as well as memory profiling. Possibly add support for live updating, and unmanaged profilers such as valgrind.

Deliverables: Logging profiler support for the profiling addin, including allocation and statistical profiling.

Database Addin

Database Designer

Implement a database designer canvas using Moonlight that can be used to visualise and modify the table structures and relationships in a database. This could share code with the class designer.

Deliverables: A database designer canvas that can be used to view and modify database tabs and their relations.

Database integration

Integrate the database addin with other parts of MonoDevelop. This could possibly include the GTK# data widgets in Stetic, the databound controls in ASP.NET, or persistence layers such as DBLinq and NHibernate.

Deliverables: Databinding extension points and services in the database addin, and and addin that provides these features for the ASP.NET addin or the GTK# designer.

Language Bindings

Language binding extensions integrate support for programming languages: compilation, code completion, etc. We are primarily interested in bindings for languages with an open-source implementation that can target Mono, but the architecture of MonoDevelop does not preclude other languages.

Implement a new Language Binding

Implement a language binding for a language currently unsupported by MonoDevelop. It should include complete code parsing and simple code completion, and possibly refactoring operations.

Possible languages include F#, IronPython, IronRuby and LuaCLR.

Deliverables: A new language binding, with full parsing support and code completion.

Improve C/C++ Binding

Implement a mini parser and local type resolver in order to provide code completion for instance members and contextual code completion. Make the code completion more "eager". Refactor out the ctags layer so that it can be used to provide basic completion for other ctags-supported languages. Add features to facilitate managed bindings, such as DllImport completion and SWIG integration. Consider implementing some refactoring tools.

Deliverables: Negotiable, but should include a new parser, and reasonably accurate member completion.

Improve VB.NET Binding

Finish the VB.NET bindings for MonoDevelop. Improve the code completion "eagerness". Implement the basic refactoring operations so that it can be used with Stetic and the ASP.NET codebehind. Implement automatic code insertion (insert 'End If' after 'If', etc).

Deliverables: Restore code parsing and code completion support to the VB.NET binding. Add refactoring operations necessary for the GTK# designer to work. Implement some advanced completions, e.g. override completion.

Improve Boo Binding

The Boo (http://boo.codehaus.org) Binding is in a similar state to the VB.NET binding, so similar tasks would apply.

Deliverables: Restore code parsing and code completion support to the Boo binding. Add refactoring operations necessary for the GTK# designer to work. Implement some advanced completions, e.g. override completion.

Java/IKVM Binding

Implement a parser for the IKVM Java binding to provide code completion. Further work is possible, as for VB.NET binding.

Deliverables: Add code parsing and simple code completion support to the Java/IKVM binding.

Moonlight/Silverlight

Complete Moonlight project Support

Complete the Moonlight project support in MonoDevelop, completing xap compilation and run support. Implement full XAML code completion, and add an embedded Moonlight widget to show a live preview of the XAML in a code/preview split. Allowing use of the property grid to edit XAML controls in the text editor would be nice.

Deliverables: Complete XAML code completion. Live Moonlight preview alongside text editing. Complete Moonlight build/run support, including xbuild tasks.

Designer Integration

Integrate the Lunar Eclipse moonlight designer as an alternative editor for XAML files.

Deliverables: Integrate the Lunar Eclipse designer as an alternate editor for xaml files, including toolbox, document outline and property grid integration.

Web Tools

Webkit-based HTML editor

An HTML editor based on GTK WebKit. The key feature of this editor should be to synchronise edited changes to and from the text editor in real time, allowing a designer/code split view. It should also include support for "regions" of uneditable code that can be rendered and updated by the ASP.NET addin. The will require close mentoring by mhutch to make sure it can be used to replace Composer for the ASP.NET editor.

Deliverables: WebKit-Gtk-based HTML editor widget, based on synchronization to/from a text editor, with support for non-editable regions.

CSS Support

This would involve implementing CSS code completion, both for standalone JS files, and for JS in HTML and ASPX files. Some code already exists for this, from a failed GSoC project last year. This should be quite easy, so there would be potential to investigate more interesting and advanced features such as support for browser profiles, checking for common errors, pads for interactive editing of styles.

Deliverables: CSS code completion in standalone files and inline in HTML/ASPX files. Interface for managing CSS classes. CSS browser profiles.

JS Support

This would involve implementing JavaScript code completion, both for standalone JS files, and for JS in HTML and ASPX files. It should be capable of handling common JS frameworks such as JQuery.

FlashDevelop has an ActionScript parser that could perhaps be adapted.

Deliverables: JavaScript code completion in standalone files and inline in HTML/ASPX files.

HTML Validation

Live validation of HTML (and possibly CSS and Javascript) against the different feature sets supported by different browsers.

Deliverables: An addin that validates HTML, CSS and JavaScript against the features known to exist in different browsers. Browser profile support.

Code analysis

Gendarme Addin

Take over the Gendarme addin (it will need to be mostly rewrittten) and improve its usability and feature set.

Deliverables: Completed gendarme addin. Support for selecting rulesets, excluding rules, exceptions, viewing list of violations and possible solutions. Templates for gendarme rules.

Code metrics

The code metrics addin could also be improved, adding more complex metrics such as documention coverage, tests coverage, classes per file, methods per class, LOC per method etc.

Deliverables: Develop a framework for code metrics, and a number of code metrics for C#. Details negotiable.

On-the-fly analysis

On-the-fly code analysis, searching for common coding problems. Will require infrastructure for post-processing parse units.

Deliverables: A framework for on-the-fly code analysis, detecting and suggesting solutions for common problems.

Version control addins

The version control integration in MonoDevelop can be extended to support new version control systems via providers. Since the only completed provider is the Subversion provider, it is unknown whether the provider extension point is flexible enough to support all other version control systems; some patches to the core version control addin may be required.

Implement a new Version Control Provider

MonoDevelop has a version control addin into which providers for VCS systems can be plugged. Currently there's only a SVN provider. We'd like more.

Deliverables: A version control provider for any popular open-source VCS, such as GIT.

Visualisation tools

In order to fully support distributed development, MonoDevelop needs tools to perform visual merging of changes (ideally three-way merge) and visualising branch and file history. Although most useful with distributed VCS, these will be useful with Subversion too.

Deliverables: A graphical three-way merge tool for the VCS system, and support for this in the SVN provider.

Compilers

VB.Net 9

The current VB.Net compiler, vbnc, fully implements VB.Net 8. We would like to extend it to implement VB.Net 9. This may be too much for one summer, so your application should list which parts you plan on implementing.

Deliverable: Code and tests for vbnc which implement the proposed VB 9 features.

Class Libraries and Bindings

GIT# implementation

Importance: High

A fully managed implementation of the GIT framework, this would be a class library that would implement the GIT file format and operations in C#, including its test suite.

This could be a port of the EGit Java implementation to C# or assisting any of the current GIT efforts for .NET hosted on github.

It should be possible to implement command-line equivalents to the GIT command line tools on Unix using the library.

There are various benefits in this project:

• It would allow tools like MonoDevelop to integrate GIT support natively.
• Bring GIT support to Windows easily
• Allow for the creation of new tools that use GIT storage as their backend.

Deliverable: A managed library that implements GIT functionality with unit tests.

Windows.Forms VisualStyles Support

Currently, Mono only supports the VisualStyles namespace on Windows. We would like to support this on Linux (Gtk) and Mac (Cocoa) as well. This can be done in one of three ways:

• P/Invoke the necessary Gtk and Cocoa libraries, allowing them to draw on the given graphics surface.
• Write your own managed rendering code that mimics Clearlooks or Aqua.
• Adapt Wine's (http://www.winehq.org/) uxtheme.dll code to run under Mono. (This would be able to run any VisualStyles theme, including many existing ones that mimic Clearlooks and Aqua.)

Deliverable: A complete implementation of the VisualStyles namespace for either Linux/Gtk or Mac/Cocoa.

GTK#

GTK# Applications

We are extremely proud to have some exciting and innovative Mono/GTK# based applications, like F-Spot (http://f-spot.org/Main_Page), Tomboy (http://www.gnome.org/projects/tomboy/), and Banshee (http://banshee-project.org/Main_Page). We are interested in expanding this to include the next generation of Gnome apps. If you have an idea for a new, innovative application, please feel free to write a proposal for it. Note we are not interested in "I would like to rewrite application XYZ in Mono". We want fresh, new applications that provide value to the Linux desktop.

Deliverable: A GTK# application that contains the features specified in the proposal.

Summer of Profiling

The new 2.0 profile support in Mono is larger than 1.0 and also includes many new code paths that might affect regular applications running by using more memory that they should.

Since performance of managed applications is deeply tied to memory allocation, reducing memory allocation in Mono applications will lead to performance increase.

The Summer of Profiling would be a project to identify, tune, patch and improve the memory usage of Mono applications in every aspect: ASP.NET, web services, XML handling, core libraries, Gtk#.

Deliverable: Patches to reduce Mono's memory usage.

Tools

Gendarme related projects

Mono has a tool, Gendarme to inspect .NET software to detect potential problems within them. It is similar, in goal, to the FxCop tool available to Windows developers.

Gendarme is composed of a runner (a command-line tool) that execute a set of rules over binary assemblies. The rules are written in C#, or possibly any .NET language, by using Cecil, a managed API to manipulate an assembly IL and metadata.

Questions ? See us on IRC, #gendarme channel on GIMPNet, or drop us a mail on our Google Group (http://groups.google.com/group/gendarme).

Here are some potential projects related to Gendarme. We expect you to develop them further in your proposals.

Apply Gendarme to Mono

This project goal is to enhance Gendarme to be even more useful to Mono itself.

This project includes:

• Creating, or tweaking existing, rule sets (profiles) for
  • stable assemblies, where API cannot be changed
  • unstable assemblies, where the API can be changed
  • non-core assemblies, those the Mono project doesn't directly support
  • tools, all managed tools provided with mono

• Create a special runner to ease the execution and reporting over Mono different profiles.
  • NET_1_1, NET_2_0, Silverlight ... assemblies and tools

• Wrap some rules for Mono usage.
  • E.g. a lot of Gendarme's rules cannot be used because they would turn out valid issues that cannot be solved and retain compatibility with MS .NET framework (e.g. naming rules). However some rules would still be useful for private and internal classes/methods.

• Analyze Gendarme results to find:
  • False positives. Create new unit tests for them and either fix the rules or fill bugs for them.
  • Bugs on class libraries (and tools). File bugs for real problems (which can include patches) or add ignore entries for unsolvable issues (e.g. compatibility)

• Propose changes (framework and/or rules) to Gendarme to make it more useful to Mono

Apply Gendarme to FOSS projects

This project's goal is similar to the previous one but with a different target(s). Here the idea is to enhance Gendarme by helping other FOSS projects that run on top of Mono, e.g. MonoDevelop (http://www.monodevelop.org/), Tomboy (http://www.gnome.org/projects/tomboy/), Banshee (http://www.banshee-project.org), F-Spot (http://f-spot.org/Main_Page), Gnome-DO (http://do.davebsd.com/), Beagle (http://beagle-project.org), NUnit (http://www.nunit.org/) ... The number of FOSS projects to be analyzed depend on their size and support. Since the latter may vary during the project (e.g. vacations) it could be possible to add more project(s) during the summer.

This project includes:

• Contacting the project maintainers to see
  • their interest (and free time) in fixing the reported issues. Ideally this should be done before sending us the proposal!
  • if binary compatibility is an issue, since this will influence the number of rules that can be used

• For each project you must
  • Create scripts that contain:
    • the set of rules used on the projects (actually it should be all of them - minus some specific ones)
    • the list of assemblies to be evaluated
  • File (or fix) bugs for
    • Gendarme, e.g. in case of false positives
    • the selected FOSS projects
  • Produce a small report (in the form of a special blog entry) with statistics
    • size of the project
    • how many problems were found (e.g. per category, per rule)
    • how many problems were false-positives
    • how many problems could be / could not be fixed
    • ...

• Propose changes (framework and/or rules) to Gendarme to make it more useful to FOSS projects

Statistics & Performance Analysis

As Gendarme gains more rules performance will become an important concern. Gendarme's default rule set must be kept fast enough so that using it regularly, or as part of the build process, doesn't become an issue.

Part I: Statistics

This includes enhancements to the Gendarme.Framework to, optionally, keep statistics like:

• the number of times a rule was used, not applicable, successful, failed
• the required time for each case

The results should be added, on demand, to the default console runner to help developers see the impact of their changes.

Part II: Performance Profiling

This includes using the profilers available with Mono to find where we spend our time (and memory) while executing Gendarme (and potentially Mono.Cecil too). This should enable to create/refine the developer FAQ by documenting good practice for rules development.

Part III: Optimization

This last part includes changes (proposals and, if accepted, some implementation) to Gendarme (runners, framework and/or rules) to optimize the current time/memory requirements. It's also possible to propose (or write) some rules to check rules :)

Write some cool rules

For this project your proposal must include a list of a few, moderately complex(*), rules for Gendarme. Writing rules is a great way to learn C#, IL and the metadata internals by using the Cecil managed library.

To be considered complete each rule must:

• include its source code;
• include unit tests to ensure the rules works correctly, i.e. to confirm both positive and negative findings;
• include documentation for the wiki, e.g. [Gendarme.Rules.Design];
• be reviewed (to ensure it's been tested against the Mono class library and doesn't return too many false positives);

(*) there are a lot of small and simple rules still missing from Gendarme (requiring less than 5 days of work). However they are not candidates for GSoC projects since they offer a great introduction to new contributors, a way to relax (and try new stuff) for existing contributors (when short on time) and are very popular for GHOP tasks.

Additional sources of information:

• Existing rules (http://www.mono-project.com/Gendarme#Rules)
• The FindBugs (http://findbugs.sourceforge.net/bugDescriptions.html) software for Java
• .NET Framework Guidelines (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconNETFrameworkDesignGuidelines.asp)

ILASM

Convert the ILASM backend to to use Cecil (http://www.mono-project.com/Cecil) as its backend instead of PEAPI (this is only a backend change, not a rewrite of ILASM).

Deliverable: A version of ILASM that uses Cecil.

Monodoc

• Write PDF export support for documentation.
• Multi-threaded file generation support
  • Use multiple threads to update the .xml files, using one thread per .xml file.
    • Most .xml file generation/updating shouldn't depend upon multiple resources, so this should be a net performance gain.
• Migrate to use System.Xml.Linq from System.Xml (to decrease memory requirements, and perhaps to use PLinq for the parallel updates).
• Create an on-demand member generation API.
  • Mike Kestner wants to change the XML format so that the XML only stores documented members, not all members, and the undocumented members would be generated at mdoc-assemble.
  • This would be to better support a decent documentation editor, minimize the amount of XML "churn" when committing updates to XML, minimize the amount of changes that need to be reviewed during svn commits, etc.
• Fix Monodoc.Node.URL so that it's sane
  • MonoDevelop uses Monodoc "out of process" to show documentation. (See monodoc -remote-mode for details.)
  • This "out of process" mode reads stdin to determine which nodes to show.
  • Node names are formed by Monodoc.Node.URL
  • Monodoc.Node.URL is currently of the form ecma:51#Console/
  • Problem: this format is unique to the currently executing Monodoc. Thus, that "url" may be valid for http://go-mono.com/docs, but it won't be valid the next time go-mono.com is restarted.
  • Similarly, on the local desktop it uses the same format, but the numbers/etc. will vary, e.g. if you install additional documentation.
  • The result: in some circumstances, MonoDevelop tries to navigate to a particular URL, but gets either the wrong documentation no documentation, becaues the monodoc library within MonoDevelop has a different set of URLs than the Monodoc in the external processs.
  • Oops.
  • Solution: come up with a sane, consistent, Monodoc.Node.URL mechanism.
    • Preferred solution: use the cref format, so in stead of ecma:51#Console/ for System.Console documentation, it should be T:System.Console.
    • This is preferred because monodoc already has support to parse cref formats to perform documentation lookup.
• Write a decent documentation editor.
  • Random thought: integrate the new documentation editor with MonoDevelop, and alter the editor so that when viewing C# source you see "normal" XML documentation comments, but those documentation comments are not saved within the .cs file. Instead, they're kept separate in the normal .xml file, and the .cs and .xml files are "merged" within the MonoDevelop editor.
  • Requirements:
    • Must support "bulk copying" of documentation between members. For overloaded members particularly, lots of the documentation will be similar or identical (the summary text, parameter text, etc.). The problem with current monodoc --edit is that there's no easy way to copy and paste identical text between different members, so (for me) it's far faster and more efficient to edit documentation within vim or MonoDevelop.
    • Must support adding additional sections. The XML format supports many elements such as exceptions, permission, remarks, etc., none of which monodoc --edit allows to be created.
    • WYSIWIG editing, especially for lists and tables.
    • "Code completion" style support for cref tags, to cut down on mis-typing e.g. Systme.Collections.Generic.List{T} (as I often mis-spell System).

Extend daap-sharp to d[amp]ap-sharp, integrate it with f-spot for photo sharing

Complexity: Medium Priority: Medium

DPAP is the protocol used by iPhoto for sharing images, similar to DAAP for sharing audio between iTunes and other music app (banshee, rhythmbox, ...). Right now banshee consume the daap-sharp bindings, and this bindings should be extended to support dpap too (both daap and dpap are based on dmap). F-Spot should use this new library to 1)browse remote dpap shares from the --view mode and 2)expose it's collection via dpap.

Deliverables: a working managed dpap library and a set of patches to showcase it's usage in f-spot (exposing f-spot db, browsing shared items)