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.
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: )
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.