We live in a disconnected world (as I seem to keep saying in my books about ADO.NET), but its increasingly becoming clear that I suffer from some of the same features as the DataSet. While I admit that it would be difficult to serialize me as XML (though perhaps my DNA could be), it does look very much like I've become disconnected from the "real world" - at least as far as programming is concerned.
I've been playing with .NET for what seems like forever, and with version 2.0 in its various guises for more than a year. So it's hard when I have to switch back to version 1.x again, as I really miss the data source controls, clever controls like the GridView and DetailsView, and the new XML data binding features. However, I find I really appreciate what .NET has provided when I come to build new applications and utilities, especially when compared to the pre-.NET way. I tend to build my own "internal" utilities using VB, and several are still in use on my network that were built in various versions of Visual Studio from 4.0 to 6.0 (the one surviving utility built in VB 2.0 was finally replaced about a year ago!).
Since Visual Studio.NET and the .NET 1.0 Framework appeared, I've tended to use VB.NET and Windows Forms to build new utilities, such as the most recent one that monitors my remote Web sites. Yes, I know there are plenty of these kinds of utilities available, but I wanted to do some custom monitoring of downtime and logging against a new hosting company that I'm considering switching my main stonebroom.com site to. Why the move? I've been very happy with XO Host (Concentric) for the past several years, and their service has been excellent, but I can't run my own DNS for the site because it has a dynamic IP address. I'm trying to implement and support the Sender ID initiative (see previous shed entry), which requires DNS records that most Web hosts cannot provide. My new host WebsiteSource provides a dedicated IP address at a very reasonable rate. I'll let you know how they pan out over the next few weeks of monitoring...
Anyway, back to the subject in hand, it really is amazing how easy most things are with .NET compared to, say, VB 6.0. Writing to a log file no longer involves several routines to check for an existing file, open it, write to it, and then make sure it's closed again afterwards. I can do all that in a few lines, such as:
Dim writer As StreamWriter Try writer = File.AppendText(myLogFilePathAndName) writer.WriteLine(messageText) Catch ex As Exception Finally Try writer.Close() Catch End Try End Try
And, in that, I can catch any errors and still make sure the file is properly closed without resorting to all that old "On Error Goto" stuff. Wonderful! Plus, accessing an HTTP URL is so easy, using the HttpWebRequest and HttpWebResponse classes from the System.Net namespace. No need for custom controls or calls to the Windows API - just a few lines of simple code.
Even considering this, the advantages of .NET really came home to me when I started, a couple of weeks ago, to try and sort out an ASP application for a company based here in England. It's a long time since I did anything beyond the very basics with "classic" ASP 3.0, and I'd completely forgotten just how bad this technology actually is when compared to ASP.NET. Well, I guess "bad" is not the right word, as it was a great way to build dynamic sites in its time (and I profited by writing a lot about it!). But, compared to what you can achieve quickly, simply, and elegantly with ASP.NET, it's frightening to have to go back and do the scripting thing again.
Not only is the language extremely limiting (no modern features, and almost non-existent error handling), but the requirements for using "render blocks" and Response.Write statements scattered throughout the page, and writing code to persist control values, is a real pain. Plus, lack of events that means you have to test for values in the Request collection to detect user interaction if you post back to the same page. Combined with having to work with (or, perhaps more accurately, against) an existing inflexible and imaginatively-designed data access layer - and I use the term "imaginatively-designed" in its broadest sense here - I'm amazed to see what we all went through at the time. And I guess there are still plenty of developers out there who still have to do this every day. Hence my "disconnected" feeling; and my heartfelt condolences to those that haven't yet had the courage or opportunity to grasp the ASP.NET sword and smite with anger and pride the recalcitrant problems faced by their Web sites and Web administrators (wow, that was nearly prose!).
Meanwhile, using developers and their problems as a nice segue into an entirely different topic, thanks to all those who were involved in the recent VBUG UK 10th Anniversary Conference. I was proud to have been invited to speak, and chatted away for about an hour or so about all the great new XML-based features in ASP.NET, the System.Xml classes, SQL Server 2005, and SQLXML. As you can guess, it was all a bit of a jumble - I really should have chosen a narrower feature set rather than such a broad topic, but when the nice lady from VBUG (Hi Rebecca) phones up and asks you to help out, you can't really refuse. And since very few people were even using XML (and even less using XML in .NET), it probably all went over their heads in a rush of hot air and multi-colored PowerPoint slides. Maybe I'll get another chance next year...