So here comes yet another Microsoft blogger J My name is Mikhail Arkhipov and I am development lead in the Web.NET tools team. My team owns Source view functionality of the Visual Studio HTML Editor and base editing in Design view. This includes colorization, markup intellisense and statement completion, client and server script intellisense, inline style intellisense, markup and style validation, view switching, HTML formatting preservation, pretty formatting, Tools | Options pages, validation schemas, CSS editing and so on. I have been with the team pretty much all the time since I joined Visual Interdev 6.0 team back in 1997.
Kevin Pilch-Bisson blogged about the server code intellisense and how does the feature actually work. I won’t disagree that it is probably one of the most complex pieces of code that we have in Whidbey HTML Editor. On top of that interesting architectural challenges most of the processing is done asynchronously for performance reasons. You may notice it when you open a web form in VS and immediately start typing code in a server script block: you may not get intellisense dropdown when you type one of the intellisense triggers such as dot or space. This is because code is still being generated for the web form. After ASP.NET runtime completes code generation, the code will be compiled by VB, C#, VJ# or other compatible compiler and only then the language module will provide code intellisense (not the HTML editor itself). The scheme may seem a bit convoluted, but payoff is that a) the process is identical to what happens on a real ASP.NET Web server so you get early error detection and b) almost all features of the language are supported in the script or render blocks. For instance, you can observe VB error correction in action as well as C# code refactoring.
Quite a few people asked why did we bother to implement code intellisense in server script blocks, render blocks and inline expressions. Why not keep code separation since it is 'cleaner'. Well, first a lot of customers asked for the feature. Consider that Visual Interdev 6.0 (as well as VS.NET 2003/2003) supported intellisense in client blocks and in server script blocks in classic ASP pages since '98. Second, I don't think we are in business of telling people how they should be writing their code. If they chose code separation, good. If they just need to write a few lines of code, putting code in a separate file may be too much hassle. Consider this: if you are writing 20 lines program in C/C++, do you always bother to create a separate header file or you simply place declarations in the beginning of the cpp file? Both single-file and code separation models are useful. Code behind is not dropped, it is replaced by a better (or so we think :-)) model which does require separate code file, but does not require double declaration of controls. It is enough to add control to the page, you don't have to write another declaration in the CS or VB file.
However, your feedback or flame is appreciated :-)