The Latest Crap on Code-BePart in ASP.NET v2.0

10 Comments

• 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?
  

• 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.
  

• 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 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.
  

• 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,
  
  
  
  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