This is a mirror of http://laputa.sharpdevelop.net/, the core team's central news blog.
The time to send in proposals for Google Summer Of Code is over now.
Now we're busy reading your proposals and trying to decide on a ranking. This is a
lot more work than I initially expected - we got lots of proposals during the last
three days. Unfortunately, most of the late proposals were of a rather low quality.
In total, we got 44 proposals from 34 students - much more than I expected.
Here's the list of topics proposals were written on. As you can see, most of
them come straight from the ideas
10 proposals on Database tools
5 class diagram / UML related
4 Edit and Continue / C# background compilation
3 C++ support
3 Debugger visualizer
3 Customizable Shortcuts
1 VB 9 code completion
1 Pretty printer
1 XAML code completion
1 Integrated bug tracking
1 actually creative idea
1 idea completely unrelated to SharpDevelop
1 idea I couldn't understand - due to completely broken English and an empty 'Details'
1 proposal that didn't have any idea
But we're looking for students who would like to join the SharpDevelop team; we don't
simply want to get some work done. So it's possible that we'll pick multiple
students from the same 'category'; and having the only proposal on a much required
feature doesn't mean you're automatically accepted.
There also were some Java proposals but I'm not sure where they disappeared to. In
any case, SharpDevelop is a .NET IDE, not a Java one. There are already good open
source Java IDEs available; no need to add Java support to SharpDevelop.
This is our first GSOC and I'm not too sure how we should judge the proposals.
A surprisingly large part of them is obviously disqualified because the proposal is
missing necessary details / the template isn't filled out completely. And what
to do with a student who makes a promising impression but chose a project that isn't
really interesting to us; or looks like it's not enough work for GSOC? What about
projects that look like they cannot be done in the GSOC time frame; but it might be
possible for a good coder and the Bio looks like the student knows what he's doing?
We don't know yet how many slots Google will give to us, so we are as excited
as you are :)
In SharpDevelop 184.108.40.20648, I changed our Subversion integration to use SharpSVN instead
SharpSVN exposes more Subversion APIs to managed code, which could result in some
nice features in the (far) future - for example, "SVN Diff" right inside the
But the main reason for the upgrade was that SharpSVN supports Subversion 1.6. If
you are using TortoiseSVN 1.6, you need to update to SharpDevelop 3.1. The
old SvnDotNet does not work with new working copies.
However, the same is true in the other direction: if you use SharpDevelop
3.1, you must update to TortoiseSVN 1.6. No matter which .NET wrapper or
client version is accessing a repository, the underlying Subversion library has
the unpleasant feature to automatically upgrade working copies. As
soon as the Subversion 1.6 library inside SharpDevelop touches your working copy,
Subversion 1.5 clients will no longer be able to access it.
You need to update all Subversion clients on your machine at
the same time. SharpDevelop contains a Subversion client:
SharpDevelop 3.0 comes with Subversion 1.5 and requires TortoiseSVN 1.5.
SharpDevelop 3.1 (starting with revision 3948) comes with Subversion
1.6 and requires TortoiseSVN 1.6.
in the Subversion FAQ describes the problem and offers a working copy downgrade
script, in case you decide to go back to a previous SVN client version.
David wrote a blog
post on our participation in the GSoC 2009. It refers to the GSoC
2009 Wiki entry where the mentors have posted a few ideas (yes, we actively encourage
students to come up with their own!). As I am the program manager, I am not active
as a mentor, but I sure do have an opinion... here are my top five projects when it
comes to "visibility" (a feature that will be used by a large percentage of our user
The database scout / database api / EDM designer (we already have a student lined
up for this)
Debugger improvements (visualizers, edit and continue support, ...)
VB.NET 9 support on par with our existing C# 3.0 support (most likely a task for a
Refactoring support (think ReSharper)
Customizable keyboard shortcuts / toolbars
I took "Everything .NET 4.0" from my top five because Beta 1 of Framework 4.0 most
likely won't hit the streets before the student application deadline. And I will
post further ideas in David's blog post, so you might find something palatable there
Another major release of SharpDevelop finally hits the streets - version 3.0 has been
completed yesterday and is available for download as of now! Go
On December 5th (revision 3655), we removed the WPF designer from SharpDevelop 3.0.
The decision to remove this feature had its origins in an internal discussion between
Daniel, Ivan and myself after watching the PDC 2008 session Microsoft
.NET Framework: Declarative Programming Using XAML. There, System.Xaml.dll was
announced - a parser for the full Xaml standard.
Back then, a preview was announced for November, but that has been pushed back - please
see the System.XAML
CTP blog post by Rob Relyea. Therefore we had to take the decision whether to
use System.Xaml.dll without doing a prototype, but we opted for saving ourselves the
chore of having to keep abreast with future XAML changes by sticking with a standard
parser instead of having to maintain our own.
Because System.Xaml.dll is part of .NET Framework 4.0, we had to remove the WPF designer
feature from SharpDevelop 3.0.
In version 220.127.116.1160, I changed how NRefactory's TypeReference.Type works.
This is a potentially breaking change to users of NRefactory.
Previously, TypeReference had both a "Type"
and a "SystemType". If you parsed "long
a;", you got a TypeReference with Type="long"
However, this got a little problematic if you wanted to modify the AST - do you have
to change both Type and SystemType?
Actually, setting Type to "int"
was automatically setting SystemType to "System.Int32"
- even if you were modifying VB code which doesn't have the "int"
keyword but uses "Integer". The other way round,
setting Type to "DATE"
would set SystemType to "System.DateTime"
- not only for VB, but also for C#. Because the parser internally also uses the Type
setter, "DATE d;" would parse to "System.DateTime
d;" in C#!
To solve this, I removed the language-specific "Type".
Now the Type property always contains the SystemType.
You can use the new boolean IsKeyword property to
tell if the type was specified using the language keyword or if the CLR type was specified
Another related problem was that there was no way to output "System.Int32
a;" using NRefactory - the output visitor would always automatically convert
it to "int a;". I changed this, too - now the output
visitors will use the short form only if the IsKeyword property
is set. So code generators using NRefactory will output the long form when using the
new NRefactory version unless they are modified to set IsKeyword=true.
In revision 3506, SharpDevelop 3.0 got improved support for code analysis using FxCop
There were some bugs fixed that were related to the suppress message command
- it was working only with FxCop 1.35, but even there couldn't suppress messages for
static constructors and explicitly implemented interface members.
Using this command inserts a SuppressMessageAttribute in the code:
A new feature is support for custom dictionaries for the FxCop spell checker. Instead
of suppressing tons of spelling messages, you can simply add a new xml file to your
project with content like this:
add words specific to your application here -->
Disable Lineup as a single word - LineUp is the spelling used in WPF -->
Use this section to deprecate terms -->
Use this section to tell FxCop the correct casing of acronyms. -->
set the file's build action to "CodeAnalysisDictionary" (this build action does not
appear in the drop down, you'll have to type it in).
More than one year ago, I added the XAML language binding to SharpDevelop 3.0, showing
tooltips in .xaml files and enabling refactoring. ("XAML
and WPF support in SharpDevelop 3.0")
Now I finally added the missing part: code completion.
You get completion when typing an element:
And for attribute values if the property expects an enum:
In case anyone gets a wrong idea, take a close look at the title bar - it has the
word "experimental" in it:
The reverse integration of the WPF branch is the first step in the direction of "more
WPF" in SharpDevelop 4.0 (this screenshot shows the new WPF workbench and the new
WPF start page).
So what does this mean for the not-yet released version 3.0? As 3.0 is the last version
built entirely on top of Windows Forms, it will be a long-term stable release series
- meaning there are plans for at least 3.1 and 3.2. We know a lot of people are using
our workbench, our text editor and various other parts in their applications - and
we are definitely going to be supporting you in the future!
Our Wiki has a guideline
on joining the team which outlines the process of submitting code to the project.
As part of this year's #develop developer days (#d^3) we decided on a change to the
It is now possible to contribute "any-size" patches (be it a bug fix or feature enhancement)
when those code pieces (your changes) are licensed under the BSD
Why this change? We want to make it easier for the "accidential contributor" (ie someone
who stumbled across a bug and dabbled with our code to fix it) to get her or his changes
into our codebase without going through the "hassle" of having to sign & send
This should lower the barrier to contributing to our project.
If you want to work on a larger feature, we still want you to send us a JCA - the
simple reason being in it's name: it is a joint copyright assignment, making you and
the project owners to the copyright, allowing you and the project to work with the
code in any way desired. For more details on "Why the JCA" please see the guideline.
This addin integrates Microsoft
StyleCop into SharpDevelop. StyleCop only supports C#, and this addin has been
tested against StyleCop
4.3, earlier versions won't work.
Line highlighting of the warnings found
Change StyleCop settings on a per-project basis, copying from a master file you can
Run as part of the normal build process or on-demand from the project menu
So how do you run StyleCop? Simply from the context menu of the current C# project:
This will result in an error (given that you haven't installed StyleCop yet):
Therefore please download the latest version of StyleCop and install it. Note that
you must install the MSBuild integration:
Once installed, you have to tell SharpDevelop where to find it. This is done in the
Tools / Options dialog:
Click on "Find StyleCop path" and go to the MSBuild directory:
Now SharpDevelop knows how to find StyleCop, all you have to do is re-run the StyleCop
inspection of your project. In my sample project this results in quite a few warnings:
As you might not go d'accord with the default style checks, you can manipulate the
StyleCop settings right from your current C# project:
Those rules are documented in StyleCop.
Because the question keeps coming up repeatedly in the forum, I want to repeat the
most important pieces of advice from the last
thread in this blog post. Firstly and most importantly:
If you use SharpDevelop 2.x, you must use TortoiseSVN 1.4.x.
If you use SharpDevelop 3.x, you must use TortoiseSVN 1.5.x.
So why is this important? Well, Subversion 1.5 does change the working copy format,
therefore older clients cannot read the working copy anymore. And why is this important
to SharpDevelop? Daniel continues to explain:
SharpDevelop uses its own copy of the Subversion library for marking files
as added/removed/etc. This can upgrade the working copy to the 1.5 format.
However, SharpDevelop does not have it's own commit dialog - we simply
So there are two Subversion libraries used by SharpDevelop:
the one we ship for local operations, and the one shipped with TortoiseSVN for commit
etc. Because the Subversion 1.4 library cannot read working copies touched by the
1.5 library, you run into this kind of problem when either TortoiseSVN or SharpDevelop
is too old.
To sum up: SharpDevelop 2.x ships with libraries that are compatible with Subversion
1.4 and requires TortoiseSVN 1.4 for UI. Whereas version 3.0 of SharpDevelop ships
with (different) libraries that are compatible with Subversion 1.5 and requires TortoiseSVN
1.5 for UI.
So will there be an upgrade for SharpDevelop 2.x to support Subversion 1.5? This was
a hotly debated issue, however, in the end it boiled down to the following question:
do we want to ship two almost identical versions of SharpDevelop 2.2 that only differ
in the version of the included Subversion library (because we would have to support
both camps)? As that would create quite a bit of confusion, we decided to leave 2.2
as is and support Subversion 1.5 only in SharpDevelop 3.0.
If you receive the following error message
but have TortoiseSVN installed, then you have run into the following snag: SharpDevelop
3.0 is explicity marked as 32 Bit application, thus it cannot use the x64 version
Solution: install TortoiseSVN 32 Bit. It can be used in parallel with the x64 version.
Running SharpDevelop on USB thumb drives has been possible for a long time. What is
new in version 3.0 though is that the settings that usually go into the user's profile
can live directly on the memory stick - allowing you to take your settings with you
at all times. Here is the procedure:
Download SharpDevelop 3.0 and perform a standard installation on Windows. By default
the installation location (on an x64 machine) will be the following:
Simply copy the 3.0 directory to your memory stick, and then open the \bin directory
There, you have to open SharpDevelop.exe.config - and search for the appSettings section
which by default looks like this:
<!-- Use this configuration setting to store settings in a directory
relative to the location
of SharpDevelop.exe instead of the user's profile
<!-- <add key="settingsPath" value="..\Settings" /> -->
<!-- Use this setting to specify a different path for the code completion
The cache contains information about referenced
assemblies to speed up loading
the information on future SharpDevelop
<!-- <add key="domPersistencePath" value="..\DomCache" /> -->
<!-- Use this setting to disable the code completion cache. Code completion
will still be
available, but take longer to load and use more
<!-- <add key="domPersistencePath" value="none" /> -->
The comments tell you what to do, basically uncomment settingsPath and domPersistencePath:
<add key="settingsPath" value="..\Settings" />
<add key="domPersistencePath" value="..\DomCache" />
Save the file and you, SharpDevelop and your settings are ready to go. Note that once
started the two directories show up in the directory tree:
Starting with version 18.104.22.16810, the C# code completion in SharpDevelop has support
for implicitly typed lambda expressions.
Given a variable "IEnumerable<MyClass> items" and the "Select" extension method
from LINQ, typing "items.Select(i => i." now shows the members of MyClass. And
if the result of the Select call is assigned to an implicitly typed variable, SharpDevelop
is now able to infer that the variable has the type IEnumerable<return type of
the lambda expression>.
Unlike all other expressions in C#, the type of a lambda expression cannot be inferred
just from by at the expression itself (and the variables used by the expression).
To resolve lambda type parameters, we also need to look at the context where
the lambda is used. Currently, not all contexts are supported by code-completion,
you can find the list
of known problems in our bugtracker (Component: DOM / Resolver). Should you find
anything where code-completion does not work correctly which is not in that list,
please file a bug report in our forum.
The most commonly used context for lambda expressions is method calls, and this is
also the most difficult thing to support. It's easy when the method has a clear
signature like "void M(Func<int, string> f)", since then SharpDevelop can infer
the lambda parameter types directly from the delegate type. But most of the
time, things aren't that easy. For example, the signature of the Select method is
"IEnumerable<R> Select<T, R>(this IEnumerable<T> input, Func<T,
R> f)". Here, SharpDevelop needs to first infer what T is, then it can know what
the lambda parameter types are, and only after that it can resolve the lambda expression
to infer what R is.
But when the method has multiple overloads, things can get even more messy:
When a method has to overloads "void M(Func<string, int>
f)" and "void M(Func<int, int> f)", it
is valid to call them like this: "F(i=>i.Length)",
"F(i=>i+i)". In the first call, i is
a string; in the second, it is int. What SharpDevelop needs to do here is to infer
the lambda parameter types for each overload separately, infer the lambda's return
type; and then check that against the delegate's signature to see which overload was
the correct one.
i=>i.Length is a resolve error if i would
be int, but returns the expected int if i is
string; so i must resolve to string.
i=>i+i returns a string if i would
be string, but returns the expected int if i is
int; so i must resolve to int.
Note that because there's no way to tell the type of i before
the lambda expression is completed, you cannot expect that SharpDevelop gives you
correct code completion for it. "Length" will not be included in the code-completion
list for i when you type ".", because at that
point, the method call is "F(i=>i)", and i is
thus an int. But after the expression is written, SharpDevelop will show a tooltip
for "Length", and features like "Go to definiton" and "Find references" will work.
More Posts Next page »