SharpDevelop Community

Get your problems solved!
Welcome to SharpDevelop Community Sign in | Join | Help
in Search

Siegfried Pammer

March 2012 - Posts

  • SharpDevelop 4.2: Debugging C# 5 async methods

    As Chris already announced in a previous blog post, SharpDevelop 4.2 and later will support targeting .NET 4.5. One of the interesting new features in .NET 4.5/C# 5 is async. If you have already tried debugging an async method, you will have noticed, that SharpDevelop's debugger is unable to evaluate any local variables.

    In short this is because async is - similar to iterator blocks (yield return) - implemented as state machine in a compiler-generated struct. So the debugger has to find the correct location (i.e. compiler-generated code) where all the local variable's values are stored.

    In the most recent nightly builds of SharpDevelop 4.2 Beta 2 (starting with build, we've applied the necessary plumbing to make it work. But see for yourself:

  • Project Behaviors - Extensibility in the Project System

    With the upcoming release of SharpDevelop 4.2, you get support for ASP.NET MVC projects based on IIS and IIS Express. We also want to give you debugging support. However this required some changes in our project system, because web development usually involves a web server and the IDE attaches its debugger to the web server when the project is run. This is fundamentally different from normal projects.

    Another point is that projects consist of different "project types". For example a WPF project is usually C# + WPF or VB + WPF. An ASP.NET MVC project even consists of three parts: C#, web and MVC.

    The Solution

    Visual Studio solves this by inserting different project type GUIDs into the project file. Depending on the GUIDs it opens the project file with a different handler. While this approach is a good idea, its implementation in Visual Studio requires the project file to be read two times. First it is opened and scanned for the project type GUIDs and then opened again with an XML parser and finally loaded completely. (Source: [1])

    So each project type can have various sub-types defined by GUIDs. Scala implements such type compositions through mixins. In fact we would need something like this (pseudo syntax):

    var mvcProject = new CSharpProject() with WebSupport(), MVCSupport();

    Of course this is not possible in C#. So we borrowed this concept and implemented it through project behavior chains, as described below:

    In SharpDevelop we first load the project file into an IProject container. Which container to use is defined by the file extension. So there is a CSharpProject (.csproj), VBProject (.vbproj) or FSharpProject (.fsproj) and so on. After the container is initialized and the file has been loaded, we look for the project type GUIDs and then load all the project behaviors that apply to the different GUIDs.

    A project behavior is a set of virtual methods that can be overridden to alter certain behavior of the project (for example Start, which starts the project with or without debugger). Project behaviors are chained together in the order they appear in the AddIn Tree. If a project behavior does not want to handle a certain call, it is passed onto the next project behavior. At the end of the chain there is the default project behavior which implements the defaults for each project type.

    This change allows AddIns to implement different handlers for different projects without modifying the whole project system and/or the debugger.



Powered by Community Server (Commercial Edition), by Telligent Systems
Don't contact us via this ( email address.