Execution Ordering

re: Execution Ordering

Anderson Imes — Thu, 29 Jul 2004 20:28:00 GMT

Most of ASP.NET I learned from the Wrox Press book "Professional ASP.NET 1.1" (http://www.wrox.com/WileyCDA/WroxTitle/productCd-0764558900.html).

I did a lot of research, and being from a classic asp background, I found this book very helpful. It does not involve Visual Studio much - mostly just ASP.NET. The first several chapters describe in detail the execution order of a page and its interraction with the CLR and IIS. Very good.

Visual Studio does a lot for you and most things are better done in the codebehind, but there are times when it makes a lot more sense to dive into the HTML and add some code. I find that a lot of the programmers I've worked with are resistant to this approach and I think it makes their applications less efficient and harder to read. I like this book because it tells you when best to use codebehind or use inline C# in HTML view.

re: Execution Ordering

Ian Griffiths — Wed, 04 Aug 2004 19:38:00 GMT

You seem to be assuming that just because something is on the .aspx page itself (and not the code behind) that this means it runs on the client. At least that's how it seems when you ask the question "why didn’t this work on the client?"

In fact, the .aspx page can contain a mixture of client-side and server-side code. Anything inside a <script runat="server"> block, or inside <% ... %> or <%= ... %> tags runs on the server. Anything else runs on the client.

If your code truly was on the client, then that would explain why it didn't work - the set of classes and facilities available to you on the client are completely different from what's available on the server: client side code basically gets to use DHTML functionality, while server-side code (whether it's on the .aspx or the codebehind) gets to use the .NET framework. Likewise, the set of services visible on the network will likely be different.

And I'm pretty sure you know this... :-) So I think this is really a case of terminology - I don't think you reall mean "on the client" here.

The real question is: how does server-side code on the .aspx get hooked up with everything else. And the answer is: it depends on whether it's a <script> block or a <% ... %> block. And the simplest way to find out what happens is to set the Debug="true" flag in the Page directive, and introduce a deliberate compilation error, and hit the page from a web browser running on the same box as the server. If you do this, ASP.NET will dump out the source code that it generated for your .aspx page. That will let you see where it puts the code.

I'd strongly recommend Fritz Onion's book on ASP.NET - it's the best I've read on the subject. It explains the order in which things occur when a page is rendered, and how the .aspx relates to the code that gets generated. (And it explains all of the rest of ASP.NET too...)

re: Execution Ordering

Michael Platt — Wed, 04 Aug 2004 23:47:00 GMT

Thanks for this Ian, yes, i didnt mean "on the client". Thanks for the debug tip and the book, I will follow it up
Mike