This is the Mono Project's project ideas page. For general information and rules about participating in Google Summer of Code (GSoC) (http://code.google.com/soc/) for the Mono Project, please see our overview page.
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:
Table of Contents
2.1 Native support for PDB
2.2 Improve and extend the logging profiler GUI
2.3 Rewrite Remoting to use DynamicMethod
2.4 Mono.Simd ports
2.5 Add support for X86 to use SSE for FP math
2.6 Use Mono.Simd in the classlibs
2.7 Improve and optimize ParallelFX
2.8 Add COM support for other COM runtimes
4.1 VDPAU VC-1/H.264 Support
4.2 Silverlight 3 Demuxers
4.3 Silverlight GUI Designer
4.4 Silverlight/Web-based "Garage-Band"-like application
4.5 Silverlight/Web-based video editing sofwtare
4.6 Silverlight/Moonlight Web-based: Suggest Your Own
4.7 Dirac Support
4.8 Vorbis/Theora Support
4.9 Ogg Container Support
Other Ideas
If a project is not listed here, but you think you have 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.
Runtime
Native support for PDB
Currently we have a tool, pdb2mdb, that converts .Net debugging symbols into Mono debugging symbols. Originally, this required COM support running on Windows. Recently, Microsoft has open-sourced a C# library for reading PDB files (CCI (http://ccimetadata.codeplex.com/)). It would be nice to support these files directly in the Mono runtime.
The debug file parsing infrastructure (http://anonsvn.mono-project.com/viewvc/trunk/mono/mono/metadata/debug-mono-symfile.c) in the runtime is written in C. Therefore, the code needs to be converted to C, and integrated in the Mono runtime.
Alternatively, it might be possible to modify the runtime to use the managed C# version.
Deliverable: A set of patches that integrates a C version of CCI into the Mono runtime.
Improve and extend the logging profiler GUI
Extend the current logging profiler GUI to support all of its operation modes 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:
- 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. This work should include global register allocation of fp values, by reserving a few of the SSE registers and adapting the managed-unmanaged interface to correctly preserve their values.
Use Mono.Simd in the classlibs
Implement encryption, 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
Status: Taken by Jeremie Laval
Improve the ParallelFX library.
Build a test suite to assert its 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 (http://f-spot.org/Main_Page), Banshee (http://www.banshee-project.org), Pinta (http://pinta-project.com/), Gnome Do (http://do.davebsd.com/), Tomboy (http://www.gnome.org/projects/tomboy/), Beagle (http://beagle-project.org) and others. Please contact these projects' communities for project ideas.
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.
F-Spot
Extend DAAP# to DPAP# and integrate it with F-Spot for photo sharing
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 consumes the DAAP# bindings, and these bindings should be extended to support DPAP too (both DAAP and DPAP are based on DMAP). F-Spot should use this new library to browse remote DPAP shares from the view mode and expose its collection via DPAP.
Deliverables: a working managed DPAP library and a set of patches to showcase its usage in F-Spot
Moonlight/Silverlight
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.
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 run locally on the Linux desktop: what would be a great application that we could run unmodified on the web and on the client?
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 many more ideas listed on the tasks page (http://monodevelop.com/Developers/Tasks).
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. You should also create a wizard integrated into MonoDevelop that can convert a project or file into a template and submit it to the web service.
Deliverables: Implement a simple web service for serving templates and a simple website for users to submit templates. Rework the New File / New Project dialogs to add support for online templates. Add a wizard to MonoDevelop for creating templates.
Error and and Statistics Reporting
An opt-in web service for MonoDevelop that would collect error traces and usage statistics from MonoDevelop, and a web UI for browsing the results. Statistical data should include the kinds of machines that MD runs on, typical screen sizes pad layouts, project sizes, while command are executed and whether they're executed from shortcuts, menus or toolbars, and so on. These data will enable us to improve MonoDevelop usability. The web UI should allow registered users to browse the data and to view crash traces. It should merge identical traces and allow linking them to bug reports.
Deliverables: a patch for MonoDevelop to collect usage statistics and crash traces, an ASP.NET web service to collect the data, and an ASP.NET web app to process the data.
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.
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.
Moonlight/Silverlight
Complete Moonlight project Support
Complete the Moonlight project support in MonoDevelop. 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 or Mercurial.
VCS 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.
Class Libraries and Bindings
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 2.0 and 4.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 and Compilers
Code Contracts Verifier
.NET 4 introduces Code Contracts via attributes such as [NotNull]. We would like a contract verifier tool that can analyze a set of assemblies using Mono.Cecil and verify these contracts.
Deliverable: a contract verifier tool that can reliably verify a reasonable set of contracts.
VB.Net 9 Compiler
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.
Port ILASM to Cecil
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.
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
- ...
- Create scripts that contain:
- 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)