SharpDevelop Community

Usage Data Collector: The Signup Message

ChristophWille — Thu, 18 Mar 2010 12:55:00 GMT

This is the start of a series of blog posts describing the Usage Data Collector that is built into SharpDevelop 4.0. UDC as it is called for short is intended to help us better understand what features are being used, how developers found out about the feature (menu, toolbar, context menu, et cetera), how much time they spent using the feature, and if there were any issues (exceptions). The intention is to find out which features need to be surfaced differently so more people use them, which the popular features are (and thus should be given a higher priority) and a lot more.

Before diving into the topic of this blog post, one important piece of architecture information: UDC is not tied to SharpDevelop. We developed it to be reuseable in your applications. Including (a yet to be developed) analysis Web frontend. That's also why we intend to give you a good background on what we collect, how we collect it, how it is transferred - so you have a good understanding whether it is suitable for your userbase.

On its new start page, SharpDevelop 4.0 asks you to participate in the customer experience improvement program:

If a user wants to participate and clicks the "Save" button, we do send the initial usage data message - for two reasons: first, depending on firewall settings, the user might need to allow SharpDevelop to communicate with the Internet. Doing it right now and there allows the user to see why SharpDevelop wants Internet access. Secondly, we gather Session "0" - information about the version of SharpDevelop, and on top of what platform it is running.

In terms of actual data, this is a sample UDC signup message (line 1 has been truncated for xmlns elements):

 1:  <UsageDataMessage ...>

 2:    <Sessions>

 3:      <UsageDataSession>

 4:        <EndTime i:nil="true" />

 5:        <EnvironmentProperties>

 6:          <UsageDataEnvironmentProperty>

 7:            <Name>platform</Name>

 8:            <Value>Win32NT</Value>

 9:          </UsageDataEnvironmentProperty>

10:          <UsageDataEnvironmentProperty>

11:            <Name>osVersion</Name>

12:            <Value>5.1.2600.196608</Value>

13:          </UsageDataEnvironmentProperty>

14:          <UsageDataEnvironmentProperty>

15:            <Name>processorCount</Name>

16:            <Value>1</Value>

17:          </UsageDataEnvironmentProperty>

18:          <UsageDataEnvironmentProperty>

19:            <Name>dotnetRuntime</Name>

20:            <Value>4.0.30128.1</Value>

21:          </UsageDataEnvironmentProperty>

22:          <UsageDataEnvironmentProperty>

23:            <Name>appVersion</Name>

24:            <Value>4.0.0.5623</Value>

25:          </UsageDataEnvironmentProperty>

26:          <UsageDataEnvironmentProperty>

27:            <Name>language</Name>

28:            <Value>es</Value>

29:          </UsageDataEnvironmentProperty>

30:          <UsageDataEnvironmentProperty>

31:            <Name>culture</Name>

32:            <Value>es-ES</Value>

33:          </UsageDataEnvironmentProperty>

34:          <UsageDataEnvironmentProperty>

35:            <Name>userAddInCount</Name>

36:            <Value>0</Value>

37:          </UsageDataEnvironmentProperty>

38:          <UsageDataEnvironmentProperty>

39:            <Name>architecture</Name>

40:            <Value>x86</Value>

41:          </UsageDataEnvironmentProperty>

42:        </EnvironmentProperties>

43:        <Exceptions />

44:        <FeatureUses />

45:        <SessionID>0</SessionID>

46:        <StartTime>2010-03-18T12:01:38.5625Z</StartTime>

47:      </UsageDataSession>

48:    </Sessions>

49:    <UserID>cb02e999-4e80-45d2-9773-ed3d80b3937f</UserID>

50:  </UsageDataMessage>

Please note line #49: each client machine creates a GUID for itself. This GUID is used to map all sessions to a single user - so we can tell whether a single developer is using a feature heavily compared to say a hundred developers using the very same feature lightly.

As you can see, the initial message is very small. Once data is being gathered, the messages do increase in size, and contain more information (feature use, exceptions). We will look into those message in future blog posts, as well as how those messages are processed and analyzed.

Compiling Python Packages with IronPython

MattWard — Tue, 16 Mar 2010 21:03:00 GMT

Here is a walkthrough on how to compile Python packages and modules, such as those provided by the Python Standard Library, so you can distribute your IronPython application as a set of standalone assemblies. If you just want to use the Python Standard Library without compiling parts of it into your application then you can add the path to the standard library as described in a previous post on using the Python Standard Library.

Prerequisites

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

Python Modules Included with IronPython

Before you start compiling a Python module or package into your application you should check whether it is already included with IronPython or whether you can use the .NET framework instead. A lot of the Python Standard Library modules are already included with IronPython. You can see which ones by using Reflector to look at IronPython.dll and IronPython.Modules.dll. Open these assemblies in Reflector, right click and select Disassemble. In the screenshot below the modules that are included with IronPython are defined by the PythonModule attribute.

Alternatively you can use the IronPython Modules Reader application to list all the available modules in IronPython.

If you need to use one of the modules provided by IronPython then add a reference to IronPython and IronPython.Modules in your project and then import the module in the normal way:

import cmath

Compiling a Python Module

Now we will look at writing a simple IronPython application that reads in a zip file using the zipfile module from the Python standard library. Our application will read the names of all the files in the zip file and display them in the console window. The code is shown below.

import zipfile 
 
file = zipfile.ZipFile("test.zip", "r") 
 
for name in file.namelist(): 
    print name

Now if you create a python console project with SharpDevelop, copy the code above into the Program.py file, compile and run the program you will get an error saying "No module called zipfile". To fix this problem you can add the zipfile.py file from the Python standard library directly into your project. Simply right click your project, select Add Existing Item and browse to the zipfile in the python libs folder (e.g. C:\Python26\lib). If you compile your program again and run it you will get an error about a different module. The zipfile module depends on 13 other modules from the standard library. With a bit of trial and error you can work out which modules are needed. After adding these dependent modules to your project you will have a set of assemblies that do not require the Python Standard library to be installed.

The full code for the zip file reader application can be downloaded from the Zip File Reader link at the end of this post.

Compiling a Python Package

A Python module consists of a single file (e.g. zipfile.py). A Python package is a set of files inside a subdirectory. Compiling a package into your application cannot be done simply by including the files directly in your project. Instead you must compile the package files into a separate class library assembly. As an example we will look at using the json package. We will create a simple application that creates a json string from a dictionary. The code is shown below.

import json 
 
address = {} 
address["street"] = "24 22nd Street" 
address["city"] = "New York" 
address["state"] = "NY" 
address["postCode"] = "10021" 
 
person = {} 
person["firstName"] = "John" 
person["lastName"] = "Smith" 
person["age"] = 20 
person["address"] = address 
 
print json.dumps(person)

Now to use the json package from our application we need to create a python class library project. Then we need to add all the files from the json package into this project and compile it. Finally in our Json Writer project we need to add a reference to this class library. The screenshot below shows the contents of the two projects.

Now this is not quite enough since the json package depends on several modules in the standard library. So now we add these to the json class library project. After adding these modules the json class library project should then contain the files as shown in the screenshot below.

You should now be able to compile and run your Json Writer application. The Json Writer application can now be distributed as a set of assemblies without needing the Python Standard Library to be installed.

The full code for the Json Writer application can be downloaded from the Json Writer link at the end of this post.

Finally here is a link to the license FAQ for Python and Python Standard Library that should be checked before you include the standard library in your application.

Downloads

IronRuby 1.0 RC3

MattWard — Sat, 13 Mar 2010 15:47:00 GMT

The latest releases of SharpDevelop 3.2 and 4.0 (versions 5611 and above) now include IronRuby 1.0 RC3 which was released yesterday.

The IronRuby console (ir.exe) command line option to use Ruby 1.9 mode has changed in this release from -19 to -1.9 so if you have an IronRuby project (.rbproj) created with a previous version of SharpDevelop you will need to change the command line used when debugging your application. To do this from the Project menu select Project Options and then update the Start Options Command Line, for example:

-1.9 -D Program.rb

IronPython and IronRuby versions in SharpDevelop

MattWard — Wed, 03 Mar 2010 18:40:00 GMT

SharpDevelop	IronPython	IronRuby
SharpDevelop 2.2.1	IronPython 1.1*	n/a
SharpDevelop 3.0	IronPython 2.0	n/a
SharpDevelop 3.1	IronPython 2.0.2	IronRuby 0.9.1*
SharpDevelop 3.1.1	IronPython 2.6	IronRuby 0.9.1*
SharpDevelop 3.2	IronPython 2.6.1 RC1	IronRuby 1.0 RC3
SharpDevelop 4.0 (.NET 4.0 RC1)	IronPython 2.6.1 RC1 (.NET 4.0 RC1)	IronRuby 1.0 RC3 (.NET 4.0 RC1)

* - Available as a separate addin not shipped with SharpDevelop.

Debugging an ASP.NET Application with SharpDevelop

MattWard — Sun, 28 Feb 2010 18:53:00 GMT

This tutorial shows you how to debug an ASP.NET application with SharpDevelop.

Before we begin it should be noted that SharpDevelop does not have great ASP.NET support. There is no web forms designer, no intellisense for ASP.NET pages (.aspx) and no support for the new style ASP.NET Web Site projects introduced in Visual Studio 2005. You can however create an ASP.NET Web Application project or an ASP.NET Web Service in SharpDevelop. If you are looking for a better ASP.NET experience then you should use Microsoft Visual Web Developer. However if still want to use SharpDevelop then here is how to debug your ASP.NET application.

Creating an ASP.NET Application

First let us create an ASP.NET Web Application. From the File menu select New, then Solution, to open up the New Project dialog.

On the left hand side of this dialog select ASP.NET category underneath the C# category. On the right hand side select the ASP.NET web page project icon. Give project a name and choose where you want the project created and click the Create button. SharpDevelop will then create a basic ASP.NET Web Application project.

Download Cassini

In order to be able to debug the ASP.NET application we will be using Cassini. Cassini is a lightweight open source web server. It was originally released as a sample by Microsoft. Dmitry Robsman then updated the sample to run under .NET 3.5. After that different versions based on Dmitry's original work were released on codeplex. Any of these versions of Cassini, in the list below, will work with SharpDevelop. The version of Cassini provided by Dmitry requires you to compile the source code. The other versions do not. The Cassini Developer's edition has slightly different command line options compared to the rest so it will not be covered in the following discussion. We will use Cassini++ for the rest of this tutorial.

Cassini++
Dmitry Robsman - Cassini v3.5 or Cassini v3.5.0.2 with friendly url/routing support.
Cassini 3.5 Developers Edition

Download Cassini++ from the link provided and extract the files to a directory on the same machine that you are running SharpDevelop on.

Debugging an ASP.NET Application

First let us set a breakpoint in our application. Find the Default.aspx.cs file in your project and open it in the text editor. Locate the Page_Load method and set a breakpoint inside this method on the Response.Write line.

Now you need to configure the project to run Cassini when you debug your application. From the Project menu select Project Options. In the options dialog select the Debug tab. Set the Start Action to Start external program and enter the path to the Cassini executable. In the Start Options enter the command line that will be passed to Cassini. The Cassini command line is of the form:

<physical-path> <port> <virtual-path>

In the screenshot below you can see an example command line passed to Cassini. In this case Cassini will listen for requests on port 8080, the virtual path will be set to "/" and the physical path to your project is specified by a using SharpDevelop property ${ProjectDir} which will be replaced when you start debugging. You can put the full path to your project directory here instead of using the ProjectDir property.

Save the changes you made to the project options. Then select Run from the Debug menu. Cassini should then start.

Click the http://localhost:8080/ hyperlink at the bottom of the Cassini window to visit your application's web page in the default browser. When the page is loaded in the browser the breakpoint in Page_Load should then be hit and you can start debugging.

Attach to Process

As an alternative to configuring SharpDevelop to start Cassini every time you debug your ASP.NET application you can leave Cassini running and attach to its process when you need to.

First on your desktop create a shortcut to Cassini and specify the appropriate Cassini command line as explained earlier. Note that the ${ProjectDir} property cannot be used here so instead you will need to put the full path to your project. Start Cassini by double clicking the shortcut and use a browser to display your web page. Now in SharpDevelop select Attach to Process from the Debug menu. Select the Cassini process and click the Attach button.

Now when you press Ctrl+F5 in the browser showing your web page to refresh the page the breakpoint in the Page_Load method should be hit and you can start debugging.

SharpDevelop and the Google Summer of Code 2010

DavidSrbecky — Sat, 20 Feb 2010 16:32:00 GMT

Google Summer of Code 2010 has been officially announced and SharpDevelop intends to participate again.

Google Summer of Code is an opportunity for students to earn 5000 USD over the summer by working on an open-source project.

We have created a list of ideas, but you can work on anything you want as long as it is related to SharpDevelop. You can find the list of ideas and any further information on the SharpDevelop wiki page for the Google Summer of Code. The application deadline is 19:00 UTC on April 9th. In the meantime, you can start coding and talking to us on the forums, via email or on the IRC (#SharpDevelop at irc.freenode.net).

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

If you have any project ideas for the students, feel free to mention them in the comments below the post.

Code Converter Site Upgraded to SharpDevelop 3.2 RC1

ChristophWille — Sun, 14 Feb 2010 15:38:00 GMT

With the release of RC1, the code converter site has been upgraded too (from NRefactory 3.2.0.5362 to 3.2.0.5506). Relevant checkins:

http://fisheye2.atlassian.com/changelog/sharpdevelop/?cs=5432
http://fisheye2.atlassian.com/changelog/sharpdevelop/?cs=5448

Supported languages (via Web interface as well as Web Service): C#, VB.NET, Boo, IronPython, IronRuby.

Progress in SharpDevelop 4.0

DanielGrunwald — Fri, 12 Feb 2010 18:59:00 GMT

SharpDevelop execute many tasks that require progress reporting. Most also can be cancelled by the user.

Examples are:

Loading a solution (parsing files for code completion and class browser)
Building
Searching

In SharpDevelop 4.0.0.5483, I've rewritten the IProgressMonitor interface used for these operations. The main difference in comparison with the old interface is that it is now possible to create nested progress monitors, allowing the composition of large progress-reporting operations from many smaller operations. Also, creating nested progress monitors now allows to safely report progress from parallel computations. Every thread can create its own nested progress monitor for reporting its progress.

Now what happens with these progress reports? They will be collected by the ProgressCollector class. The ProgressCollector takes care of summing up the progress from all nested progress monitors. It also handles the multi-threading issues. The output of a ProgressCollector is a simple set of properties describing the current progress of the operation, plus a "PropertyChanged" event which will be fired only on the GUI thread. This allows using WPF data binding to display the total progress in a progress bar.

Another difference is that the cancellation support has been simplified by making use of the .NET 4 cancellation framework.

The above changes don't have any visible effect for the end-user. However, while working on this, I had an idea: similar to the progress bar in Windows Explorer in Vista and Windows 7, the progress bar should turn red when there are errors. This gives immediate visual feedback that the build failed, making it a lot less likely that you miss the error messages in the "Errors" pad and wonder why your binary didn't change.

A related change in SharpDevelop 4.0.0.5490 is that the progress is now shown on the Windows 7 task bar:

So the progress of long-running builds is always visible; even if you minimize SharpDevelop and do something else while the compiler is working.

Shaving 30% Off Setup Size (+Upgrading to SHFB 1.8.0.3)

ChristophWille — Fri, 12 Feb 2010 17:52:00 GMT

This blog post announces two major changes for SharpDevelop 3.2: a setup size reduction from 21.1MB down to 14.6MB (a clean 30% less than before), and an upgrade of Sandcastle Help File Builder support to version 1.8.0.3.

So how did we shrink the setup? Let's look at some sizes first:

Revision 5493 is before the upgrade of SHFB support (happened in 5499), and 5500 is the latest setup build - with additional tweaks. So what are the tweaks?

Basically, we had a look at feature usage. Like "How many people actually know that we are shipping the WiX *.chm documentation with SharpDevelop?" or "How many people actually generate documentation chm files from XML comments?". Turns out that the answer is "not too many".

The delta of 5499 to 5500 shows the effect of the WiX help documentation. And 5493 to 5499 the delta of the old release of SHFB.

Which brings me to the upgraded functionality: we had a 1.7 release in the box, and 1.8.0.3 uses a different project file format. We had to upgrade that for "Build documentation..." (project context menu) to work properly with the new release.

If you don't have SHFB on your computer (which is now the default after installing SharpDevelop), you will see the following dialog:

This dialog is now standardized (we haven't installed TortoiseSVN in the past either). Simply follow the link, install the latest version, and you are good to go (even without restarting SharpDevelop, we perform the "SHFB installed?" check on the fly):

Note that we produce a valid .shfbproj file with a reference to the project you just had open.

So why are we shipping some stuff in the box and some not? That mostly depends on how deeply integrated a feature is in the IDE (well, after all that is short for integrated development environment). We have to have control over certain tools and the version being used. In some cases we can leave it up to the user to install it if needed, like F# support, Subversion support, FxCop or StyleCop support, or now documentation generation.

Lean & mean is the new green.

F# Interactive - SharpDevelop 3.2 vs SharpDevelop 4.0

ChristophWille — Fri, 12 Feb 2010 15:38:00 GMT

SharpDevelop wraps F# Interactive (fsi.exe) in a pad of its own. For SharpDevelop 3.2, it looks like this:

You type the code you want to evaluate in a single-line textbox on top of the fsi.exe output.

With revision 5498 (part of SharpDevelop 4.0), Daniel reused Siegfried's approach for the debugger console to make F# Interactive a lot more compelling:

You type right inside REPL. Way more useful!

Boot note: In revision 5494, we ported the F# backend binding from F# (yes, the F# binding was written in F#) to C#. The main reason was that requiring F# - which is not part of the basic .NET installation - caused us problems (again) with the automated build.

Getting Started With SDR

Peter Forstmeier — Wed, 13 Jan 2010 14:19:00 GMT

For those of you that haven't followed the development of SDR in the past, a quick introduction on how to get started.

There is a Wiki dedicated to SDR: http://sharpdevelopreports.net/ (please note that it hasn't been updated yet for the fact that SDR is now back in the fold with SharpDevelop)

It contains a feature tour (with screenshots) to give you an idea how to get up and running quickly. I'd also recommend reading the what's new blog post from the SDR beta, as it contains information on the newly added functionality (such as expression support).

Speaking of support: there is a dedicated forum for SDR on our community site, please let me know about problems, ideas, fixes et al there!

SharpDevelop Reports Re-Integrated Into SharpDevelop

Peter Forstmeier — Tue, 05 Jan 2010 22:18:00 GMT

As of today, SharpDevelop Reports (SDR) is once again an integral part of SharpDevelop!

It will be shipped with SharpDevelop 3.2 (~spring 2010), but it is already available on the build server as part of the SharpDevelop integration builds. Please note that the standalone designer build is no longer available on the build server.

Sample reports can be found in the source download of SharpDevelop in the folder Samples\SharpDevelopReports.

Upcoming changes before the CTP of SharpDevelop 3.2: iTextSharp will be updated to version 5.0, and we no longer include the source code for it in the repository (only as a zip in the vendor directory, which is not part of the source download).

Next tasks: more samples, more documentation, bug fixing.

IronRuby Integration Update

MattWard — Wed, 30 Dec 2009 14:24:00 GMT

Support for IronRuby in SharpDevelop has moved on since the last alpha release of the IronRuby addin. This addin now ships with SharpDevelop 3.2 which is available to download from the build server. The main new features are support for IronRuby 1.0 RC 1 and the ability to debug IronRuby applications.

New Features

Windows Forms designer support now complete
Converting entire C# and VB.NET projects to IronRuby.
Debugger support for IronRuby applications.
Smart indenting for IronRuby code.
IronRuby 1.0 RC 1 support.

Currently there is no support for IronRuby code completion.

Now we will take a look at some of the new features in more depth.

Running an IronRuby Application

After you create an IronRuby application you can run it immediately without having to edit the project options as you did previously. The project templates have been updated so that everything is ready to go straight away. Simply select Run from the Debug menu to run your application with the IronRuby console.

Debugging an IronRuby Application

In order to get the debugger to work well when debugging an IronRuby application you should change the debugger options. To open the debugger options select Options from the Tools menu, then select the Debugging category. Only the 'Just My Code' feature should be selected and everything else should be unselected, as shown in the screenshot below.

You can set your breakpoints in the normal way either by clicking in the left hand margin of the text editor or by selecting Toggle Breakpoint from the Debug menu.

Selecting Run from the Debug menu will run your IronRuby application under the debugger. Alternatively you can select Run from the Ruby menu which will run the code currently active text editor window. Selecting either of these will run the IronRuby console in debug mode with SharpDevelop's debugger.

Converting a C# or VB.NET Project to IronRuby

To convert a VB.NET or C# project to IronRuby open the project and then select Convert from C# to Ruby or Convert from VB.NET to Ruby from the Project menu.

Extra Ruby Libraries

The IronRuby 1.0 RC 1 download from codeplex includes extra Ruby libraries that are not shipping with SharpDevelop. If you want to use these libraries then download the IronRuby zip file and copy the lib folder to the IronRuby addin folder:

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

The IronRuby console (ir.exe) is configured to look in the lib subfolder by information in the ir.exe.config file:

<options> 
   <set language='Ruby' option='LibraryPaths' value='lib\IronRuby;lib\Ruby\site_ruby\1.8;lib\Ruby\site_ruby;lib\Ruby\1.8'/> 
</options>

If you want to put these Ruby libraries somewhere else then the ir.exe.config file should be modified.

IronRuby Downloads

IronRuby 1.0 RC 1 from Codeplex

What’s New in SharpDevelop Reports 3 Beta

Peter Forstmeier — Mon, 05 Oct 2009 16:19:00 GMT

Features:

The Designer is using the infrastructure from Windows.Forms.Designer
Run Expressions inside a Report; based on the work of Irony and Simpleexpressionevaluator
UnitTests for many (increasing number) of Classes

The Designer in Action:

TextEditor, useful to enter some text and/or expressions:

A very simple report in List layout with PageNumber in the PageFooter section and Aggregate function count() in ReportFooter:

Some more functions:
Line 1 (middle):   nothing to evaluate – (right) concat two fields
Line2 (middle and right): Userfunctions
Line 3 (middle and right) : Globalfunctions
Line 4 :     show parameters inside report, useful for queries
Line 5:     simple calculation
Line 6:     etc, some more functions

The Result:

IronRuby Integration in SharpDevelop 3.1

MattWard — Sun, 04 Oct 2009 12:32:00 GMT

Support for IronRuby 0.9.1 is now available for SharpDevelop 3.1. The IronRuby addin is an early alpha preview release/proof of concept and is not an official part of SharpDevelop 3.1 so it is available as a separate download at the end of this post.

Features

Code folding
Syntax highlighting
File and project templates for Console and Windows Forms applications
IronRuby Console window
Windows Forms designer (limited)
C# and VB.NET code conversion to Ruby (limited)

Please note that the forms designer and code conversion need a lot more work.

Creating a Windows Application

Open up the new project dialog by selecting New then Solution from the File menu. Selecting the Ruby category will show two project templates. One will create a Windows console application and the other will create a Windows Forms application.

To run your application ensure the Program.rb file is in the active text editor window then select Run from the Ruby menu. This will run your code with the IronRuby console (ir.exe). Alternatively you can run the application by selecting Run from the Debug menu but you will first need to configure the project options. Select Project Options from the Project menu to open up the Debug project options.

You will need to add ${ProjectDir} to the command line arguments and working directory as shown above. The -19 command line argument is used to enable Ruby 1.9 support otherwise the IronRuby console will not be able to load any UTF-8 source code files.

Currently you cannot debug your code even if the -D command line argument is specified.

If you are running a windows app and nothing seems to happen then open a command line window and run it from there. This way you should see any errors reported from the IronRuby console.

Designing Windows Forms

The Windows Forms designer is still in its early stages so please be warned that it may break the form's code or worse. The designer code generation is a lot more complete than the designer loader so the designer will most likely fail to load all controls into the designer.

The designer can be opened in the usual way by opening the form in the text editor and selecting the Design tab at the bottom of the text editor. Once open in the designer you can add controls to the form in the usual way from the Tools window. In the screenshot below a label, text box and a button have been added.

Click the Source tab to view the generated code in the InitializeComponents method. Make sure you do this before trying to save the code.

IronRuby Console

To open the IronRuby Console window select Tools, Ruby Console from the View menu.

When you type Ruby code into the IronRuby Console you will get code completion when you press the '.' character.

Code Folding

Code folding allows you to collapse regions of a class.

Code Conversion

To convert VB.NET or C# to Ruby open the file you want to convert and then select Convert code to Ruby from the Tools menu.

The code conversion is limited to classes so it will not convert an arbitary piece of code that is not inside a class. A C# class being converted to Ruby is shown below.

The code conversion is still at an early stage of development so it will fail on complicated classes.

Class View

Classes in the open solution will be displayed in the Class browser (Select Classes from the View menu).

From there you can double click a class or method and the text editor will display the corresponding code.

Installing the IronRuby AddIn

Rename the IronRubyAddIn-0.1.zip file to IronRubyAddIn-0.1.sdaddin.
From the Tools menu select AddIn Manager .
Click the Install AddIn button.
In the Open File Dialog browse to the IronRubyAddIn-0.1.sdaddin file and click the Open button.
Click the Close button.
Restart SharpDevelop.

Ruby Links

Some of the Ruby tutorials and links used whilst creating the IronRuby addin.

Downloads

IronRubyAddIn0.1.zip

IronRubyAddIn0.1-src.zip

IronPython Auto-Indent

MattWard — Wed, 30 Sep 2009 15:36:00 GMT

Python auto-indentation has now been added to SharpDevelop 3.1 in revision 5007. The latest SharpDevelop builds can be downloaded from the build server.

The indentation will be increased after a line ending with the colon character, such as a method declaration. After typing in a pass or return statement the indentation will be decreased on the following line.

IronPython Form Resources

MattWard — Mon, 28 Sep 2009 15:39:00 GMT

Getting an IronPython WinForm to display an icon or image can be done in different ways. Here we will take a look at the following ways to add a background image to the main form of an IronPython WinForms application.

Using the SharpDevelop forms designer.
Loading an image embedded as a resource in a separate assembly.
Loading an image from disk.

Using the SharpDevelop Forms Designer

The SharpDevelop forms designer can be used to add resources to a form in the same way for other languages such as C# or VB.NET. It supports adding local form resources but not project resources currently.

After creating a new IronPython Windows Application, open the MainForm in the designer. In the Properties window select the BackgroundImage property of the MainForm and click the browse button.

Select Local Resource then click the Import button to browse to the image file you are going to use.

Click OK to close the dialog. The background image should then be displayed in the form. If you select Run from the Debug menu your application will be compiled and the main form should be displayed with your image.

Now let us take a look at the code generated for the form.

import System.Drawing 
import System.Windows.Forms 
 
from System.Drawing import * 
from System.Windows.Forms import * 
 
class MainForm(Form): 
 def __init__(self): 
  self.InitializeComponent() 
  
 def InitializeComponent(self): 
  resources = System.Resources.ResourceManager("PythonWinApp.MainForm", System.Reflection.Assembly.GetEntryAssembly()) 
  self.SuspendLayout() 
  #  
  # MainForm 
  #  
  self.BackgroundImage = resources.GetObject("$this.BackgroundImage") 
  self.ClientSize = System.Drawing.Size(284, 264) 
  self.Name = "MainForm" 
  self.ResumeLayout(False)

The generated code for the InitializeComponent method is nearly the same as the code generated by the forms designer when adding a resource to a C# form. The generated C# code is shown below.

  private void InitializeComponent() 
  { 
   System.ComponentModel.ComponentResourceManager resources = new System.ComponentModel.ComponentResourceManager(typeof(MainForm)); 
   this.SuspendLayout(); 
   //  
   // MainForm 
   //  
   this.AutoScaleDimensions = new System.Drawing.SizeF(6F, 13F); 
   this.AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font; 
   this.BackgroundImage = ((System.Drawing.Image)(resources.GetObject("$this.BackgroundImage"))); 
   this.ClientSize = new System.Drawing.Size(284, 264); 
   this.Name = "MainForm"; 
   this.Text = "WinApp"; 
   this.ResumeLayout(false); 
  }

The C# form uses the ComponentResourceManager class and typeof(MainForm) to get access to the embedded resource. The IronPython form uses the ResourceManager class instead. If we try to use a ComponentResourceManager in the IronPython application by replacing the resources line with:

resources = System.ComponentModel.ComponentResourceManager(clr.GetClrType(MainForm))

The application will throw an NotSupportedException when it is run with an error message saying that "The invoked member is not supported in a dynamic assembly.". The line of code that actually causes this error is the resources.GetObject() line. So we cannot read a resource from a dynamic assembly, but even if we could the resources are not actually embedded in the assembly that contains the code for the MainForm. When the IronPython application is compiled two files are generated an executable and a dll. The dll is generated using IronPython's ClrModule.CompileModules which is used to compile all the IronPython code into an assembly. The exe is generated using several Reflection.Emit calls and its only task is to call PythonOps.InitializeModule passing the filename of the generated dll. If you look at the exe using Reflector you can see a PythonMain class with a Main method similar to that shown below.

[STAThread] 
public static int Main() 
{ 
    string[] references = new string[] { "IronPython, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35", 
        "mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089", 
        "System.Data, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089", 
        "System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089", "System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a", 
        "System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089", 
        "System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" }; 
    return PythonOps.InitializeModule(Assembly.LoadFile(Path.GetFullPath("PythonWinApp.dll")), "Program", references); 
}

With Reflector you can also see that the form resources are embedded into the executable and not the dll. So this means our form code needs to load the resources from the executable. This is done in the generated form designer code by passing the entry assembly, which will be the executable containing the resources, to the ResourceManager as shown below.

resources = System.Resources.ResourceManager("PythonWinApp.MainForm", System.Reflection.Assembly.GetEntryAssembly())

The above code will not work if you try to run your application with the IronPython Console (ipy.exe) since the entry assembly will actually be ipy.exe. The following sections will look at using form resources that can be used when running your code with ipy.exe.

Loading an Image from an Assembly

Here we will have two projects, one with the IronPython form and one with the image resource. In the resource project you have a choice of whether you are going to put your image inside a resource file (.resx) or simply add it to the project and set its Build Action to EmbeddedResource. For now let us add the image to a resource file. Add a new resource file and then open it into the editor. Add your image to the resource file by right clicking and selecting Add files...

Finally compile your resource assembly.

From your IronPython WinForms project you can load the image from this resource assembly with code similar to the following:

class MainForm(Form): 
 def __init__(self): 
  self.InitializeComponent() 
  fileName = System.IO.Path.GetFullPath("Resources\\ResourceLibrary.dll") 
  assembly = System.Reflection.Assembly.LoadFile(fileName) 
  resources = System.Resources.ResourceManager("ResourceLibrary.Resources", assembly) 
  self.BackgroundImage = resources.GetObject("SharpDevelop") 
  
 def InitializeComponent(self): 
  pass

The code loads the resource assembly (ResourceLibrary.dll) by assuming it is in the Resources subfolder off the current working directory. The name of the embedded resource and the loaded assembly are then passed to the ResourceManager. Finally the SharpDevelop image is read from the resource manager via the GetObject method. This code will work with both ipy.exe and when the application is compiled but it uses the current working directory is used to determine the location of the resource assembly. An improvement is to use a path relative to the MainForm.py file itself.

class MainForm(Form): 
 def __init__(self): 
  self.InitializeComponent() 
  directoryName = System.IO.Path.GetDirectoryName(__file__) 
  fileName = System.IO.Path.Combine(directoryName, "Resources\ResourceLibrary.dll") 
  assembly = System.Reflection.Assembly.LoadFile(fileName) 
  resources = System.Resources.ResourceManager("ResourceLibrary.Resources", assembly) 
  self.BackgroundImage = resources.GetObject("SharpDevelop") 
  
 def InitializeComponent(self): 
  pass

With this modified code we get the full filename including its path to the MainForm.py file by using the __file__ constant. Then we can get the full path to the resource assembly relative to the MainForm.py file. This code will work with ipy.exe but not if the application is compiled. With the compiled application the __file__ constant returns the name of the file without its extension and without any path information.

Loading an Image from Disk

Here we assume the image (SharpDevelop.png) is in a Resources subfolder relative to the MainForm.py file.

class MainForm(Form): 
 def __init__(self): 
  self.InitializeComponent() 
  directoryName = System.IO.Path.GetDirectoryName(__file__) 
  fileName = System.IO.Path.Combine(directoryName, "Resources\\SharpDevelop.png") 
  self.BackgroundImage = System.Drawing.Bitmap(fileName) 
  
 def InitializeComponent(self): 
  pass

Here the code simply determines the full path to the image and then loads it into a Bitmap. The Bitmap is then used to set the form's background image. Again this code will work with ipy.exe but not if the application is compiled.

Example code for all the ways of using resources in IronPython can be found in the IronPythonFormResourceExamples.zip file.

New debugger features implemented during #d^3

martinkonicek — Thu, 10 Sep 2009 00:46:00 GMT

During SharpDevelop developer days 2009 we implemented new debugger features to appear in SharpDevelop 4:

Debugger tooltips for IEnumerable

The individual items of IEnumerable can be expanded normally.

Text visualizer

There is a new visualizer chooser in debugger tooltips.

For string values, Text and XML visualizers are available. Choosing "Text visualizer" shows a window:

XML visualizer

XML visualizer uses AvalonEdit to display syntax-highlighted xml. Folding (= node expanding/collapsing) and auto indentation will be implemented.

Profiling Unit Tests Made Easy

siegi44 — Wed, 02 Sep 2009 14:20:00 GMT

Although we had basic support for profiling unit tests in the RC1 of SharpDevelop 3, it was very hard to use. The reason for this was that the profiler simply attached itself to the NUnit console runner used by SharpDevelop and recorded all calls, even the initialization of NUnit. This produced a large overhead of data.

In SharpDevelop 3.1 rev. 4863 I changed the data processor a bit. The profiler now displays all unit tests as root nodes in the "Overview" tab and all NUnit initialization calls are removed from the data.

As you can see, it is much easier find the information you need. This also works with multiple tests selected.

Another feature I thought it could be useful for profiling in general is "Find references". Simply right-click on a node in the tree view and select "Find references" from the context menu.

I hope you like the changes and find it useful. If you have any questions or suggestions, please post them here.

API Changes explained: Language Bindings and Project Bindings

siegi44 — Sat, 25 Jul 2009 12:20:00 GMT

Important note: The changes discussed in this post apply only to SharpDevelop 4.0.0.4537 and later revisions.

Why?

As you might have noticed, I am one of the accepted Google Summer of Code 2009 students. While working on my project, the XAML binding, I had the idea of implementing an Outline Pad for XAML. After a short discussion with my mentor, we decided to add a general solution for implementing this functionality for C#, VB .NET, Boo, Windows Forms Designer and the (upcoming) WPF Designer too.

For instance, normal backend bindings like the C#, VB .NET and Boo binding could display a tree of the current document structure with namespaces, classes, member variables, methods properties, etc. This would allow fast physical restructuring of a file. With XAML you could easily move a part of the XAML tree to another location. Same would go for the Windows Forms and WPF Designer.

So each language binding or display binding should be able to tell the outline pad what content it should display to the user. The existing ILanguageBinding only represented a language from the point of view of the project system, there was no support for things like code completion, formatting or highlighting. So I changed the name of the existing ILanguageBinding to "IProjectBinding".

The New Language Binding API

The new ILanguageBinding is not project-based, but file- or, to be more specific, ITextEditor-based. What does this mean? It simply means, that every ITextEditor instance (that is, every file opened by the default text editor in SharpDevelop), gets its own ILanguageBinding instance. Furthermore, if you use the split-view functionality present in SharpDevelop, both views get their own ILanguageBinding instance too. Please keep that in mind, when implementing your own language bindings.

So let's move on the practical part: In fact, the "API" only consists of one interface, plus wrappers for the SharpDevelop addin system, to make it easy for backend binding addins to provide their own language-specific implementation. We will discuss its structure first:

public interface ILanguageBinding
{
        IFormattingStrategy FormattingStrategy {
            get;
        }

        LanguageProperties Properties {
            get;
        }

        void Attach(ITextEditor editor);

        void Detach();
}

It is not very complex, but there are a few things to keep in mind:

Attach is called only once on every ILanguageBinding instance (before any other method calls).

SharpDevelop will never Detach() and re-Attach() a language binding; instead, it will detach the old binding and attach a new instance. A new instance is created in the following situations:

an ITextEditor is created by SharpDevelop,
the filename, of the file being edited, has changed
or the user switches to split-view mode.

You can attach additional functionality like a custom highlighter or an IOutlineContentHost, to provide content displayed in the Outline pad, as mentioned at the beginning.

If you override Attach, you should also override Detach. It is called only once in the life-cycle of an ILanguageBinding instance:

when an ITextEditor is closed (disposed by SharpDevelop),
before a new language binding is attached, after the filename, of the file being edited, has changed. (So SharpDevelop disposes the old one before creating a new one.)
after switching from split-view to normal view mode, to dispose the second view, as it is not needed anymore.

You should detach (and dispose) all services and additional functionality, added by your language binding, from the ITextEditor at this point.

FormattingStrategy should return an instance of the IFormattingStrategy implementation for your language binding.

Properties should return a reference to the LanguageProperties implementation for your language binding.

Example: XamlLanguageBinding

I pasted the Attach and Detach method from the XamlLanguageBinding as a small example. Please note that adding custom syntax highlighting (in this case: XamlColorizer) and additional services, like IOutlineContentHost, requires a reference to the TextView of the AvalonEdit.TextEditor class. So this part can only be implemented for specific text editor controls.

public override void Attach(ITextEditor editor)
{
    base.Attach(editor);

    // try to access the ICSharpCode.AvalonEdit.Rendering.TextView
    // of this ITextEditor
    this.textView = editor.GetService(typeof(TextView)) as TextView;

    // if editor is not an AvalonEdit.TextEditor
    // GetService returns null
    if (textView != null) {
        colorizer = new XamlColorizer(editor, textView);
        // attach the colorizer
        textView.LineTransformers.Add(colorizer);
        // add the XamlOutlineContentHost, which manages the tree view
        textView.Services.AddService(typeof(IOutlineContentHost), new XamlOutlineContentHost(editor));
    }
}

public override void Detach()
{
    base.Detach();

    // if we added something before
    if (textView != null && colorizer != null) {
        // remove and dispose everything we added
        textView.LineTransformers.Remove(colorizer);
        textView.Services.RemoveService(typeof(IOutlineContentHost));
        colorizer.Dispose();
    }
}

Nice, But How Do I Register My Language Binding With SharpDevelop?

Similar to all other parts of SharpDevelop, just add it to the addin path /SharpDevelop/Workbench/LanguageBindings like this:

short explanation:

id: The name of the LanguageBinding, must be unique, preferably the same as your project binding or code completion binding.

class: The fully-qualified name of your language binding class.

extensions: A semicolon-separated list of file extensions, that are handled by your language binding. Please note that multiple LanguageBindings can handle a file extension. But only the first non-null FormattingStrategy is used or only the first non-null LanguageProperties instance is used. You can control the order of the language bindings using the insertbefore and insertafter attributes.

Important: In the past you were able to register a formatting strategy by adding it to /AddIns/DefaultTextEditor/Formatter/, this was removed. Now the IFormattingStrategy gets set by overriding the FormattingStrategy property in the Language Binding implementation.

How To Access The Features From AddIns?

When dealing with text displayed inside a SharpDevelop text editor, the easiest way to do this is to use the ITextEditor interface. The active language binding can be accessed by using ITextEditor.Language property.

Project Bindings

I have not done any changes to the project binding API, except renaming everything. Project bindings are responsible for project management (reading project files, compilation management, etc.). XAML does not need its own project format (there is no .xamlproj ;-)), so I cannot provide an example and explain it to you, please take a look at existing project bindings such as CSharpProjectBinding, VBNetProjectBinding or BooProjectBinding.

Conclusion

I think the language bindings make it easier to extend ITextEditor with language specific features and also allow other AddIns to access these features. In my next post I will explain my work on the XAML binding more in detail and guide you through the features I implemented.

If you have any questions concerning language bindings and these changes, please feel free to ask.

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