C# and ASP.net Whidbey

It’s been a while, but now that ZBB is over, and I’ve got a little bit of time, I thought I would write a little about what has been occupying so much of my time lately.


C# and ASP.net Whidbey


One of the things I’ve been working on a lot lately is the interaction between C# and ASP.net for Whidbey, so I thought I would write a little bit about what’s going on in that space.


What’s new?


One of the major differences (at least as far as it’s impact on me goes 🙂 is that in Whidbey, you will be able to create inline blocks of server executed script, just like in the old days of ASP.  Well not quite, because in ASP.net Whidbey, you will also get support from the individual language of your script block.  This means that colorization, intellisense, and all of those other language specific features should also work in inline script.


What does it look like?


Let’s say you create a web form with a simple button on it.  The code for the page might look something like this:


<%@ Page Language="C#" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">


<script runat="server">

    uint _numClicks = 0;


    void Button1_Click(object sender, EventArgs e)



        this.Button1.Text = this._numClicks.ToString();




<html xmlns="http://www.w3.org/1999/xhtml" >

<head runat="server">

    <title>Untitled Page</title>



    <form id="form1" runat="server">


        <asp:Button ID="Button1" Runat="server" Text="Button" OnClick="Button1_Click" />







How does it work?


What happens behind the scenes is that ASP.net generates a complete class which you as the user never see.  The C# language service however, sees both of these two things: The actual default.aspx file (what we call the primary buffer), and the C# class containing the inline as well as some other stuff to pull it all together.


This makes it a little difficult for the language service team, because whenever we look at a position in the file, we need to think about which file we’re looking at: it could be either the primary or the secondary buffer depending on what interface we’re talking through.  Generally, if we’re talking to either ASP.net team, or the core editor, we need to use primary buffer co-ordinates, but if we’re talking to the C# compiler we need to use secondary buffer co-ordinates.


We’ve pretty much adopted the rule that whenever we talk to the core team or the asp.net team, we’ll translate to/from primary buffer co-ordinates, but the rest of the time we’ll use secondary buffer co-ordinates throughout the language service and compiler.  This has been the source of many bugs in our ASP.net integration, because throughout the 7.0 and 7.1 (or RTM and Everett as we call them), cycles, we had an implicit assumption that the two sets of co-ordinate systems would be identical.  Thus most of the bugs in C# and ASP.net integration have come from places where we missed the fact that we were interfacing with another component.


Project system issues


Another interesting area when it comes to C# and ASP.net integration is how we interact with the project system.  Within the ASP.net world, each individual web form looks to the language service like a separate project.  The reason for this is that it’s not possible to reference code from a different page, and the only way to enforce this in the C# compiler is to have them generate different assemblies.  The only way to get them to generate different assemblies is to use different projects.  This isn’t really a big deal; it just means that opening a web form in the editor is a little bit more expensive than opening a normal C# file in the editor. 


What is interesting is that the project system only tells the language service and the compiler about a page when the page is open.  There are good reasons for this.  Imagine you are working against a remote web server, and the site you are working on contains hundreds of pages.  You don’t want VS to have to hit the webserver to retrieve every page when you open the solution.  Instead, VS hits the server only on demand, when you actually try to open the page.


“So what?” You might ask.  “How will this affect me?”


Well, this affects quite a number of C# Intellisense features, specifically, those that deal with finding things in code.  The types of things I’m talking about are the new “Find all references” command, and the new Refactorings.  The basic problem is that if a page is closed, we have no idea that it exists, so we can’t look for references to things in it.


Let’s take an example.  Imagine you have a class in your Code Directory (the shared repository all pages can access), and you have a reference to it in a bunch of web pages.  You decide that you don’t really like the name of the class so you decide to rename it.  You can use C#’s handy new Refactor->Rename command to do it.  The problem is that if all of the pages that reference it are not open, we don’t know they exist, so we don’t look for references in them, and they don’t get updated.  This isn’t a problem for refactorings of things defined in a web form, since they can’t be shared with other pages, but it is a problem for things defined in the Code directory.

Comments (35)
  1. Come on, I don’t want to code like the old asp – all the things inline. It’s insane, and you folks were talking about codebehind feature a lot before asp.net 1.0 and 1.1. and its benefits. So now you are taking your word back ? Listen, I just don’t want to code inline I want back codebehind feature of asp.net.

  2. Mikhail Arkhipov (MSFT) says:

    Unfortunately, a lot of people do. So here you go :-). However, code separation is still there and it is default.

  3. Mikhail:

    Do what ? I played a little bit with technical preview, and I understand that default is inline coding for asp.net. May be I’m wrong ?

    As far as I see there are lots of changes, but very little info about it over the net. There is much more info about longhorn instead.

  4. scottgu says:

    Code behind is still the default way to write ASP.NET Pages in Whidbey. But developers now have the option to choose single-file if they want to.

  5. scottgu:

    Are you sure ?

    Have you seen technical preview ?

    Some official document link that proves this ?

  6. Mikhail Arkhipov (MSFT) says:

    Scott definitely has seen it. He is ASP.NET product unit manager :-). I am dev lead in the Web Tools team. Yes, code separation is default. It is available in tech preview as well. I believe in earlier builds there were two icons in the New Web Form dialog: with and without code separation. Now there is a single icon and a "Place code in a separate file" checkbox at the bottom of the dialog which is ON by default.

  7. Mikhail Arkhipov (MSFT) says:

    Official link

    <a href="http://msdn.microsoft.com/asp.net/whidbey/default.aspx?pull=/library/en-us/dnaspp/html/codecompilation.asp">New Code Compilation Features in ASP.NET Whidbey</a>

    Scott’s <a href="http://weblogs.asp.net/scottgu">Blog</a&gt;

  8. Guys says:

    The consequence of that will be more massy code written by not experience developer

    This is an open door for mistakes for lots of developers that still did not succeed to do their steps into OO.

    Now they will have another, simple and easy to use option to spread their code – so without experience developer to guide them they will choose as default the simple option.

    BTY – what is the advantages to enable inline code (I have some ideas but I’m not sure)?

  9. Thanks for that entry, it’s always interesting to hear about these little snippets of information from within the production teams!

  10. To Mikhail Arkhipov:

    Sorry, man – I have this checkbox OFF by default in my technical preview: I’m in front of computer right now :).

    How could I figure out that you dev lead and scottgu is ASP.NET product unit manager, do you have a blog ? Scott’s blog was not updated from december.

    The article also does not speaks about this but about new compile model. It’s also very single-sided. The bin directory had lots of disadvantages and the other approach has only advantages.

    The inline feature would definitely encourige developers write ugly code that is difficult to maintain, imho

  11. Paul Bartrum says:

    I like the ability to code inline. It reduces the number of files in my solution by (almost) half. It’s more intuitive (1 file = 1 page). Provided the editing experience is as good as with code-behind (I’ve tried the whidbey preview and it’s very close), I’ll definately be using it.

  12. Paul:

    >> It’s more intuitive (1 file =

    >> page).

    You are wrong, more intuitive is code-separation. Ever used user controls/server controls ? Hey, it increases the number of files in your solution. 1 page = many files. And man according to you it is more intuitive to put business logic inside this file. 1 file = 1 page ??

  13. C# and ASP.net Whidbey

  14. RichB says:

    If I work on a big project I use Code Behind. But if I’m just hacking up a 1-page site to show something like current build metrics – then I generally use a single ASP.Net page + <@Page src="…"> style backing class.

    I just find it simpler to hack together something like this.

  15. I was really disappointed with the new system too :(. I *love* the 7.1 style and was more than happy to say goodbye to the hackish ASP/PHP/etc. style.

    I really don’t like having the "Code" directory and all that. The March CTP is rather broken so I can’t tell what the actual intent is, but I’m really afraid that it’s not going to be usable in the way I’ve been using ASP.NET.

    I guess there were too many customers who think that HTML is a programming language :).

  16. Quite a few of our customers believe that HTML is a programming language, and we want to respect that. Visual Studio is used by a very wide variety of customers, and that is why there are options to do these things.

    Remember that even if the default is not something that you like, it is only a default. Defaults will always be driven by what the majority want, not what we think people should do. Most people do not like tools forcing the "right" way to them.

  17. Ben:

    You completely miss the point. You can write html in both ways.

    Concerning "default": remember, before .net 1.0 asp people wrote all their code inline (html together with server side), but nevertheless Microsoft came out with completely different model as the default way to write asp.net code in visual studio.

    And the inventions and develoment is never driven by majority because majority just knows nothing about new things that belong to the future.

  18. BTW, through this thread I’ve seen several times people speak about the "majority", many customers that want this way or that way. Hey be more specific, give some names, links, discussions. As far as I can see among people that are playing with TP, I can not say most of them don’t like it or not, it is early enough, but the definite feeling is that MS takes its word back concernig ideology of development.

  19. Sorry, I was just referring to the code beside versus code behind argument.

    The point I am trying to make is that in VS7.1 the support for code beside is not as good as it is in whidbey. In whidbey we are trying to make sure that both approaches work equally well, and letting the user choose which one they want. In VS7.1 we only offered templates for code behind, which kind of forced the hand for some people.

    There is a difference between editor settings and what the platform and editor support. Using code behind or code beside is just a setting in whidbey – you are not forced to do anything.

    Are you advocating removing code beside support completely? Or just removing code beside templates? I am unsure about what change you want in the product (if any).

  20. Yes, I’m advocating removing code beside support completely, simple as that.

    This blog and your blog are .text driven. And many others. If you’ve seen its sources there are many places where many user controls use one single code behind file for them.

    At least don’t make code-beside be default as it is now in technical preview. Now the realization is webmatrix style and I don’t like that.

    Suppose I don’t write application from scratch but come to some company to finish some app. I come and see that it is written code beside. What should I do ? Get some tool to convert it back ?

  21. Mikhail Arkhipov (MSFT) says:

    Anatoly – the short answer is ‘it depends’ :-). If I write 30 lines C/C++ program, I probably won’t bother to create separate header file. I’ll just declare everything in a single file. However, if I am going to write 10000 lines app, I definitely will have separate header files.

    Same for code inline. It is not different from client script, btw. If you have tons of script, you are probably using <script src="foo.js"> or some sort of include. However, if all you have is couple of onclick handlers code separation just adds overhead.

    So long version (sort of): tool developers cater to users. We are not in position of requiring certain code writing style. We do give user an option to have code in a separate file, but if he or she does not want it – fine, we will handle code inline too. We are not advocating this or that style. Customer will make her choice. We are just making software and would like to sell more copies 🙂

  22. I think code beside is fine, and will help people (and understand the business reasons for changing VS.NET around).

    What I want is the old 7.x style of compiling all my pages and having ASP.NET subclass them at runtime (no partial classes). This way, I get compiler checking before deployment. As well, the content is separate and can be replaced separately from the code, and no code needs to be on the server.

    I have one client, where I deliver just the DLL and a sample ASPX. He then goes and does his HTML stuff with the page. He doesn’t have the source code. Can I still do this with Whidbey? More importantly, will VS.NET still make it easy to do?

  23. Mikhail Arkhipov (MSFT) says:

    There is new Build Web Site command that compiles all pages. I guess this is what you want.

  24. Jiho Han says:

    Interesting. I’ve heard so much about the new "Code Beside" feature of whidbey but I never knew that it simply meant an inline code block.

    I think that giving people an option is always good. It’s never good to have only one way of doing something.

    That being said, as Anatoly has suggested – maybe unknowingly 🙂 -, I would like a tool that converts the source from Code-Beside to Code-Behind and vice versa. I, like Anatoly, don’t want to take over a project and find myself with mounds of Code-Beside files to deal with. If you’re going to provide an option, you should make it complete. Especially when the tool isn’t given out for free but gets sold for hundreds of dollars.

  25. Jiho Han says:

    I just remembered something and I thought I might just throw it in here as well. Does whidbey address the inability to create .netmodules or multifile assemblies?

    Just wondering.


  26. Mikhail Arkhipov (MSFT) says:

    Hmmm, I guess I was not clear. Code Beside DOES NOT mean inline script blocks. Code Beside means separate class file (i.e. foo.aspx.cs). Actually, we even limit support for server code in the aspx file in this case. For instance, you won’t be able to generate server event handlers via dropdowns and double-click in Design view will generate code in the CS file, not in the ASPX file. It is pretty much Code Behind model except it is based on partial classes so no control declarations are requred (i.e. you don’t have to declare

    System.Web.UI.Button button1;

    in addition to <asp:button id="button1" runat="server" />

    Code Inline is a simplified model which does not requre .cs (.vb, .js) file and allows you to write server code in script blocks. It targets simple cases when amount of server code is small and placing it in a separate file create more hassle than necessary.

  27. Mikhail Arkhipov (MSFT) says:

    As for conversion, Whidbey includes migration tool that will convert Code-Behind files to Code-Beside when you open a project or a Web site.

Comments are closed.

Skip to main content