Ramblings from the Creator of WilsonDotNet.com
I prefer the new way. You get precompiled pages, and you get rid of the double declarations for controls, which can be a mess when a page has a couple hundred controls on it. I definitely think the change in Code-Beside showing the inheritance chain in the code is good though. It was a little confusing to me that the code classes didn't inherit from anything. A little bit too much magic. :)
Not quite sure i'm understanding your rant? This is good for those who don't want others who have access to the servers to mess with their html source code, so i don't see what all the fuss is about.. it's not like it's mandatory :/ And this isn't anything new, they've been touting this pre-compilation feature since the announcement of 2.0. Also, shouldn't this make deployments for large webs considerably faster and easier since everything is already precompiled and pages don't need to be compiled when they're first accessed? Then again.. i might be misunderstanding your post :|
Stebet: Yes, you've misunderstood my rant. My rant is NOT about pre-compilation, which is a good thing in many cases. My rant is about the latest version of code-bewhat -- which appears to be getting just downright screwy. My side rant was that they took away one type of compilation, that of code-behind, in the new model -- and while I agree many will benefit from pre-compilation, many also benefit from the existing compilation of only code-behind. I'm saying that should have left code-behind alone and simply added pre-compilation as another option. Those that don't want the OO nature of code-behind would be served well by the new features in VS (intellisense and code view) for the single page model.
Uhmm... that's exactly what they did according to the article you linked isn't it? Use src= instead of CodeFile= and you get CodeBehind?
Hi Paul, Dont stress, they have not taken anything away. You now have the option of: a) Fully pre-compiling the site. b) Dynamically compiling everything at runtime. c) The old code-behind model (Fritz is incorrect this is not supported), just improved a little. Here is the post I just made on Fritz blog: >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. There is current a lot of misunderstanding about the most recent changed because they are only available in the November CTP. Bring on Beta 2..... David Taylor
I am not up on all the changes to the code-behind, but I can see the partial page classes being really useful for having code-generated and customized portions of the pages in separate source files. I think we will see some cool code generation tools coming down the pipe that will exploit this feature, allowing us to be more productive and causing less of a chance to step on generated code.
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
Almost, but not quite, src is the same thing as it is in v1.1 -- which is code-behind that isn't compiled. That's certainly not what I want, nor is it really supported by VS today or in 2005.
I agree that partial classes are going to be very useful in code-gen scenarios, so I'm not trying to moan about partial classes. I'm just very dissatisfied with the use of partial classes in ASP.NET for code-whatever-we're-calling-it. Code-behind in v1.* works! And its very easy for anyone coming from an OO background to understand. It doesn't hide any magic from you -- it just works. Granted, it may have some issues for those tasked with building the VS designer, but designers are always difficult. As far as I'm concerned, all the changes from code-behind are being made either to (1) make the designer easier to build or to (2) make things simpler for non-OO web developers by hiding things from them. The original code-beside model in the previews didn't hide too much, since it was a pure partial class implementation, although it also was not going to be easy for anyone working without a cool tool like VS, unlike the standard code-behind of today. But this new model is just introducing too much trickery that requires a tool or a compiler to make sense of it all -- not at all simple unless you only work in VS. True, I can do pure page inheritance and avoid this, but now you're telling me that I can't use the tool to help me -- and yet I can today -- so this is a huge step back for OO web developers. Let's stop and think about what we're saying. We're saying that protected declarations in an abstract base class are too confusing! And I agree they are to far too many web developers -- but those are the developers that should be using a single page model anyhow! Corporate developers, as opposed to hobbiests, are the ones who should be using code-behind -- and they had better learn OO in .NET and not have us start hiding things from them and having everything magically work at either compilation time or runtime! So what I want to know is if you don't like code-behind in v1.* today, then why don't you just use the single page model? You can precompile that too, so I really don't see why precompilation keeps being the rationale for a lot of this crap. And I do not intend to remove my description of this as crap -- it was crap when it was first shown to me, it was crap when I first showed it to my team of OO developers (and I was trying to defend it then since I decided to go along with the crap), and its crap now.
I agree with you Paul, src= is not an option for me. I do not deploy or distribute the .cs files with my web applications. So looking at the only remaining option which is CodeFile=, what exactly does that mean for me, when up till now I deployed my .aspx files and my precompiled dll's in the /bin folder. I still don't think I have gotten my head completely around it.
Paul, I just think you are being way harsh. I mean you seem to be suggesting the new model will only be easy when using a tool like VS. This thinking is just backwards. I think the opposite is true and people could only use the V1.x codebehind model when they use a tool like VS than manages both the ASPX and control declarations at the same time and keep them in sync. The whole point of this change is so people can use simple tools like vi/notepad and use the code separation model. You seem to be defending the V1.x codebehind model which was always ugly and broken. It was just problematic to define your controls both in the ASPX file and also in your page....Then if you renamed your control in you .cs file but forgot too in your ASPX file, guess what? a) Your code would compile perfectly. b) Your code would run perfectly, but you would end up having a second control with the original name that was not "correctly hooked up" to your code. This is all wacky and wrong...and quite rightly identified by the ASP.NET team at 'brittle'. David Taylor
Hi Paul, Actually, I forgot to mention that it is way more than that...... Both models in V1.x (single-page or code-behind) you never really knew if your application would compile until runtime. In fact you would have to 'hit' every page in your application at runtime to find out if you had any errors in your ASPX page because the ASPX page was only compiled at runtime when the page is first hit. So not only have they simplified the model with V2.0, but they now fully support compiling your .cs page (partial class) against your .ASPX (partial class) and thus immediately find errors in control declarations, etc. But more importantly, they compile your 'entire site' when you hit the 'build' button. Thus Visual Studio 2005 will, for the first time, compile everything you have and tell you at 'build time' instead of 'runtime' if there are any errors in your code. This makes me want to jump with joy! Because we are getting all the benefits of strong static typing, with an environment that feels like everything is dynamic. :-) Dont worry....Be Happy... (I will sing for you Paul). David Taylor
I do agree that adding the pre-compile/build option was a good thing, but I think that could have been done with the old model too. And while I do agree code-behind in v1.* is "brittle", it certainly is not "ugly and broken". Its pure OO -- that may be "ugly" to many -- but to many of us its not at all ugly. And "broken" -- I'm not at all aware of any thing in code-behind that is broken. So yes, they are right to make some tweaks, and a pre-compile/build option is very much appreciated -- but that doesn't justify all the hurdles and magic of the new system -- nor the loss of the current deployment model.
Paul, >> nor the loss of the current deployment model. See my other comments above; you can still use the current deployment model. Maybe what you are missing is that there is a new command line compiler supplied specifically for ASP.NET (in that it understands how to generate a partial class from your ASPX page and precompile it against your partial .cs class). This new command line compiler is not a "special thing in Visual Studio". It will be a standard part of the SDK. It is with this compiler you can do the precompilation and end up with the current model of deploying a DLL, but still leaving the ASPX page in the server for editing like some people wanted. Does that help? David
You may be right that the existing model is there, but Fritz also didn't seem to agree with you there -- but maybe. But I still believe there is simply no need for all this crap when what we have was working perfectly OO, and since we have improved single page support now too. It just feels like you are defending the ASP.NET team's decision instead of looking at the bigger picture and calling it what it is -- and I did that for a while myself so I can relate. Its so easy to get caught up in defending our baby when we're MS ASP.NET devs, but we also have a responsibility to be honest. That was exactly the issue when they first showed this to me and the other dozen people at the first private preview -- we all thought it a bad idea and they "convinced" us that it was a good thing since it was a "brittle" model and too "hard" for newbies. But there's something seriously wrong when the ASP.NET team has to "convince" the very experts they invited !
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 David Taylor