C# and ASP.net Whidbey

Article
04/30/2004

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" "https://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

uint _numClicks = 0;

void Button1_Click(object sender, EventArgs e)

{

++this._numClicks;

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

}

</script>

<title>Untitled Page</title>

</head>

<body>

<div>

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

</div>

</form>

</body>

</html>

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

Anonymous
April 30, 2004
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.
Anonymous
April 30, 2004
Unfortunately, a lot of people do. So here you go :-). However, code separation is still there and it is default.
Anonymous
April 30, 2004
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.
Anonymous
April 30, 2004
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.
Anonymous
April 30, 2004
scottgu:
Are you sure ?
Have you seen technical preview ?
Some official document link that proves this ?
Anonymous
May 01, 2004
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.
Anonymous
May 01, 2004
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>
Anonymous
May 01, 2004
Official link
http://msdn.microsoft.com/asp.net/whidbey/default.aspx?pull=/library/en-us/dnaspp/html/codecompilation.asp

http://weblogs.asp.net/scottgu
Anonymous
May 01, 2004
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)?
Anonymous
May 01, 2004
Thanks for that entry, it's always interesting to hear about these little snippets of information from within the production teams!
Anonymous
May 01, 2004
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
Anonymous
May 02, 2004
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.
Anonymous
May 02, 2004
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 ??
Anonymous
May 02, 2004
C# and ASP.net Whidbey
Anonymous
May 03, 2004
The comment has been removed
Anonymous
May 03, 2004
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 :).
Anonymous
May 03, 2004
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.
Anonymous
May 03, 2004
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.
Anonymous
May 03, 2004
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.
Anonymous
May 03, 2004
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).
Anonymous
May 03, 2004
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 ?
Anonymous
May 03, 2004
The comment has been removed
Anonymous
May 05, 2004
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?
Anonymous
May 05, 2004
There is new Build Web Site command that compiles all pages. I guess this is what you want.
Anonymous
May 06, 2004
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.
Anonymous
May 06, 2004
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.
Thanks
Anonymous
May 11, 2004
The comment has been removed
Anonymous
May 11, 2004
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.
Anonymous
January 16, 2007
<A HREF=" http://bonring.fire.prohosting.com/scarface_theme_on_mobile.html">scarface theme on mobile</A>
Anonymous
January 16, 2007
<A HREF=" http://bonring.fire.prohosting.com/scarface_theme_on_mobile.html">scarface theme on mobile</A>
Anonymous
January 20, 2007
<A HREF="http://entertop.info/scarface_rigntones.html">scarface rigntones</A>

Partager via

C# and ASP.net Whidbey

Comments

Ressources supplémentaires