SharpDevelop Community

Debugger visualizers - a Google summer of code project

martinkonicek — Mon, 29 Jun 2009 13:24:00 GMT

Hi,

my name is Martin Konicek and starting this summer, I will be trying to make your debugging experience in SharpDevelop even better. This blog will be about my project for Google summer of code 2009 - Debugger visualizers. The exciting part is that I'll be working on features that are not present in any IDE today.

Motivation

The idea is to introduce new ways to let you observe the state of the program during debugging. For me, by far the most used debugger feature are the tooltips. The problem with tooltips is they never show you the data structure "as a whole". Here we have two objects having a reference to each other:

As we can see, the tooltips can be expanded forever, even if we have only two objects forming a loop - there is no easy was to tell this information just from the tooltips. Long ago, I was thinking how gain more insight - what about displaying the objects in memory and references between them as an oriented graph, updating live when stepping in the debugger? I wrote it as a hobby project, which gave me important lessons how not to do that.

Object graph visualizer

I found out that SharpDevelop team had similar idea for Google summer of code, great! I applied, researched and wrote a prototype, which I sent to David Srbecky, the author of SharpDevelop debugger and my mentor. The prototype looked like this:

In the picture, the visualizer (right) shows all objects that can be reached from variable "a" in the program being debugged (left).

There is one more visualizer that is totally missing in today's IDEs in my opinion, and will be implemented. More about that next time.

Bio

I'm 23, from the Czech Republic, currently studying CS at Charles University in the beautiful city of Prague. I think .NET is great, I have used it as my primary platform for a couple of years now. I'm teaching basics of programming to freshmen at our university - I recommend this to everyone, it's a great experience. I have a personal programming blog here.

Stay tuned for updates..

Debugging IronPython Code in SharpDevelop

MattWard — Sat, 30 May 2009 12:40:00 GMT

With SharpDevelop 3.1 you can now debug IronPython code with the IronPython Interpreter (ipy.exe).

Before you start make sure the debugger is set to use the Just My Code feature. From the Tools menu select Options and then click the Debugging category.

Ensure that the Just My Code feature is checked and that the Step over code without symbols is not checked. If the Step over code without symbols option is selected then stepping will not work properly and lines of code will be skipped over.

There are two ways to debug your code. You can use the Python menu or modify the project options. We will look at both of these alternatives. First open your IronPython project into SharpDevelop. Open your main file and make sure it is the active text editor window. Set a breakpoint somewhere in your code. Then from the Python menu select Run.

This will start ipy.exe which will run your code and the debugger should stop the execution at the breakpoint.

From this point you can do the usual debugging activities such as stepping through your code, viewing the callstack, adding items to the watch window, etc.

If you want to use a different ipy.exe then this can be specified in the Python Options dialog (Tools menu | Options).

To enable debugging when you press F5 or select the Debug Run menu option you can modify the project options. From the Projects menu select Project Options and then open the Debug tab. Here you should change the Start Action to Start external program and use the browse button to locate ipy.exe. In the Start Options add the following command line arguments, changing the name of your main file as required.

-D ${ProjectDir}\Program.py

Once these changes are saved you can then press F5 and ipy.exe will be run under the debugger instead of running the compiled executable.3

Issues

No support for debugging the executable produced by the IronPython compiler since it does not produce debug symbols (i.e. .pdb files).
When using ipy.exe you need to add references to .NET assemblies explicitly in your code except for System which is included by default. For example:
```
import clr 
clr.AddReference("System.Windows.Forms") 
```

Thanks

Thanks to David Srbecky, SharpDevelop's debugger expert and maintainer, for reviewing the code changes I wanted to make to the debugger and making sure nothing was broken. Adding support for debugging IronPython was straightforward and required 10-15 lines of new code thanks to the code already written by David.

Thanks also to Harry Pierson (IronPython Program Manager at Microsoft) who has written a great set of blog posts on creating an IronPython debugger in IronPython which gave me the reason why SharpDevelop's debugger was not working when debugging IronPython code.

IronPython 2.0 Forms Designer

MattWard — Tue, 12 May 2009 19:50:00 GMT

Support for designing Windows Forms in IronPython is now available in SharpDevelop 3.1. The original IronPython forms designer was removed when SharpDevelop 3.0 began supporting IronPython 2.0 which had removed support for generating IronPython code from Microsoft's CodeDOM. The forms designer has now been re-implemented to use the IronPython abstract syntax tree (AST) and no longer relies on the CodeDOM.

Creating a Windows Application

To create a Windows Application open up the new project dialog by selecting New then Solution from the File menu. Select the Python category to show the available project templates. Select the Windows Application project template, enter a name and location and click the Create button.

Designing Windows Forms

The Windows Forms designer is not yet complete so be warned that it could generate form code that will no longer compile.

The designer can be opened by opening a form in the text editor and selecting the Design tab at the bottom of the editor.

Once open in the designer you can add controls to the form by dragging the controls from the Tools window. In the screenshot below a label, text box and a button have been added.

Click the Source tab at the bottom of the editor to view the generated code in the InitializeComponents method.

Limitations

The IronPython forms designer is not yet complete and the following are some of the known limitations.

No support for project or local form resources.
No support for icons.
Incomplete support for ToolStripItems and menu strips.
Incomplete support for ListViewItems.
No support for TreeViewItems.
Incomplete support for non-visual components (e.g. Timers).
Controls needed to be fully namespace qualified.

Forms Designer Internals

For those interested in how the forms designer actually works at a high level we will now look at what the IronPython forms designer does when loading and then generating code for a form.

To show the form in the designer the following steps are executed.

The form's code is parsed and an IronPython AST (PythonAst object) is created.
The AST is then visited and each control is added to the forms designer and the control's properties are set.
The form's properties are set in the designer and the form is displayed.

To generate the code after the form has been designed the following steps are executed.

The form is obtained from the forms designer.
Each of the child components of the form have their properties checked to see if they need to be serialized. This can be done by getting all the property descriptors and then checking the ShouldSerializeValue method. If they do need to be serialized then code is generated for them and added to a StringBuilder.
After all the child components are added the code for the form is generated.
Finally the generated code is inserted into the text editor inside the InitializeComponent method, replacing any existing code.

Converting C# and VB.NET Code to IronPython

MattWard — Mon, 11 May 2009 19:07:00 GMT

SharpDevelop 3.1 now supports converting C# and VB.NET code to IronPython. It can convert a single file or an entire project. The code to convert between these languages is still under development and has some limitations.

Converting an Individual File

To convert a C# or VB.NET file, open it in SharpDevelop's text editor, then from Tools menu select Convert code to Python.

The code conversion is limited to converting classes so it will not convert an arbitary piece of code that is not inside a class.

Converting a Project

To convert a C# or VB.NET project, open it in SharpDevelop, then from the Project menu select Convert From C# to Python.

Once converted the project will most likely not compile straight away due to limitations in the implementation. At the time of writing converting a project has the following limitations:

Project's Main File is not set.
No code generated to call the project's Main entry method.
Namespace imports do include all the used classes.

Code Conversion Internals

Converting code to IronPython was originally supported in SharpDevelop 2.2 and was based on converting code to a Microsoft CodeDOM and then getting IronPython 1.0 to generate the Python code. In IronPython 2.0 this CodeDOM support was removed so the code conversion feature was removed from SharpDevelop 3.0 since that was using IronPython 2.0. In SharpDevelop 3.1 the code conversion has been rewritten to no longer use the CodeDOM support. It now works by executing the following simple steps:

The C# or VB.NET code is parsed using SharpDevelop's parsing library NRefactory and an abstract syntax tree (AST) is generated.
A visitor class then walks this AST and generates Python code which is added to a StringBuilder.
Once the visit is complete the generated Python code is then displayed or saved to disk.

NUnit 2.5 Support

MattWard — Sun, 10 May 2009 16:46:00 GMT

SharpDevelop 3.1 now supports NUnit 2.5.

A summary of which NUnit version is supported by SharpDevelop is shown in the table below.

SharpDevelop 3.1	NUnit 2.5
SharpDevelop 3.0	NUnit 2.4.8
SharpDevelop 2.2.1	NUnit 2.4.7
SharpDevelop 1.1	NUnit 2.2

NUnit 2.5 Changes

NUnit 2.5 has changed quite substantially compared with the previous 2.4.8 release, as outlined in the NUnit 2.5 release notes. The problems that we had when migrating SharpDevelop's unit tests to NUnit 2.5 were as follows.

Assert.IsInstanceOfType has been replaced by Assert.IsInstanceOf.
Your code will still compile and work if Assert.IsInstanceOfType is used but you will get compiler warnings.
NUnit.Framework.SyntaxHelpers namespace no longer exists.
All classes that were in this namespace have been moved to the NUnit.Framework namespace.
The Has.Count constraint no longer takes an integer parameter.
To fix this problem replace code such as:
```
Assert.That(classesCollection, Has.Count(1));
```
With the following:
```
Assert.That(classesCollection.Has.Count.EqualTo(1));
```
Overriding a [TestFixtureSetUp] method in a derived class using the new keyword no longer works.
Some of the SharpDevelop unit tests were overriding an abstract base test class [TestFixtureSetUp] method in a derived class by using the new keyword, as shown below.

Base class:
```
[TestFixtureSetUp] 
public void SetUpFixture()  
{ 
    // Setup code. 
}
```
Derived class:
```
[TestFixtureSetUp] 
public new void SetUpFixture()  
{     
    // Extra setup code. 
    base.SetUpFixture(); 
}
```
In NUnit 2.4.8 the SetUpFixture method in the derived class would be called when running the tests allowing it to execute some extra setup steps. In NUnit 2.5 the base class SetUpFixture method is called instead and the derived class method is never called. To resolve the problem we changed the base class so it used a virtual method and allowed the derived class to override this to execute its extra setup steps.

Base class:
```
[TestFixtureSetUp] 
public void SetUpFixture()  
{ 
    BeforeSetUpFixture(); 
    // Setup code. 
} 
 
public virtual void BeforeSetUpFixture() 
{ 
}
```
Derived class:
```
public override void BeforeSetUpFixture() 
{ 
     // Extra setup code. 
}
```

Accepted GSoC students

DavidSrbecky — Fri, 24 Apr 2009 16:11:00 GMT

These projects have been accepted into SharpDevelop. You can learn more about each project by visiting the links below.

Student	Title	Mentor
Siegfried Pammer	XAML code completion for SharpDevelop	Bernhard Spuida
Philipp Maihart	Application "Database Tools Add-In"	Peter Forstmeier
Martin Konicek	Debugger visualizer for SharpDevelop	David Srbecky
Sergej Andrejev	Common keyboard shortcuts handling and management in SharpDevelop	Matt Ward
Tomasz Tretkowski	Integration of C++/CLI	Daniel Grunwald

Our goals for GSoC 2009 are simple:

provide students with a learning experience in advanced .net application programming
motivate students to become long term contributors
improve SharpDevelop in code areas the core team does not have time to work on currently

We look forward to having a great experience with all involved.

And don't worry, even if you were not selected for one of the slots available, we value your efforts and thoughts. If you want to contribute to SharpDevelop nevertheless, you are welcome and also will receive our support. Of course, there won't be money involved, but if you enjoy coding as much as we do, we will be glad to help and mentor you - just drop us a line to let us know and we will be there for you. If you don't, we look forward to seeing you around again in the next GSoC.

Thanks for all your applications and great project proposals. It is wonderful for us to see what you are thinking and planning.

Merging of Calls – Pinpointing Interesting Methods

siegi44 — Mon, 13 Apr 2009 12:20:00 GMT

As mentioned in the previous post, SharpDevelop 3.1 will contain a built-in profiler.

Today we'll talk about what data the profiler collects, and what exactly "merging" is.

We’ll use the following sample program for exploring the topic:

using System;
using System.Threading;

namespace ICSharpCode.Profiler.Example1
{
    class Program
    {
        static void DoCalculation(bool doLotsOfWork) {
            if (doLotsOfWork) {
                int target = Environment.TickCount + 1000;
                while (Environment.TickCount < target) { }
            } else
                Thread.Sleep(100);
        }

        static void SomeMethod() {
            DoCalculation(true);
        }

        static void SomeOtherMethod() {
            for (int i = 0; i < 10; i++) {
                DoCalculation(false);
            }
        }

        static void Main() {
            SomeMethod();
            SomeOtherMethod();
        }
    }
}

SomeMethod and SomeOtherMethod take the same amount of time, but for different reasons.

If we simply store timing information per method, it would seem that DoCalculation spends 50% of the time in get_TickCount and 50% in Thread.Sleep.

But a good profiler should be able to show that only the invocations of SomeMethod spend their time in get_TickCount, whereas SomeOtherMethod ends up spending time in Thread.Sleep.

Or, assume you have a program with a textbox and a button. You click on the button, then change the text (input to the program) and then run the button code again. The other input might mean that the performance characteristics of the button method change dramatically - so ideally, we should be able to view each click separately.

What data does the profiler have to collect to do this? The easiest solution would be to record all function calls. For each function call, store the function ID, the call start time, and the call end time.

That way, we don't lose any data; we can reconstruct the application's stack at every point in time.
Of course, if you are looking into a performance issue, you don't want to look at individual stack traces - you want a little more overview. Or expressed for our textbox/button example: It is nice to be able to separately view the data for each button click; but initially, you'll want to look at all data at once.

Now we get to our data model: when you're using the SharpDevelop profiler, you're dealing with "merged" sets of individual calls. Instead of seeing a single call stack, you'll see the tree of all call stacks.

For our example code, this looks like in the following screenshot:

Note that the ten calls to DoCalculation inside SomeOtherMethod were merged into a single node in the tree view (a "merged" call). In this view, you are not able to view an individual call's timing data, only the sum of all individual times. However, the DoCalculation call inside SomeMethod and that in SomeOtherMethod are still separate, as these have different call stacks.

If you want to view them together, select both calls and use Right Click > Merge.

A new tree will open with all 11 calls merged together:

No matter whether we're dealing with multiple calls after each other, or with calls in different positions in the tree, it's always the same operation: merging. You can even merge calls of different functions together - though unless the functions do similar things, you won't get useful results.

For example, here you can see SomeMethod and SomeOtherMethod merged together:

Note that merging functions also merges their children (grouped by function name).

Now it's pretty clear what the timeline control above does: the profiler takes all root nodes from all stack traces in the selected time span, and merges nodes belonging to the same thread.

However, naïvely storing every function call individually takes a lot of space - about 7 GB (!) for SharpDevelop starting and opening its own solution (SharpDevelop.sln). That's why the profiler limits you to selecting start and end positions for the time spans with a granularity of about 500ms: during profiling, the profiler hook merges the calls into data sets of about 500ms.

We never actually create the "function start,end"-entries proposed above, but directly build a merged representation as the profiler runs. That way we dramatically reduce the size of the profiler output: only 198 MB for SharpDevelop starting and opening its own solution.

In the next post we will give you a brief overview of all the other commands you can access in the context menu of each call and how to use them.

Introducing a New Tool in SharpDevelop – The Profiler

siegi44 — Sat, 04 Apr 2009 16:43:00 GMT

Nearly one year ago, we started building a new tool for SharpDevelop: a profiler. It will make it easier to analyze and improve the performance of applications developed using SharpDevelop. In the next few weeks we are going to give you an overview of all the different aspects of the profiler, its usage and we will shed some light on its implementation and technical details.

Using the Profiler

To start a new profiler session just go to “Quality Tools” > “Profiler” and then you can decide whether to profile the currently opened project or you can select a program to run.

During execution of the application, performance data is collected. On program end, SharpDevelop will automatically open up the session and display the collected data.

In the “Overview” tab, all threads and all calls are listed. In the “Top 20” tab 20 methods, in which most time is spent during run time, are listed. On the right side you can see the ring diagram. The concept of the ring diagram was taken from the Ubuntu “Disk Usage Analyzer”. It can be used to easily navigate to deep levels of the call tree. Just click on a call to move there. If you want to go back to the call you had selected before, just click inside the gray circle in the middle.

To show details on a call in the ring diagram simply move the mouse over it and a tool tip with important information will be displayed. The gray circle represents the call currently selected in the tree view. The innermost ring is a pie chart showing the children of the selected call. The size of each piece is proportional to the time spent inside that call. The other rings represent the deeper levels of the call tree.

In the next post we will show you the “merge” feature, which allows you to view multiple parts of the call tree at once. The “merge” feature is used by the “Top 20” tab and the timeline too.

GSOC proposals

Laputa — Sat, 04 Apr 2009 00:16:03 GMT

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...(read more)

Subversion 1.6

Laputa — Fri, 03 Apr 2009 20:20:24 GMT

In SharpDevelop 3.1.0.3948, I changed our Subversion integration to use SharpSVN instead of SvnDotNet . 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 text editor. 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...(read more)

GSoC 2009

Laputa — Tue, 24 Mar 2009 13:42:01 GMT

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 base): The database scout / database api / EDM designer (we already...(read more)

SharpDevelop and the Google Summer of Code 2009

DavidSrbecky — Tue, 24 Mar 2009 02:09:00 GMT

SharpDevelop is participating in the Google Summer of Code this year.

It is an opportunity for students to earn 4500 USD over the summer by working on an open-source project.

We have created a list of ideas, but you can work basically on anything you want as long as it is relevant to SharpDevelop. You can find the list of ideas and any further information on the SharpDevelop wiki page for the Google Summer of Code. You can submit your application here.

If you are not a student or if you do not have enough spare time, you can benefit as well.... share your ideas with us and maybe some student will pick them up and implement them.

Feel free to contact us on the forums or via email.

Please spread the word and tell your friends about the Summer of Code...

Using the Python Standard Library

MattWard — Sun, 01 Mar 2009 14:43:00 GMT

Here is a short walkthrough on how to use the Python Standard Library with SharpDevelop 3.0 and IronPython 2.0.

Prerequisites

You will need to have SharpDevelop 3.0 and Python 2.5 installed on your machine. These can be downloaded from the following locations.

Note that using Python 2.6 is not supported. The following section assumes that Python 2.5 was installed into the C:\Python25 folder.

Using the Python Standard Library

First we will create an IronPython console application in SharpDevelop. From the File menu select New and then Solution. In the New Project window select the Python category and select the Console Application template.

Give the project a name, select its location and click the Create button.

To use the Python Standard Library the project needs a reference to IronPython.dll, which should be added by default, and a reference to IronPython.Modules.dll. Open the Projects window, if it is not already open, by selecting Projects from the View menu. Right click the project's references and select Add Reference. In the Add Reference dialog first add a reference to mscorlib, this reference is needed since we are going to use the System.Console class to pause the console output. Then select the .NET Assembly Browser tab and click the Browse button. Locate the IronPython.Modules.dll file and select it. This file should be in the following folder:

C:\Program Files\SharpDevelop\3.0\AddIns\AddIns\BackendBindings\PythonBinding

Click OK to close the Add Reference dialog.

In the Program.py file change the code to the following:

# Add Python Standard Library to search path. 
import sys 
sys.path.append("c:\python25\lib") 
 
# Use Python Standard Library os module. 
import os 
print os.getcwd() 
 
# Wait for a key press before closing the console window. 
import System 
print "Press any key to continue..." 
System.Console.ReadKey(True)

The sys.path.append line adds the Python Standard Library to the search path. After that the os module is imported and the os.getcwd method is called to get the current working directory and this is output to the console window. The last three lines of code are just used to pause the console window so we can see the output.

Compile the above code by selecting Build Solution from the Build menu.

Finally run the application by selecting Run from the Debug menu.

SharpDevelop 3.0 Final

Laputa — Tue, 10 Feb 2009 08:48:17 GMT

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 get it...(read more)

WPF Designer Removed From SharpDevelop 3.0

Laputa — Sun, 14 Dec 2008 19:17:46 GMT

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...(read more)

NRefactory TypeReference - breaking change

Laputa — Sat, 06 Dec 2008 18:49:41 GMT

In version 3.0.0.3660, 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 " and SystemType=" System.Int64 ". However, this got a little problematic if you wanted to modify the AST - do you have to change both Type and SystemType ? Actually, setting...(read more)

WiX 3.0 AddIn for SharpDevelop 2.2

MattWard — Tue, 18 Nov 2008 19:53:00 GMT

If you want to use WiX 3.0 with SharpDevelop 2.2 now you can. SharpDevelop 2.2 will still ship with WiX 2.0 support however the WiX 3.0 addin has been backported. This WiX 3.0 addin for SharpDevelop 2.2 can be downloaded at the end of this post. It was built and tested using WiX 3.0.4714 which is the most recent release at the current time.

Installing

The simplest way to use the addin is as follows.

Download the wix3-binaries.zip file from SourceForge.
In SharpDevelop's WiX addin folder SharpDevelop\2.2\AddIns\AddIns\BackendBindings\WixBinding rename the original WixBinding.addin file to WixBinding.addin-bak.
Copy the contents of the bin folder in the Wix3Binding.zip file to SharpDevelop\2.2\AddIns\AddIns\BackendBindings\Wix3Binding.
Copy the contents of the doc folder in the wix3-binaries.zip file to the SharpDevelop\2.2\data\schemas folder. This updates the WiX schemas for use in the XML editor.
Rename the folder SharpDevelop\2.2\Tools\Wix to SharpDevelop\2.2\Tools\Wix-bak
Copy the contents of the wix3-binaries.zip file to the SharpDevelop\2.2\Tools\Wix folder.
Restart SharpDevelop.

Updating to Newer WiX Versions

Download the wix3-binaries.zip file from wix.sf.net
Copy the contents of the wix-binaries.zip file to the folder SharpDevelop\2.2\Tools\Wix.
Copy the contents of the doc folder to the SharpDevelop\2.2\data\schemas folder.
If there are any problems try re-compiling the source code and check the unit tests still work.

Compiling the Source Code

Copy the contents of the Wix3Binding zip file into the folder SharpDevelop\2.2\src\AddIns\BackendBindings\Wix3Binding.
Run msbuild WixBinding.sln.

Download Wix3Binding.zip

Windows.Forms Designer Project Resource Support

Christian Hornung — Wed, 10 Sep 2008 18:55:00 GMT

As of SharpDevelop 3.0 build 3534, the integrated Windows.Forms designer supports project resources for images and icons. Especially, this means that forms generated by Visual Studio that use such resources can now be loaded and modified in SharpDevelop.

In earlier versions of SharpDevelop, when adding an image or icon to a control the only possibility was to import an image file which was then stored in the resource file of the form. This also meant that an image was often stored in the resources multiple times, for every single control where it was used.

In the new build, you will now see the following dialog when you click on the dots to edit an image property of a control:

The "local resource" option in combination with the "Import" button lets you do what the earlier versions did: Import a file and store it in the resources of the form.

The new "project resource" option, however, lets you choose a suitable image resource from any resource file in the current project that does not already belong to a form. This way, resources can be reused and maintained more efficiently.

Adding this feature required a lot of complex coding, including creating custom code serializers and deserializers, and getting this right is sometimes more like a game of pure chance, because the internals of the forms designer in the .NET framework are documented poorly. So, please feel free to test this feature thoroughly and report any problems in the forums.

Code Analysis improvements in SharpDevelop 3.0

Laputa — Sat, 06 Sep 2008 17:32:29 GMT

In revision 3506, SharpDevelop 3.0 got improved support for code analysis using FxCop 1.36. 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...(read more)

XAML code completion

Laputa — Thu, 04 Sep 2008 23:04:00 GMT

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: For attributes: And for attribute values if the property expects an enum:...(read more)

First Mirador (SharpDevelop 4.0) Screenshot

Laputa — Thu, 04 Sep 2008 17:57:06 GMT

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...(read more)

More Comprehensive Exception Reports for SharpDevelop

Christian Hornung — Tue, 02 Sep 2008 19:20:00 GMT

First and foremost, we hope that you will not see the "unhandled exception" dialog box of SharpDevelop often. Nevertheless I would like to shed light on some improvements in that area.

In spite of all error reporting features of an application, the best thing users can do to help us is to describe as precisely as possible what they were doing that eventually led to the error. However, SharpDevelop 3 now also outputs some additional information that may help with fixing the bugs. As of build 3.0.0.3455, two extensions to the exception reports created by SharpDevelop are in place and working:

The log message recorder permanently stores a number of internal log messages (currently up to 25) in a cyclic buffer. Those messages are then added to the report whenever an unhandled exception occurs. Here you can see the exception box with some log messages scrolled into view:

Additionally, some state information is added to the report. Currently the following items are listed:

installed 3rd party add-ins
type and name of the current project
name and some properties of the current solution
active view content

Please note that the new exception reports can contain information which you might want to keep private. For example, names of projects, files, classes, methods etc. can appear in the log messages and state information, perhaps even parts of code that has been edited. If you are concerned about privacy, you should look through the generated report and check whether it contains anything you do not want to disclose before posting it. Feel free to anonymize it as necessary, but please make sure that you do not change the "meaning" of the report - i.e. if you change a name, change all occurrences of that name equally.

Patch-Sized Contributions Without JCA

Laputa — Mon, 01 Sep 2008 17:12:32 GMT

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 guideline: 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 license . Why this change? We want to make it easier for the "accidential contributor" (ie someone who stumbled across...(read more)

XML Editor Reuse

MattWard — Sun, 31 Aug 2008 14:00:00 GMT

It is always good to see that someone else finds the code that you have written useful enough to be reused in another application. Here we take a look at where SharpDevelop's XML Editor has been reused. The XML Editor was originally added to SharpDevelop 1.0 back in April 2005.

MonoDevelop

Some time ago I ported SharpDevelop's XML Editor so it could be used from inside MonoDevelop. Currently there is an addin available for MonoDevelop 1.0. MonoDevelop 2.0 now ships with this XML Editor after Michael Hutchinson from Novell integrated it in March this year. I also believe that it is being used to help provide at least some part of the autocompletion for ASP.NET. It will be interesting to see how Michael builds on and improves the XML Editor code.

Kaxaml

Kaxaml is a lightweight XAML Editor written by Robby Ingebretsen. Kaxaml version 1.0 and 2.0 use a modified version of SharpDevelop's XML Editor. Robby has replaced the user interface part so the autocompletion popup window now uses WPF. He has also modified it so the autocompletion popup window behaves the same as Visual Studio's XML Editor. For example, SharpDevelop automatically inserts the equals sign and double quotes an attribute name is autocompleted whilst Visual Studio will autocomplete just the attribute name and then automatically insert the double quotes after the equals sign is typed in.

Intellisense for Microsoft Expression Blend 2.5

Stefan Dobrev has written an addin to provide XML autocompletion for the as yet unreleased Expression Blend 2.5. This addin uses the XML Editor code from Kaxaml to provide the autocompletion. Stefan has modified this code slightly to add support for the Expression Blend's code editor.

New feature: Extract method

siegi44 — Mon, 25 Aug 2008 13:17:00 GMT

In the upcoming SharpDevelop 3 there's a new refactoring included: Extract method. With it you can easily split a method into two independent methods.

If you want to use it you first have to select the piece of code you want to extract:

Then just click on Refactor > Extract method in the main menu:

The preview will pop up, here you can enter a name for the new method:

After entering a name click "OK" and here you can see the new method and the inserted call:

Of course you can undo the change, just press Ctrl+Z.

I hope you find this refactoring useful and I would be glad to receive any comments on this.