Google Summer of Code 2011
Google Summer of Code 2011
For more information about the program see http://code.google.com/soc/
SharpDevelop is an open source IDE for C#, VB.NET and other languages on the .NET platform. It is typically used as an alternative to Microsoft's Visual Studio .NET. It includes features like a forms designer, code completion, code generation, integrated debugger, refactoring support, SVN integration, code conversion between C# and VB.NET, integrated support for testing and many other features. The project is as old as the .NET platform itself - it started in the year 2000 and it has been actively developed ever since. SharpDevelop is translated by the community to over 18 languages and it is downloaded 2000 times each day.
For more information see the homepage: http://www.icsharpcode.net/OpenSource/SD/
The SharpDevelop team has also recently created ILSpy which is an open-source .NET assembly browser and decompiler. The development started after Red Gate announced that the free version of .NET Reflector would cease to exist by end of February 2011.
ILSpy includes a C# decompiler which is already producing very good code and has support for some advanced features such as lambdas and 'yield return'. See the full list of features.
Every year, we meet in Bad Ischl, Austria for a few days. This is a great way to get to know the members of the team, meet the other students and of course to write some code. The participation in completely voluntary, however, if you are within a travelling distance, you are strongly encouraged to come. We have all enjoyed the event in the past.
You need to submit your application before the 8th April 2011. The application can be submitted via Google after 28th March 2011. Do not send the applications directly to us. You can can find the template of the application here.
If you want to discuss your idea with us or if you just want to introduce yourself and say hi, please feel free to contact us (preferably sooner rather than later). You reach us via email ([[[email protected]]]), the public forum (http://community.sharpdevelop.net/forums/) or IRC (irc://irc.freenode.org/#sharpdevelop). If you have any specific questions, please feel free to contact the mentors directly.
Please try to submit your application early even if the application still is not polished - just mention that you are still working on it. You can still edit the application after you submit it. This way, we might be able to give you some early feedback, but most importantly, you will have the application submitted. It is very easy for something to go wrong just before the deadline (eg. overloaded server or you can just get the time wrong) and the online system is very strict - if you are even just one minute late, it will not let you submit it.
We suggest that you start coding even before the application deadline. Some preliminary code allows us to see that you can understand and extend the SharpDevelop source code. It also show us that you are motivated and can write good C# code. Last year we had only 4 slots for 30 applicants so demonstrating you capabilities can really help you. Start by downloading ShaprDevelop from GitHub (see AccessingTheRepository) then study the parts of code related to your project. You can try to either write a quick prototype of your project or you can add some small feature.
Note that you can submit multiple applications. We strongly suggest that you focus on one application and try to make it as good as possible. However, you can also submit other application(s) for project(s) that you like as well. That would come handy if two really good students happen to apply for the same project. In that case we could still accept both of you and let one of you work on the backup project.
See this page for some advice: http://code.google.com/p/google-summer-of-code/wiki/AdviceforStudents
You can find the list of projects that you can work on bellow. This list is by no means exhaustive or fixed. Feel free to modify the ideas to your liking or come up with your own idea. The project are grouped into categories depending on how important we consider them. Don't feel pressured to work to the high-priority ones - you might have less competition for the other projects. Ultimately, the most important thing is that you convince us that you are capable and motivated student.
You will have to write the code in C# and you should base it on the current head (SharpDevelop 4.0). See AccessingTheRepository.
You are expected to be already familiar with the .NET and C#. You might also need to familiar with technologies related to the project you want to work on. Familiarity with SharpDevelop and the SharpDevelop source code is advantage but not necessary. All new GUI should be written in WPF.
| David Srbecky | Email/MSN/XMPP: dsrbecky(at)gmail.com |
| Skype: dsrbecky | |
| ICQ: 153888796 | |
| Daniel Grunwald | Email: daniel(at)danielgrunwald.de |
| Matt Ward | Email: mrward(at)users.sourceforge.net |
| Bernhard Spuida | Email: bernhard.spuida(at)gmail.com |
{BR}
| **Difficulty:** | Medium-Hard |
| **Required skills:** | WPF, Xaml |
| **Mentor:** | Daniel Grunwald |
The WPF designer architecture was originally written in 2007, when System.Xaml was not available. The project would be to rewrite the designer's backend storage to use System.Xaml. This should improve the designer's compatibility with XAML, as there are some constructs which the designer does not handle yet.
Furthermore changes in the designer should be immediately visible in the XAML source code (think side-by-side view, as in Visual Studio). Similarly, changes in the XAML source code should be immediately visible in the designer (that is, faster than reloading the whole XAML file). We have some ideas about how to do this. In particular, we have a our own custom XML parsing library that can notify you when parts of the XAML file are changed. (but this is for you only if you're interested in implementing a difficult feature)
In addition to these backend changes, SharpDevelop's WPF Designer AddIn should be changed to run in a separate AppDomain. This would allow us to load (and later unload) custom controls in user-defined assemblies.
Lastly, there are still many UI improvements and missing features in the WPF designer. You could include some of them in your proposal as well, if you think you have enough time free (probably only if you don't do the side-by-side view)
Difficulty varies based on which features you plan to implement. We expect your GSoC application to contain a detailed list of the features you want to implement. You could just try the existing WPF designer to see what's missing. Then, please discuss your feature list with us before submitting your application!
{BR}
| **Difficulty:** | Medium |
| **Required skills:** | WPF, Reflection-API, (Interprocess communication) |
| **Mentor:** | David Srbecky |
Create some interesting and useful debugger visualizer. It is up to you to come up with some ideas. You can create one complex visualizer or several simple ones.
The visualizers should be written in WPF.
Porting of some open-source Visual Studio visualizers might also be an option. In particular, we are interested in porting Mole to SharpDevelop. This would qualify as "one complex visualizer". Note that you do not have to replicate Mole; you should take Mole's source and use it as a starting point. Mole is written in VB.NET, but we can use SharpDevelop's converter to translate it to C#. Mole is using the Visual Studio's visualizer API - you should get familiar the API since the first task will be to reimplement it in SharpDevelop. Do not worry, as far as interprocess communication goes, this API is very simple. Once this works you can either create other visualizers or you can improve Mole - you can take some inspiration from the commercial Mole 2010.
In any case, it is good idea to take a look at the Mole article to see how visualizers work. Also, make sure to read the blog post which is explaining the basics of the SharpDevelop debugger.
Links and References: {BR}
- Mole for WPF visualizer - http://www.codeproject.com/KB/WPF/MoleForWPF.aspx
- Basics of the SharpDevelop debugger- http://community.sharpdevelop.net/blogs/dsrbecky/archive/2010/07/29/debugger.aspx
{BR}
| **Difficulty:** | Easy |
| **Required skills:** | WPF, knowledge of Task Parallel Library (System.Threading.Tasks) |
| **Mentor:** | Matt Ward or Daniel Grunwald |
The old SearchAndReplace AddIn has several deficiences:
- It requires running on the main thread
- It has several known issues/bugs
- It is hard to maintain (lots of code duplication)
The goal of this GSoC project is to create a new search engine that is thread-safe and allows searching (potentially in parallel) while SharpDevelop stays interactive. It should use a more suitable abstraction of the data source so that 'search in selection' does not need code duplication. The search results pad should apply syntax highlighting to all results (not just those in open files).
As the search engine alone likely won't take the whole summer; as a second step, the search UI could be improved. For example, simple searching within the current document could be done using a Firefox-style search bar (this could replace the existing incremental search).
{BR}
| **Difficulty:** | Easy |
| **Required skills:** | WPF, knowledge of .csproj format (MSBuild) |
| **Mentor:** | Daniel Grunwald |
Port the project browser to WPF using ICSharpCode.SharpTreeView. The main goal is to enable multiple selection; and to increase the extensibility of the project browser by SharpDevelop AddIns. Supporting multiple selection will require that a lot of the copy/paste and drag'n'drop code in the project browser is changed. This also is an opportunity to remove code duplication and make the code more maintainable.
The new project browser should use events (e.g. those in ProjectService, maybe introduce additional events in IProject?) to detect and handle changes to the projects. Other parts of SharpDevelop that are modifying the project should not have to deal with updating the project browser.
{BR}
| **Difficulty:** | Medium |
| **Required skills:** | WPF |
| **Mentor:** | Daniel Grunwald |
ILSpy should be integrated into the SharpDevelop code browsing experience. Go to definition should decompile code; and the user should be able to continue navigating in the decompiled code. Search features such as 'find references' and 'find overrides' should work both on user code and referenced assemblies.
{BR}
{BR}
| **Difficulty:** | Medium to hard |
| **Required skills:** | IL bytecode, Metadata/tokens, Cecil |
| **Mentor:** | David Srbecky |
Edit and Continue is the feature which allows you to change the source code while debugging the program and have the changes applied to the program. Therefore, you do not have stop the application, recompile and try to get into the same state.
In general, the natural approach to Edit and Continue would be to support it in the compiler. Visual Studio has its own private implementation which we, however, can not use. Writing our own C# compiler would be just insane and even modifying the Mono compiler would be non-trivial. Even if we used the Mono compiler, I guess that some users would not be pleased if SharpDevelop used a different compiler than Visual Studio - especially if it missed some features from the most recent version of C#.
Therefore this project proposes to use more general approach - just recompile the whole program, extract the new or modified code from the assembly and apply it to the running program.
The main issue is that the new program might contain new code, have some code deleted and include/miss references to external functions. In other words, all metadata tokens might be potentially renumbered. Therefore we can not just cut the IL code of the modified method and paste it to the running program, we have to remap all tokens so that they match the old ones. Some further tweaks to the IL code might be necessary to make sure it complies with some EnC restrictions.
Fortunately, the most difficult part of the EnC technology - changing of the code running code - is done by the CLR and we can use it. We just pass the new IL code for the method body to the runtime and it will take care of the rest.
As far as the compilation goes - we do not actually have to recompile the whole project, we just have to compile the modified method plus anything it needs to compile properly. We really need just a skeleton of the rest of the code - just the needed type and member definitions without any method bodies. Siegfried has already implemented this - it just needs some further improvements.
Finally, we will have to deal with the fact the new code will have symbols in different pdb file. We will have to tell the runtime where the new instruction pointer goes, which will need some editor support. We will also need some help from the editor to find which methods were modified.
Links and References: {BR}
- Mono Project Page - http://www.mono-project.com/
- Mono Cecil - http://www.mono-project.com/Cecil
{BR}
| **Difficulty:** | Varies |
| **Required skills:** | F#, Knowledge of LL-parsers |
| **Mentor:** | Daniel Grunwald |
There is no code-completion for F# yet, which would be the most important feature for F# (visual designer support is rather low for this language)
{BR}
| **Difficulty:** | Easy-Medium |
| **Required skills:** | Entity Framework |
| **Mentor:** | Matt Ward |
Use T4 from MonoDevelop. T4 is text templating system which is supported in Visual Studio. It is quite similar to the other know templating systems such as MyGeneration and CodeSmith.
The goal of the project would be to implement support for T4 and then write templates for the Entity Framework that will generate SQL code necessary to create a database on the server.
Note that MyGeneration is open-source some parts of it might be useful.
Links and References: {BR}
- T4 description on MSDN - http://msdn.microsoft.com/en-us/library/bb126445.aspx
- More about T4 - http://www.olegsych.com/2007/12/text-template-transformation-toolkit/
- T4 in Mono - http://dan.s.wards.ws/how-to-execute-t4-text-templates-in-monodevelop/
{BR}
| **Difficulty:** | Medium-Hard |
| **Required skills:** | CIL, some compiler knowledge |
| **Mentor:** | Daniel Grunwald or David Srbecky |
{BR}
{BR}
| **Difficulty:** | Varies |
| **Required skills:** | - |
| **Mentor:** | Matt Ward |
Includes Debugging support
{BR}
| **Difficulty:** | Hard |
| **Required skills:** | Knowledge in compiler theory; |
| **Mentor:** | - |
Low-priority project. Difficulty varies depending on the level of support of the language. Parsing C++ is extremely hard, you will be required to pick and reuse an existing open-source parser implementation. clang might be an option.
Forum Discussions:
- C++/CLI Support - C++ Support
{BR}
| **Difficulty:** | Hard |
| **Required skills:** | Compiler design |
| IL bytecode | |
| **Mentor:** | David Srbecky |
Low-priority project.
You do not have to worry about the debugger/runtime side of this. What we need is a C# compiler that is able to generate updated IL code, metadata and symbols. Modifying the Mono C# compiler is probably the best way to go.
The scope of this project is limited to just being able to modify a body of a method. For example, adding of a new method is not supported. We are limited by the capabilities of the .NET Framework anyway.
The problem is that the current Mono compiler compiles the source code and then exits (forgets all the intermediate data). If a body of a function is modified, it is not necessary to recompile the whole project. It is only necessary to recompile the function and get the new IL code. However, to do so, the compiler has to remember some of the state - all the already compiled classes and their members.
Links and References: {BR}
- Mono Project Page - http://www.mono-project.com/
- Mono C# compiler - http://www.mono-project.com/CSharp_Compiler
{BR}
| **Difficulty:** | Easy |
| **Required skills:** | - |
| **Mentor:** | Siegfried Pammer |
Allow the user to compare two SDPS files. This involves adding a suitable GUI and implementing different comparison modes (tree comparison, function-based comparison, ...).
Feel free to come up with an idea of your own.
You can also look for additional ideas on the following two pages: {BR} (You might need to expand or trim down an idea to make it suitable as a project) {BR}
You can also find some ideas in the comments of this blog post
In any case, note that you will be expected to work on the project for over two months and you will be paid 5000 USD for it. The project has to be sufficiently large so that you deserve the money - we are unlikely to accept a proposal that we can accomplish ourselfs over the weekend. On the other hand, do not be too ambitious - it much better to do smaller project very well than to promise too much and fail.