ASP.NET v2.0: Code-Beside Replaces Code-Behind

I'm not at the PDC, but that can't stop me from talking about .NET v2.0 (Whidbey) as of today.  I'll try to do even better than the folks at the PDC and actually post some real details!  That's right, my goal this week is to post a brief article each day at ASPAlliance.com.  I'll also try to blog some other shorter details based on my experiences this last year.  So, here's the first article: ASP.NET v2.0: Code-Beside Replaces Code-Behind.  ASP.NET v2.0 replaces the Code-Behind code-separation technique with Code-Beside, which is designed to be an easier and less brittle method based on Partial Types.  (Note: I'm glad they did not call this Code-Behind v2.0, which was one of the early candidates.)

The article is not really about Partial Types, as there isn't much to them in reality.  However, it does confirm that this is a feature of VB.NET as well as C#, although not well publicized.  I also have some syntax notes on using Code-Beside and Partial Types, which shows you that the VB.NET keyword for a Partial Type is Expands, instead of the partial keyword used in C#.  Also note that while C# requires you to put the partial keyword in all code files for that type, VB.NET expects one main code file without the Expands keyword.  For ASP.NET, this means that the ASPX Page is that main file, not the Code-Beside file, which has the odd side-effect that any inheritance for the class must be defined in the ASPX Page, not the Code-Beside file.

Finally, I have grown to really like this easier version of Code-Behind over the last year, but it does have one aspect that I don't like in some cases.  You can no longer deploy and update ASPX Pages while separately compiling your code files, which is nice if you want to not make the source completely obvious, or even apply some obfuscation.  That's right, your choice is to deliver both the ASPX Page and Code-Beside source files, or you can pre-compile both, but that will make it impossible to update even the ASPX content on the fly.  Maybe another option will yet be delivered, as the ASP.NET team is just now starting their work on their last of three milestones, but that remains to be seen.

5 Comments

  • Well, that's the gotcha that remains, isn't it? Officially, you have to be at the PDC to get the bits. The first public beta is not scheduled until Spring 2004. That said, my guess is that someone looking hard enough will be able to find the bits in the next couple of weeks -- but not from me. :)

  • I hope I'm not misunderstanding this post... But I like that current system because it is nice to fire up dreamweaver or Visual Studio.net and make a change to the aspx file which doesn't effect the code behind page, upload it to the server, and NOT have to recompile. I hope that we don't lose this!

  • As long as you don't precompile the code-beside you will find those changes in the aspx file to actually be easier than they are now! On the other hand, if you choose to pre-compile your code-beside, then you will also be pre-compiling your aspx pages too, unlike today.

  • If we write every code inside aspx file do we still need Code-Beside file which is most of the time remains empty???

  • No. VS.NET Whidbey will give you a choice to use separate code file or inline code. You certainly do not need the separate file if you intend to use inline code. Also, unlike today, it will give you full intellisense with the inline style, and a view that is code only. I would still recommend the separate file if you are in a team environment, as it allows different people to work on the GUI and the code.

Comments have been disabled for this content.