Server code intellisense in Web Forms (new blogger)

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 🙂

Comments (6)
  1. Uwe says:

    So probably you can dispatch my request for a possible small feature 🙂

    When switching word-wrap mode on (i.e. long lines wrap at the right side of the edit window), I would LOVE to have a more intelligent wrapping as e.g. editor does:

    The wrapped lines are indented as much as the original line, so you still have a useful indention in place, even when in wordwrap mode.

  2. Anon says:

    Cant wait for whidbey, hope you guys sorted out a lot of the designer features, whilst better that frontpage, the last version of studio and the one before that, its still blows.

    Straight to HTML view please. Now thats better than ever but when I drag user controls on the page for this it isnt going to be an A link now is it ?

    But keep up the good work and keep improving that thing.

    (Visual inheritance cant wait cant wait, think you can release whidbey with SP3 attached so I can get it in prodction straight away 😉 )

  3. Welcome to the club 🙂

  4. Mikhail Arkhipov (MSFT) says:

    Uwe, I will pass your request to the VS IDE team. VS text editor is a core shared component. It is interesting option, however since it seems to require addition of physical whitespace. Or do you want ‘virtual’ indent when no spaces or tabs are added?

    As for Designer, it is better than before since insted of using plain vanilla mshtml.dll (IE6 core engine), we forked its source code and improved editing in many areas. We also removed browsing features since they are not used in editing mode anyway.

    No, controls won’t be links, drag-drop from toolbox in Source view (it is Source view again, as in VID6) is fully supported 🙂

  5. Hi Mikhail

    I understand that code separation is based now on partial classes. Another thing is that the code is not precompiled into dlls. I know that dlls in bin folder in vs2003 don’t give you extra perfomance but one of the benefits of these dlls is deployment. You can send your customer one dll, obfuscate it, whatever. Or you can upload dll + as*x only to your web server. What can we do now with all this ? Upload all changed code beside files (as*x.cs) ? Or something else ?

  6. Mikhail Arkhipov (MSFT) says:

    By default we follow FrontPage model (i.e. publish source files). However, you do can get web site precompiled into a single assembly if you use Web | Build Web Site. I am not sure which build the command first appears in, but you should be able to use it in whatever we will distribute on PDC in San Diego.

Comments are closed.

Skip to main content