Recent Updates Page 91

In my last post about CodeBehind, I stated that the CodeBehind attribute for the @Page directive was gone.  It was, and VS 2005 Beta 1 threw an error when i tried to put it there.  Mysteriously, now, it is back.  It appears in the intellisense window and everything.  I can use the code-behind attribute, but it literally does nothing now.  It doesn’t make the “View Code” menu item work.  It’s functionality is gone.  If you want to implement a code-behind file as a base class, you can do that by making that type the Inherits”. . “ attribute, but it really won’t be a code-behind file because it wont work if  you keep it next to the ascx file.  You would have to put it in the Code directory for it to even compile.  Then  your user control would see it and be able to inherit its functionality, so you can still do the inheritence that code-behind gave you, but code seperation is done with the code-beside partial class.

To be honest, at first I was a bit bitter that Microsoft had taken away my code-behind, but now I do see the benefit of code-beside.  I still think that code-behind should be an option.  I don’t the the removal of features is the answer.  I, as a developer, like options.  I also want explicit compiling put back so that I can actually have a web-specific assembly.  And I’d like to be able to designate more directories for dynamic compilation (not just /Code).

This is a chronicle of my adventure and probably indicative of some issues that you might face:

• I opened my project file which caused VS 2005 to run my project through it’s converter




• The converter pulls all my class files into the Code directory and converted all my code-behind classes to partial classes that compiled with the ascx and aspx files


• I tried to run the project:  NO GO.




• I was using <head id=“head“ runat=“server“/> to expose the <head/> element to the server so I could programmatically add <title/> and other elements.  Since v2.0 now has a Head property built in, my code is broken in this state.


• I refactored my code to use the new Head property, and I stripped out my own implementation of this feature.


• I tried to build my web site (which doesn’t produce a .dll by the way), it just does compile-time checking, and I was made aware of several more “errors“ throughout the site:




• My base page (in the Code directory) could not see any of my UserControl types – every page in my site has to be able to dynamically load one particular user control, and I was referencing that type in my base page.  Since code outside the Code directory is not compiled until runtime, my base page had no visibility to that type; therefore, it could not compile.




• A side-effect of the code-behind model is a hierarchy of page and control inheritence.  Every user control gets its own base class compiled into the assembly at compile time.  You end up with this strongly-typed web library of all your user controls.  Pages can reference controls in code, user controls can reference other user controls, etc.  When you take that away and make all code dynamically compiled at runtime, you no longer have that library of classes at compile time, and your coding is limited.


• I retrofitted code-behind to my user control by making a base user control class (in the Code directory) and having the ascx inherit from that class.  Then I can reference that base user control class in my base page and work with it.  Remember, code-behind just mandates a base page for every control and page.


• I refactored all my code to reference the base page type instead of the actual user control type (which really doesn’t exist until it’s compiled just before runtime).


• I ran my web site, and I received a reflection exception (could not find my assembly).




• In my project, I define a web user abstract class that inherits from GenericPrincipal.  For the app to run, I have to be able to instantiate a user class that inherits my abstract class.  Since any class from any library could provide this user class, I have config information with the assembly name and fully qualified type.  I use reflection to instatiate this type at runtime.  With VS 2003, I knew exactly what my web assembly .dll was going to be called, so it was a no-brainer.  With Whidbey, you don’t have a .dll until runtime, and then it’s a temporary .dll. 


• I refactored my project and broke off the entire Code directory into a class library project within the same solution.  This way I could guarantee the name of the assembly and perform the proper reflection code to instatiate my type.


• I ran the web site, and it worked!


• I proceeded to log in, and my site went into an infinite loop.  The following is a REAL BREAKING CHANGE!




• When a user logs in, (upon authentication changing) I do a Server.Transfer(Request.Path, true) to start the request over fresh with the newly authenticated user.  I do this because my login control is on every page instead of having a page as a dedicated login page (which would start a new request by going to another page).  I pass true as the second parameter so that the querystring would be preserved.  This is a very valuable feature.  The problem with this in v2.0 is that this feature has been modified.  Now, with that true parameter, both the querystring AND form variables are preserved and usable in the next request.  This is a huge problem because when the user logs in with my login form, the page posts back and sends the data in the Form collection.  The page authentications and does a Server.Transfer(. . . , true) and now sends the same form data to the next request (which logs the user in again and repeats the process all over again).  This results in an infinite loop.


• I changed the line to Server.Transfer(Request.Path, false) so that the querystring or form is not sent, and all is well.  My app seems to be functioning as normal.  I probably will find some other issues, but for now it’s working.  Of course, now if the user has some querystring data, and they log in, that data will be lost.  I may have to resort to a Response.Redirect, but I’m trying to avoid it.

100% backwards compatible?  Nope.  The addition of the Head property and the Server.Transfer() change are the two Framework breaking changes I’ve found, but the whole elimination of code-behind is where I believe a lot of people will have problems.  Honestly, it will take a while for everyone to wrap their brains around the change and realize that their apps are breaking because they don’t have a supporting class library as they did with all their code-behind classes.  In those cases where compile time referencing is a must, we can put our code-behind files in the Code directory, and they will dynamically compile.  This isn’t an ideal solution, though because then the code files and the ascx files are physically seperated from each other.

There are several bugs posted against Whidbey regarding this, and I’ve contributed one to suggest that dynamically compiled directories be configurable:  Why “Code”.  I may want my “Foo” directory to be dynamically compiled.  What I would really like to see is for an explicit build process in Whidbey as their is in VS 2003.  I want my web app to be compiled into a .dll in my bin folder.  I want to know what the assembly name is going to be.

In addition to my previous post in response to Van’s post, I have found the build process in Whidbey to be especially slow when building a web site that has a helper class library project.  When I build, the IDE hangs for at least 10 seconds before doing anything.  I really hope this gets better.

Van, from Microsoft blogged about Whidbey performance, so here is my experience in response to his query:

I have a Pentium M 1.8 Ghz with 1Gb RAM.

I open the IDE and open a 1MB web solution, and the IDE is consuming 128.5 MB of RAM.  I don’t feel any hurt because I have plenty more, but when i close the solution, I get the hour-glass, and there is a noticeable delay.  Also, when I create a new class file in the Code directory, I see a noticeable delay before the IDE is responsive again.  Then, if I add a class library project to the solution (to reference from my web site), every build is noticeable slower than VS 2003.  The IDE freezes for a moment before the build begins.  There are some intermitten freezes that happen, and since I’m a developer, even 1 second is noticeable.

Since you asked, I’ve used the MS IDEs all the way back to Visual Notepad.

On a positive note, the intellisense menus (which are EVERYWHERE) are super fast and responsive.  Kudos to the intellisense team!

When it pulls my code files into the Code directory, my casing is lost.  MyObjectException.cs becomes myobjectexception.cs.  I’ve already logged a bug with Microsoft, so hopefully this will get fixed.  The code inside is good, but the filename is converted to all lowercase.

Otherwise the project convert wizard works well.  I took my VS.NET 2003 project, and I opened the project file in VS 2005.  The convert wizard was automatically launched, and it succeeded.  It removed every CodeBehind and Inherits attributes from my @Page directives, and it converted all my code-behind files to code-beside (converted them from stand-alone classes to partial classes that merge with the aspx file upon compilation).  It pulled all my class files into the Code directory, and it preserved all my namespaces.

The issue I’m wrestling with now is how to declare variables of type MyUsercontrol.  All my usercontrols were converted to code-beside with partial classes, and my code can’t see the user controls (build error).  There is code in the Code directory that is referencing a Usercontrol type (to dynamically load later on), and I’m guessing that the code in the Code directory is compile first (and it can’t find the user control which will be compiled later).  I’m not sure if this is a bug or if I just haven’t figured out the *new* way yet.

In my journey down the Whidbey trail, I’m documenting key things I am discovering that are missing from the v2.0 books and articles I have read.  A key piece of information is the the CodeBehind attribute of the @Page directive is gone.  I’ve read that the code-behind model will still be supported in Whidbey, but I’m not seeing it.  I have no problem converting to Code-beside with partial classes.  There is still code separation, and the wizard is supposed to convert code-behind to code-beside, but it’s still a little buggy.  It left all my code-behind files untouched, and they won’t compile unless they are in the Code directory.  Of course the CodeBehind attribute has no bearing at runtime since it has always just been an IDE-specific attribute for linking the code file, but in the IDE, you’ll get the red squiggly line saying that no CodeBehind attribute exists.  One thing is for sure.  None of use will be using CodeBehind in Whidbey (but code-beside using the CompileWith attribute is better in my opinion).

I’m using VS.NET 2005 Beta 1, and I’m converting an existing web project to Whidbey format.  The wizard pulled all my supporting code files (.cs) to the Code directory, but it left my code-behind files next to their aspx and ascx files.  I learned that Web apps – called web sites in Whidbey – cannot be explicitly compiled as in VS.NET 2003.  Meaning, I can’t put a Class1.cs in the root and have it compiled into the bin on Build.  I have to either put this class in the Code directory or have it in a supporting class library project that I reference from the web site. 

It appears that only code files in the Code directory get compiled on a Build, and the (legacy) code-behind files do not get compiled.  Then on run, the page errors out because it cannot find it’s code-behind class from which to inherit. 

Code-beside, however, does get compiled no matter where it is.  The partial class linked through the CompileWith attribute gets compiled along with the aspx page.

So it seems that code-behind is really NOT supported in Whidbey.  Am I doing something wrong?  Is anyone else using Code-behind in Whidbey? or trying to.

I think it is terrific of Microsoft to make a tool like this available.  I’ve logged two bugs so far at the Whidbey Product Feedback Center.  There are over 1000 bugs logged.  It’s great.  The more bugs we find before RTM, the better the product will be.  And let’s face it folks, if you are using v1.1 now, you’ll be using v2.0 next year.  Unless you want to be like the people who reject upgrading to WinXP because they still favor Win95.  You can hold out for a little while, but eventually, we’ll all be using it.  Frankly, I look forward to it.  I’m using Beta 1 right now, and my team is doing a support tools project with ASP.NET 2.0 right now.  I’ll be porting my EZWeb project to v2.0, and in the process, I’m noticing some bugs.  These bugs aren’t major.  There are always work-arounds, but they are bugs nevertheless.  I praise Microsoft for soliciting this level of communication for thier upcoming product.

Most RAD developers will probably not encounter this breaking change, but for me, this doesn’t seem like something obscure:

In my pages, I make my <HEAD/> element accessible from code:

<head id=“Head” ruant=“server”>

</head>

Then, in my code-behind, I use:

protected HtmlGenericControl Head;

Then in code, I can add my title element as I need to, and I can add <meta/> elements programmatically.  Well, I try to run this page under ASP.NET 2.0, and my VERY FIRST experience with ASP.NET 2.0 comes back with a big, fat ERROR screen. 

Because the Page class in v2.0 has a Head property of type HtmlHead, my code will throw an error because I am accessing the HtmlHead Head; property through my HtmlGenericControl variable.  It worked great in v1.1, but it’s definitely a breaking change in v2.0.

I don’t really have beef with this change because a quick modification to my code solves the issue.  I do have beef, however, with the PR given to the “supposed“ backwards compatibility of v2.0.  Almost every article and book you read about v2.0 will say, “Never fear, your v1.1 apps will run just fine on v2.0 because it’s 100% backwards compatible.“:

ASP.NET 2.0 Internals claims this in the first line, and a direct quote from Migrating from ASP.NET 1.x to ASP.NET 2.0:  ”If you have ASP.NET 1.x applications in production, you will be relieved to know that ASP.NET 2.0 is fully backwards compatible. That is, your ASP.NET 1.x applications will run as normal on ASP.NET 2.0 without any changes.”  Well, my ASP.NET 1.1 application would not run on ASP.NET 2.0 without any changes.

I wish they would just be truthful.  I think statements like that are plain lies.  I have no problem with new versions have some published compatibility issues.  I know there will always be issues.  I just want to know about them.

Microsoft, I love you, but if you say something, I would like to believe it.  In this case, I wonder what other incompatibilities exist.

-now I await the inevitable comment that will prove me ignorant and misinformed. . . 🙂

I am in the process of porting my EZWeb application framework to ASP.NET 2.0.  Of course, this process will be similar to many projects that are currently in VS.NET 2003 format.  VS.NET 2005 will automatically convert the project.  I accepted the default option, and VS pulled all my code files into the newly-created “Code” folder, but my (converted) code-beside files were left with the corresponding ascx files.  I tried to run the application, and I ran into a roadblock.  It wouldn’t build because my .cs files that didn’t make it to the code directory were ignored.  Obviously I don’t want my code-beside files to be physically separated from the ascx files, so I think that the Code directory model is only useful for non-enterprise projects where you might want to deploy the source with the application and put all code in <script runat=server/> blocks in the ascx files.  Small hobbyist projects will probably benefit from this model because the deployed code-base and be modified directly without going through a lengthy develop-test-deploy cycle.  Academia will also probably use this model.  Especially with the free Visual Web Dev, intellisense in the HTML view will enable students to write Page_Load code, and they can even write classes and put them in the Code directory.  In my opinion, this change makes ASP.NET 2.0 viable for college classes.

But this still leaves me to explore another model for my enterprise-level web project.  I’m also a little annoyed that my favorite shortcut Ctrl+Shift+B (Build) was removed, and I’ll have to remap it.