One of the big changes we have made in Whidbey is how webs are compiled in the ide. In 7.0 we had a funky model by which the code for the page was compiled by VS, but the aspx was converted to code and compiled on the server inheriting from the assembly produced by VS. This was good in that you got errors on the client, but as all the pages were compiled into a single unit, it caused problems for teams. So for whidbey we took a step back, looked at the problem and have moved to a model where all the content is compiled on the server.
The problem is that users are used to getting all the errors in the IDE. So for the beta we are implemting a “validate web” feature as part of the IDE. What this does is to run the web through a version of the asp.net runtime we have on the client. The best way to replicate what is done on the server, is well, to do what is done on the server. So unlike client projects where the VB/C# lanaguage service is responsible for the compilation, its done in a somewhat more convoluted manner. We ask asp.net to compile the site, it then does the dependency detection, reads the config files, invokes the compiler etc. From this we get back a bunch of errors. In fact, we have a better experience than 7.0 as we also get the errors from the generation of code from the aspx files.
The problem is routing the errors to the right place. We own the editor for HTML, but use langauge services for editing the inline code blocks. We don't own the editors for code beside cases. Compounding the problem is that we need to create a compiler project for each page as they are seperate compile units, the compiler projects are used to give intellisense, and the other rich code editing features. They are only created when they are needed. We need to pass the errors to C# so that they can show them, and squiggle the file, but hide them when VB is live as it does background compilation. So today we had the task of working out how to route the errors to the right places, holding onto them when the files are closed, passing them in when the files are opened, and reclaiming them again if the files are closed.
The last debate, is what to call the feature.Sometimes it seems that designing it is simpler than naming it. Suggestions are: