More details on code behind v2

This really makes me think they should have just left code-behind as it was in v1.*. I was initially opposed to this when it was introduced back at the first private preview in October 2003, but I (and others like me) relented when the team insisted the code-behind model was too "brittle". While there was certainly truth in this, and certainly beginners in OO have issues understanding code-behind, it just doesn't look like they've succeeded in the end here. Now it appears to be a monstrosity that's not OO, not simple, and not even as functional as the original model which at least allowed you to pre-compile the code-behind while leaving the design non-compiled so designers could modify small things in it if necessary.

I still think that this whole partial class thing in the code-behing is just to show off partial classes :) C'mon... All this mess just to avoid those protected members? Is there some other more important advantage ? If we would eventually get page parser/compilation errors before (our mistake, of course), now with more files being generated I'm affraid it represents more space for those errors to happen.
On the other hand, this should make me more comfortable that the IDE will not mess with my code so much. This should be especially good in windows forms.

I wouldn't go as far as Paul and suggest this is possibly a step backwards, but certainly if the only advantage to this model is the lack of having to declare protected control members, this is certainly a trivial enhancement.

I thought the payoff in this model of using partial classes was in the ability to use code generation to help generate parts of a class in separate source files. This way you can have code generated parts of a class and customized parts of a class in separate files that can be merged to generate the complete class. I see this opening a lot of doors to IDE and tool vendors in helping developers be more productive and causing less problems with developers stepping on code generated portions of classes. Am I wrong or missing the big picture?

>There is one claim I have seen made that this model also enables the pre-compilation of the code behind classes....(cut).

But it does allow this Fritz. This is because your code-behind and original .ASPX file (both partial classes) will be compiled together into a single pre-compiled class. This class then becomes your page's bass class and at runtime your ASPX page will inherit from this base class.

Then at runtime you can edit your ASPX file, (like you can in 1.x) and it will simply cause a recompile (again inheriting from your original base class).

You are probably just confused because you figure "but what if I add a few extra controls to my ASPX file after the base class has been pre-compiled? They will not be added to the base class!". That is perfectly correct, but not a problem, because your base class never reference those new controls anyway.

In fact this is exactly the same situation as we have today in V1.x with codebehind if you add a new control to your ASPX file using nodepad after the code behind was pre-compiled by Visual Studio.

This is actually quite simple, and I think people are just confused because the ASP.NET team changed the way this is done mid-way through the beta process. But the end result will be quite elegant.

I never deploy .cs files to the web server and I usually inherit my code-behinds from a custom base page that inherits from System.Web.UI.Page. Will I still be able to do that without any trouble? I like and am very comfortable with that model.

Also, I don't know how comfortable I am with not being able to see the declarations for the controls I'm using in the file where I am using them. I sometimes do a lot of glacing at the top of the file if I forget the name of a control I need to use. I just don't think I like the idea. There doesn't seem to be enough payoff.

Brian, the answer is "Yes you can do what you have done in the past without any trouble". If you have forgotten what controls you have access to just press "Ctrl-space" or type "this." and intellisense will show you.

Fritz - here is some additional info I posted on Pauls Site:

I should clarify one last possible point of confusion:

Fritz was probably thinking that it would be impossible to pre-compile your base page partial class, because it needs to be merged with a partial class with control definitions generated from your ASPX file; And this is completely correct...you DO need that ASPX file to be defined first in order to pre-compile your base class.

But the point here is that whilst you do need an ASPX file containing the control definitions in order to pre-compile your base page class; at any time after this, you can edit the ASPX file like you can today in V1.x and it will be recompiled on the fly inheriting from your pre-compiled base class.

The main question is "Is it better the controls are defined in the .cs file imperatively , or the ASPX file declaratively". Hopefully everyone agrees the latter is better.

And guess what? If you disagree, and just want to define the entire base-class in code without needing an ASPX file to compile against (partially) - you can just do that by writing the class in exactly the same way as you would in V1.x. Just forget all this partial stuff and write an entire base class that inherits from Page.

I hope we can get some agreement that this is "all good" and that Paul can edit his blog entry and remove the word "crap" ;-)

Regards,

David Taylor

David - perhaps you can clarify for me, in what way is the code-behind file and it's generated partial class sibling precompiled? The sibling partial class is generated by ASP.NET on request and then compiled together with the code-behind class to form the base class for the ASPX page. Unless there is some option to generate this sibling class during a local compilation before deployment, I don't see how anyone can call it precompiled. Separately compiled, perhaps (although in my tests, the sibling partial class and the ASPX class were placed in the same file, preventing separate compilation even).

Btw - I'm reasonably happy with the new model. I think the advantage of not having to declare control member variables is huge. I think making the inheritance from System.Web.UI.Page explicit in the code-behind class is good. However, I still claim that the new model does not enable pre-compilation of the code behind classes, and I don't think I'm confused :)

This is interesting. I thought that the declaration in the .aspx file was going to be the actual declaration ala XAML. Thus the partial class would be the .aspx file. But I see they've moved away from that for obvious reasons.

This is good info Fritz .. thanks for sharing.

Fritz, thanks for the updated info. What about us guys with the beta 1 bits who'd like to start crafting our ASP.NET 2.0 applications? Should we just wait until the beta 2 release (which I hear is supposed to be in spring) or is there a way we can "prepare" for the changes to the "code-behind/beside" model?

I would just go ahead and build with Beta 1, and then make the necessary changes when beta 2 comes out. They should be pretty mechanical - just add the Page base class to your code behind files, change CompileWith= and ClassName= to CodeFile= and Inherits=. Also, try and make your code behind methods protected instead of private.

Fritz,

You compile your ASPX page and your partial class into a precompiled class and end up with a precompiled DLL 'exactly' the same as you had in V1.x from a reflection standpoint. By that I mean if you looked at the result using a reflector it would be about the same (minus all the other changes they made in 2.0).

Maybe the piece you are missing is the compiler....Obviously you cannot use the cs.exe compiler as it would complain because it does not understand the partial class defines by the APSX markup. So the ASP.NET team are providing a special command line compiler that can precompile your ASPX together with your C# partial class.

I forget the name of the compiler (aspxxxx.exe?) but ScottGu blogged about it last October or November.

This will seriously all make sence once Beta 2 comes out and the ASP.NET team have more time to write articles and blog ;-)

David Taylor

Thanks David, it was the compiler piece I was missing. It makes perfect sense that they could provide their own compiler (and build it into VS.NET) that generates the sibling partial class and combines them into a single assembly for deployment.
It will be interesting to see how they present this in the IDE - perhaps a special deployment wizard that gives you the option of precompiling the code behind files.
Anyway, I agree that it will be much clearer once beta 2 is out.

BTW Fritz,

If you have Lutz's reflector, load up the November CTP assemblies and search for this class: PageAsyncTask

This will set you on a trail of reflection that will be exciting (and probably waste half a day as it did for me).

I wrote a little web app sample after reading your earlier blog entry...but dont want to say much more unless I spoil the suprise....other than that I dont believe the implementation is even 100% complete in the November CTP.

Once you realize where this is going, you will be *very* excited about Beta 2

I might post my own Blog entry about this....but will give you a few days first to see if you can beat me to it.

;-)

David Taylor

PageAsyncTask - intriguing indeed! I see I'm going to have to spend some quality time with this feature :)

I believe this is an improvement from Beta 1 where I had a hard time using public properties of my custom user control code-behind classes. Also with the added editor support for intellisense in the markup view I will now do two things.

1. Inherit all of my pages from a single base class to handle everything common.
2. Write the little code to use my web controls in a <script runat=server/> tag.

I already make a practice of not writing any logic whatsoever in my aspx.cs files, so they are really fluff. I would love the opportunity to shun them and keep my presentation in the aspx and my code in my base classes where it belongs. And, of course, precompilation can compile everything.

Hi Fritz,

Paul was starting to really get on my case...So I actually loaded up the CTP to find the information for him (Paul needed to know this stuff given his position as a leader in the .NET community)....So here are the details reposted for you (below).

Btw Fritz...To keep you going regarding PageAsyncTask, here is another hint:
Page.RegisterAsyncTask(myTask);
;-)
-----
Paul,

I did convince Fritz. Anyway, load the November CTP onto a machine (do not try this with the December CTP which has an older framework). From a .NET command line prompt (or in the .NET 2 directory) type:

aspnet_compiler.exe /?

To completely precompile your app, removing all source (even ASPX source) do this:
aspnet_compiler.exe -v /MyApp -p c:\MyApp c:\Output

To do what I have been "trying" to explain use the -u option (for Updatable), as in:
aspnet_compiler.exe -u -v /MyApp -p c:\MyApp c:\Output

This will basically precompile your partial class against your ASPX file, leaving you with a precompiled DLL as per what you have with .NET 1.1, and leaving your ASPX page alone so it can be edited after deployment (as per the 1.x deployment model).

Obviously.....You need to use a new compiler, because the csc.exe compiler (and vb compiler) will not understand how to compile the ASPX into a partial class....

I hope that helps clear things up.

Note the compiler is a core part of .NET 2, not a special thing shipping with Visual Studio

---

Confirmed - the /u option generates precompiled code-behind classes merging your partial class with the ASP.NET-generated sibling partial class, but leaves the .aspx files intact for updating purposes. The IDE option for this is a checkbox in the Build/Publish Web Site dialog that says 'Allow this pre-compiled site to be updatable'.
So as David points out, this model really gives us everything we had before with a less brittle and more flexible implementation.
I admit, it feels a bit overly complex for what it is, but to provide all of the compilation and deployment options they are providing, I don't see a simpler solution.

I was chatting with <a href="http://staff.develop.com/ballen/blog/">Brock Allen" about this the other day, and he pointed out one potential advantage of the beta 1 model over the beta 2 model, which is the ability to specify an alternate base class for all pages in your config file at some later point in time. In the new model, you'd have to manually update all of your code-behind classes to point to your new base class.

Fritz,

I hope you see my blog comment, sorry I'm a bit late to the party.

With the compilation model change, I can precompile and deploy aspx'es and ascx'es to IIS - that's awesome.

My question is - can I mark the various controls on my base page ascx/aspx as a protected/private/public/internal .. etc.?

I'd appreciate your reply :)

- SM

Sahil - there's no way that I have seen to change the protection level of the control declarations, they seem to always be protected.

-Fritz

Okay I've posted something on my blog regards that.

Hope a softie will bite :)

http://codebetter.com/blogs/sahil.malik/archive/2005/02/02/50343.aspx

What the heck is this?

"...load the November CTP onto a machine (do not try this with the December CTP which has an older framework). "

Why would a later build have an older framework? If I am going to download one and start playing with it in general (not specifically doing what you were explaining) what version should I get??

I agree with Paul above - this is a joke, I'm really disapointed with this move to html.

I picked .net since I could have code separation - but now it appears they have succumbed to the scripter world of web programming.

I don't mind options, but don't leave behind something that was working well.

note: MS - let developers work without touching html! Only time in 1.1 I touch html is to add javascript includes the rest is all code.

I don't see how this could be considered a move backwards. All they have really done is moved the generated code to a seperate file. This reduces human errors as well as making the designer's job a little easier. Nobody is forcing you to write code in the aspx page. This is exactly what partial classes are for.

Great explanation -- not what I was looking for though... Trying to find sibling controls on the same page from within a control??