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

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

1. Rename the IronRubyAddIn-0.1.zip file to IronRubyAddIn-0.1.sdaddin.
2. From the Tools menu select AddIn Manager .

   

3. Click the Install AddIn button.

   

4. In the Open File Dialog browse to the IronRubyAddIn-0.1.sdaddin file and click the Open button.

   

5. Click the Close button.
6. Restart SharpDevelop.

Ruby Links

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

1. Ruby documentation.
2. Book of Ruby by Huw Collingbourne.
3. IronRuby homepage.

Downloads

IronRubyAddIn0.1.zip

IronRubyAddIn0.1-src.zip

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.

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.

1. Using the SharpDevelop forms designer.
2. Loading an image embedded as a resource in a separate assembly.
3. 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.

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.

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.

1. No support for project or local form resources.
2. No support for icons.
3. Incomplete support for ToolStripItems and menu strips.
4. Incomplete support for ListViewItems.
5. No support for TreeViewItems.
6. Incomplete support for non-visual components (e.g. Timers).
7. 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.

1. The form's code is parsed and an IronPython AST (PythonAst object) is created.
2. The AST is then visited and each control is added to the forms designer and the control's properties are set.
3. 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.

1. The form is obtained from the forms designer.
2. 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.
3. After all the child components are added the code for the form is generated.
4. Finally the generated code is inserted into the text editor inside the InitializeComponent method, replacing any existing code.

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:

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

SharpDevelop 3.1 now supports NUnit 2.5.

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

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.

1. 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.

2. NUnit.Framework.SyntaxHelpers namespace no longer exists.

   All classes that were in this namespace have been moved to the NUnit.Framework namespace.

3. 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));

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

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.

• SharpDevelop 3.0
• Python 2.5

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.

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.

1. Download the wix3-binaries.zip file from SourceForge.
2. In SharpDevelop's WiX addin folder SharpDevelop\2.2\AddIns\AddIns\BackendBindings\WixBinding rename the original WixBinding.addin file to WixBinding.addin-bak.
3. Copy the contents of the bin folder in the Wix3Binding.zip file to SharpDevelop\2.2\AddIns\AddIns\BackendBindings\Wix3Binding.
4. 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.
5. Rename the folder SharpDevelop\2.2\Tools\Wix to SharpDevelop\2.2\Tools\Wix-bak
6. Copy the contents of the wix3-binaries.zip file to the SharpDevelop\2.2\Tools\Wix folder.
7. Restart SharpDevelop.

Updating to Newer WiX Versions

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

Compiling the Source Code

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

Download Wix3Binding.zip

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.

Support for IronPython 2.0 Beta 4 is now available with SharpDevelop 3.

Missing Features

Some of the features have been disabled compared to the IronPython integration in SharpDevelop 2.

• Forms designer
• C# and VB.NET code conversion to Python

Both of the above features involve converting code to and from a Code DOM. Support for the Code DOM is reduced in IronPython 2 so the above features have been temporarily disabled.

Compiling

IronPython 2.0 beta 4 re-introduced support for compiling python code to a .NET executable or dll and so SharpDevelop supports this. There is however one limitation. The working folder needs to be set to the folder containing the compiled dll or executable otherwise it will not be able to locate any local assembly references that are not in the GAC, for example IronPython.dll.

IronPython Console

There's now an IronPython console which can be used to type in IronPython expressions and have them evaluated interactively. It is currently missing code completion which will be implemented shortly. From the View menu select Tools and then Python Console.

SharpDevelop 3 supports attaching the debugger to a running process.

From the Debug menu select Attach to Process.

The Attach to Process dialog will show the managed processes by default. Select the process and then either double click or click the Attach button to attach to the process.

When you have finished debugging you can detach from the process by selecting Detach from the Debug menu.

SharpDevelop 3.0 now supports WiX 3.0.

There are some changes to how things work compared to the WiX integration in SharpDevelop 2. The differences will be covered in the following sections.

WiX Project Templates

There are some new WiX project templates available. A basic empty project template and a template for each of the standard WiX UI library dialog sequences.

Adding WiX Extensions

WiX extensions are now displayed in the project browser instead of in the project options. They can be added by right clicking the WiX Extensions folder and selecting Add WiX Extension.

.

Project Options

The Library and Linking tabs have been removed from the project options since the WiX extensions can now be added from the project browser.

The Compiling tab has some new options as shown below.

The WiX Variables field can be used to override the standard WiX UI library settings. In the screenshot above the standard licence agreement and dialog background bitmap are being replaced with new ones.

The Suppress ICEs field is used to stop WiX from showing errors or warnings for particular Internal Consistency Evaluators (ICEs). After building your installer WiX now validates it against a standard set of rules which saves you from having to use another validation tool such as Orca.

Localized string files are no longer specified in the Application's tab. Instead add the file to the project and change its Build action to Embedded Resource.

Other Editors

If you want integration with Visual Studio 2005 or 2008 then please check out Justin Rockwood's Votive.

Rob Mensching has a list of WiX editors, including commerical ones, on his blog.

It also looks like a future version of Visual Studio will ship with WiX.

There have been some fairly large code changes on moving from SharpDevelop 2.2 to 3.0 and addins written for 2.2 are unlikely to work without some modification. We will look at the changes in the core parts of SharpDevelop and then look at one way to do the porting.

Not all the differences are covered in the next section just those types and methods that are likely to have been used by an addin.

ICSharpCode.Core

NRefactory

ICSharpCode.SharpDevelop.Dom

    IClass type = callingClass.DeclaringType; 
    while (type != null) { 
      ... 
      type = type.DeclaringType; 
    } 

ICSharpCode.SharpDevelop.Widgets

ICSharpCode.SharpDevelop

void Deselected()
void Deselecting()
void Selected()
void SwitchedTo()

ICSharpCode.TextEditor

How to Port

This section looks at one way to port an addin. This is the way that the IronPython addin was ported from SharpDevelop 2.2 to SharpDevelop 3.

Download the source code for SharpDevelop 3.0 and 2.2.

Copy the source code of your addin to a folder inside SharpDevelop 3.0.

Run three copies of SharpDevelop, one to view SharpDevelop 2.2's source, one to view SharpDevelop 3.0's source, one with your addin. In the other copies of SharpDevelop you should open SharpDevelop.sln for 2.2 and 3.0. This will allow you to quickly search for SharpDevelop classes when you find your addin code will not compile.

Compile your code and fix the code or comment it out as you try to work out what is wrong.

You do not have to convert the project to use .NET 3.5. SharpDevelop itself uses it, but some of the addins do not. With the IronPython addin I needed to change it to use .NET 3.5 since there were some assembly conflicts between what SharpDevelop was using and what the addin was using. Obviously changing to use .NET 3.5 will allow you to use any new features of this framework.

.NET Framework Differences

One change in .NET 3.5 caused me a few problems when porting the IronPython addin. This was a change in MSBuild.

After finally getting the IronPython addin to compile with the modified SharpDevelop 3 assemblies there was an assembly conflict for MSBuild. The ICSharpCode.SharpDevelop assembly now uses MSBuild 3.5 assemblies whilst the IronPython build task project and test project were using MSBuild 2.0. This was fixed by converting these two projects so they use the .NET Framework 3.5. This can be done by opening the project's properties, selecting the Compiling tab, then clicking the Convert Project to C# 3.0 button. In the dialog that opens we select the "Change target framework to .NET 3.5" and click the OK button. After making this change the addin compiled and worked however all the unit tests for the IronPython build tasks were failing with the error:

System.ArrayTypeMismatchException : Attempted to access an element as a type incompatible with the array.

The test code that was failing:

PythonCompilerTask compiler = new PythonCompilerTask(); 
TaskItem sourceTaskItem = new TaskItem("test.py"); 
compiler.Sources = new ITaskItem[] {sourceTaskItem}; 

The last line was failing when the unit test was run. The TaskItem type implements the ITaskItem interface so the code should have worked. The reason for this error is that both the build task and build task tests project were referencing the MSBuild libraries just using the reference name.

    <Reference Include="Microsoft.Build.Framework" /> 
    <Reference Include="Microsoft.Build.Tasks" /> 
    <Reference Include="Microsoft.Build.Utilities" /> 

Running MSBuild from the command line the actual assemblies being used were a mix of 3.5 and 2.0 versions.

"Python.Build.Tasks.csproj": 
/reference:"C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\Microsoft.Build.Framework.dll"  
/reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Build.Tasks.dll  
/reference:C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Microsoft.Build.Utilities.dll  

Printing out the code base of the TaskItem and ITaskItem types whilst running the unit tests showed that the TaskItem was being taken from Microsoft.Build.Utilities assembly version 2.0 and the ITaskItem was being taken the Microsoft.Build.Framework 3.5 assembly. The TaskItem we actually needed was in the new Microsoft.Build.Utilities assembly version 3.5. Changing the project references so they used this new 3.5 assembly fixed the problem.