MJHutchinson.com Michael Hutchinson's Home on the Web

I'm very pleased that Visual Web Developer Express 2008 has now gained Web Application project support in Service Pack 1. This means that MonoDevelop users will be able to share ASP.NET projects with VWD developers.

For those of you who haven't heard the story behind this, Web Application projects are support for developing your ASP.NET site as a project. Although VS.NET and VS.NET 2003 did this, it was removed in VS 2005 in favour of "Web Sites", which consider a web site to be a directory. As I'm sure you can guess, the latter system is convenient for editing websites in-place — and they even had FTP support for this purpose — but in my opinion it's a poor system for well-structured development. Clearly other people thought so, because Web Applications were added back to Visual Studio 2005 as an optional addon, and included in VS 2008. Finally in VS2008 SP1, it's reached the free version. The reason for this is quite simple; it's a necessity for proper ASP.NET MVC development.

At the moment, MD trunk does a passable job of opening projects from VWD 2008 SP1, but building and deployment isn't so great, because when I originally implemented these, I had to work around some of the limitations in MD's build and deployment system. These workarounds aren't quite compatible with the MSBuild projects from VS. I'm currently trying to make this seamless by tweaking our MSBuild loader to more closely match the MSBuild build targets and file copy semantics, making the MD deployment system slightly more generic, and implementing the build and deployment targets "correctly" for ASP.NET projects.

Support for importing Web Sites may come later, but for now, it's good to see that we can now interoperate with Microsoft's free ASP.NET development tool.

When I initially wrote the ASP.NET code completion, I added support for completing attribute values for enums and bools. More generalised completion using TypeConverter.GetStandardValues isn't so easy, since I don't want to load arbitrary types into the MD process, so I skipped this for now. However, I did special-case System.Drawing.Color, since it's used a lot.

This morning, on a suggestion from Aaron, I tweaked it to generate custom icons for each colour:

In other news, I landed the new ASP.NET completion parser, which is much more robust, and is also able to generate a tree, so it will soon replace the DOM parser too. The new design also means I'll be able to unify it with the XML and Moonlight (XAML) addins.

I recently returned from a family holiday in Maine, and will post photos when I got them sorted out and uploaded to Flickr.

I have been making good progress on ASP.NET source editing, as evidenced by the following screenshot:

Yes, that is code folding, error underlining, and a path bar. However, the document outline pad isn't hooked up yet for ASP.NET[Update 2008/5/2: outlining implemented].

I've been getting a lot of practical experience with handwritten parsers recently. The ASP.NET addin has two parsers; the first builds a full DOM, and the second provides document path information very efficiently.

The path parser is designed to accept individual characters as the user types them, instantly providing information about the current context. This is very useful for code completion and smart indentation, and is obviously near-ideal for the path bar too. It's about as robust as I can make it, recovering effectively from most errors. However, I wrote a state-based XML parser where each state was a path object, which has proved rather unwieldy to extend cleanly for ASP.NET, so this may well get replaced soon.

The DOM parser was originally written for the CodeBehind field generation. It's based on Mono's ASP.NET tokeniser, which makes it rather fragile; when it encounters a syntax error, it dies. For its original use, this is sensible behaviour, but for a text editor it needs to be much more robust, so I intend to modify the path parser to build this DOM instead.

I plan to roll a lot of this back into the XML addin, which will provide a solid base for XAML completion for Moonlight apps.

Unfortunately, I have blogged very little in recent months. I shall follow this post with a summary of the things I've skipped blogging, but for now, I offer up the following tantalising screenshot by way of apology:

Now that MonoDevelop 1.0 is on the verge of shipping, I have begun to plan the parser that will underpin the ASP.NET code completion and visual designer in upcoming versions of MonoDevelop. During a discussion with our ASP.NET expert Marek, I found out about an obscure ASP.NET feature that currently causes problems for Mono's ASP.NET parser, and is entirely counterintuitive to anyone with any XML knowledge.

I've been thinking again about the compilation and deployment models used in MonoDevelop for ASP.NET code, and it isn't easy to come up with a good solution. I've written a discussion of the various possibilities and how they mesh with MonoDevelop and the Visual Studio way of doing things.

Here's a shiny screenshot of AspNetEdit embedded in MonoDevelop. The code's not really ready for use yet, but I'm making good progress. It's been complicated by the fact that I'm running AspNetEdit and its property grid in a separate process so that the ASP.NET controls are isolated from the MD process.

I've just committed a patch to MonoDevelop to enable the use of the AspNetAddIn that I committed a couple of days ago. It's not close to fully-featured yet, but I'm pleased because it now enables a basic ASP.NET workflow. One can create an ASP.NET project and various ASP.NET files, then build and run it. The XSP server will be launched, followed by a web browser, and the compiled page can be seen in all its glory. In theory all .NET languages supported by MonoDevelop can be used, though I have only been able to test C# so far.

One of the most difficult things about developing ASP.NET project support for MonoDevelop is deciding upon a project model to use. Microsoft appears to have this problem too; while having used a "Web Application" (WA) model for VS.NET 2003, and then switched to a "Web Site" (WS) model for Visual Studio 2005, they have just recently brought back the Web Application model for VS2005. Both are sensible and straightforward ways of developing an ASP.NET site, and developers migrating from Windows are familiar with them, so it was clearly a good idea to use them as a starting point when planning how to implement the project support in MonoDevelop.

I have been accepted into Google's Summer of Code 2006!

This time round I will be adding an ASP.NET Project type to MonoDevelop, with a proper compilation, preview and deployment workflow. I will then be able to host AspNetEdit in MonoDevelop as its graphical designer for ASP.NET.

I will be posting regular updates on my blog. Right now I'm trying to decide which of ASP.NET's compilations models to support, and how they can integrate with the project model. I'm also familiarising myself with MonoDevelop's extension model.

Apologies for the delay in this announcement, but I only finished exams last Thursday.