Kudos to Scott W. for an excellent weblog tool.  I installed the 0.95 release on my laptop and configured it for a single blog.  Even though I don’t have a persistent Internet connection here in Kuwait (waiting to come home), I’m making posts locally.  When I get home, I’ll publicly post them.  This week, I’ll get on the Net for about 2 hours every morning.  One hour, I’ll be talking to my wife through Net2Phone, and the other hour, I’ll be synchronizing SharpReader, E-mail, catching up on Dilbert, etc.

Scott, great job.  I know it must be tough finding time to work on this project given that we developers have other work that has to get done in order to pay the bills.

I almost started this post with “So, “, but I stopped myself.  Listening to .Net Rocks, and reading other blogs, I’m beginning to lose some basic grammar ability.  “So” does not belong at the beginning of a sentence (unless it’s used to mean “so that“ and preceeds a subordinate clause).  It either separates two independent clauses or an independent clause and subordinate clause when meaning “so that”.  Ok, on with my post.

.Net 1.0 comes out, and everyone jumps on the bandwagon of code-behind (myself included).  Not only is it a good idea to separate code from presentation, MS recommended it, so we did it.  I don’t regret it.  One thing to note:  code attached to a page should only do small things e.g. bind a listbox to a source, change text of a label or TextBox, show/hide controls, input validation etc.  Things that should not be done in page code are connecting to a database, reading/writing to/from a file, executing business logic or validation, etc.  If the Html view of the VS.NET designer had included intellisense for code, there would have been people who never would have used code-behind, but because that was the only option that offered intellisense, that’s what we did.  Choosing code in a server-side script tag or inheriting your page from a code-behing class should be developer or team preference.  If you are properly separating business logic from the UI, this shouldn’t be an issue, but so many developers continue to omit business logic classes from thier applications.  They connect directly from the web server to the database.  They tightly couple their UI with business logic.  Then, when changes need to be made, it takes longer than necessary and code reuse consists of copy and paste.  Bad idea.  Plus, why should an Internet-facing web server have direct access to an internal database server?  That, too, is a bad idea. 

Let me share with you some successes I’ve had with code-behind.  Note that code-behind is just the term used for creating an intermediate class betwixt the actual page and the System.Web.UI.Page class from which they all inherit.  With code-behind, you are subclassing the Page class, adding properties and methods, and then inheriting your actual page from your class.  Now your page class has access to all your public or protected members.  I quickly found that in a web app, many pages are going to have some of the same properties.  A user object is a good example of something that every page is going to need.  Why declare that property in every code-behind class?  Instead I created my own MyPage class that inherits from System.Web.UI.Page.  In this MyPage class, I declare the User property (with the “new” keyword to hide the base class’s User Property – my User object implements IPrincipal) and other properties and methods that need to be available throughout the application.  I add code in the MyPage class to initialize the User object and do other things, and then every code-behind class inherits from MyPage.  Now every page in my application benefits from this abstraction because every page can use my own User object natively.  I wrote the logic once, and I can use it on every page.  Now that is what object-oriented development is all about!  True code reuse.  I remember the days of #include in ASP 3.  .Net is so much better.

To get back to the change in Whidbey, I say, welcome inline intellisense.  Since my pages have little code anyway, I will probably go back to putting code in the same file.  This still won’t be the same situation as ASP 3.0, however, for the code will be in a <script runat=server> tag, and won’t be inline with the Html.  Also, because ASP.NET is compiled, this code will not be in the source files that are deployed on the server, so my pages will have some UI code and method calls to business objects.  That’s about it. 

All in all, I tend to trust Microsoft to make good decisions about the development tools.  There are tons of developers working to come up with these coding methods, and I’m pretty sure that I don’t know better than the collective knowledge of the Microsoft developers.

One issue that has perplexed me since having a nasty bug associated with a static event declared in a cached object is:  If you cache an object, how can your ASP.NET pages that subscribe to its events be garbage collected when that cached object has a delegate with references to event handling methods in the page object?

Some background on my issue:  I had declared a static Login event in a User object so I could be notified globally when a user logged in.  Every page subscribed to this static event.  Of course we know that only one static event exists for the app domain even though many objects of that type may exists.  So we have one static multicast delegate containing references to event-handling methods in every single page object in my web app.  Well, from examing the perf counters, memory keeping being consumed but never freed.  Why isn’t the garbage collector freeing these page objects?  Allocation Profiler reveals a whole bunch of Page objects in the Heap.  It turns out that as long as this static delegate has a reference to a method in the page object, that page object is not available for garbage collection.

Why, then, doesn’t ASP.NET exibit the same behavior when you have an instance event in an object that is cached and lives for the life of the appdomain?  This same object retains references to the event-handling methods in the pages, but the garbage collector reclaims their memory.  Why this difference in behavior?  I keep searching.

Last September I purchased a Dell Lattitude D500 laptop from a Dell store in Kuwait.  Dell is only direct in the U.S., but in Kuwait and Iraq, most goods are sold face-to-face.  I paid KD345 or roughly $1550.00.  It has a 1.3 Ghz Pentium M and 256MB of RAM.  I’ve added a 512MB chip, so now it has 768MB of ram now.   30GB hard drive.  Centrino. 

I am very satisfied with this laptop for a development platform.  I run XP Pro, VS.NET 2002, 2003, IIS, SQL Server 2000, Web Matrix, VSS, WinAmp, etc.  I’ve turned off the paging file to minimize hard disk usage, and it’s turned out well.  I’ve never used up all available RAM even with all my .Net programs running – ok, once when I used a static event with my ASP.NET pages, so every page retained a reference from the event and prevented garbage collection altogether. 🙂

This laptop is not slow by any means, and I get at least 2 hours on the battery with full screen brightness and everything running.  4 hours if I’m not in VS.NET.  I highly recommend it.  It has even done well in this very dusty part of the world.  I periodically used canned air to blow it out.  It’s a must.  The laptop runs very cool with most of the heat coming from the hard disk and RAM bays.  The cooling fan rarely has to kick in, so I guess Intel got the cooling right with the Pentium M.

Some bloggers have lamented over developing on a laptop or tablet, but I intend to use this laptop with a docking station when I get back home.  It more than meets my performance needs. 

I highly recommend the Dell Lattitude D500 as a .Net development platform.

Well, this is a truly curious feature.  Yes, Kudos to Microsoft for implementing this security feature by default.  Now the responsibility has always and still does rest with the web developer.  In 1.0, and even back with ASP 2 and 3, the web developer was responsible for validating all input.  Remeber, all input is evil until it has been validated.  I imagine that a lot of beginning ASP.NET developers won’t even know about the request validation feature of ASP.NET 1.1, but recently, I came to blows with this feature.  I searched and searched, but in the end, I just had to turn it off.  Yes, I know, bad stuff.  Well, I had the need to accept script as input.  In particular, I allow site editing, and the user has complete control over the page.  Even ASP.NET code is valid as input, so the user can do whatever with the page.  Only trusted users, mind you.  So ASP.NET balked: “hey, you can input script”.  Anyway, there is no configuring this security feature as far as I know, so in the end I just had to disable the feature.  Now I’m in the habit of validating all input anyway, because rarely is there ever a field that can be just anything.  There is usually at least some restriction, so I’ve always validated my own input.  Well, now I’m accepting script as input. 

Which brings me to the point of my post:  When displaying data from a database, always Server.HtmlEncode(your data).  What if the data contains a little emotiexpression ?  If you didn’t HtmlEncode it, it wouldn’t show up.  Also, this ensures that all the data gets displayed if otherwise it would be interpreted as markup of some sort.  So, Server.HtmlEncode() is your friend.