Some of you may know this and some of you may not, but the world of Information Technology is entering some foreign territory this week. At the end of this week, Bill Gates will no longer be at the helm of Microsoft, the world's largest software company.

A NewsWeek article talks at length about Gates' last few days in the cockpit of the software mogul, but what I find most interesting is the dichotomy between people that have been posting comments to the article. It is literally a comment of monumental praise, followed by a comment stating that he is pure evil or a monster. One poster even went so far as to say: "Bill Gates doesn't know anything about computers" and that "Microsoft has no idea what customers want". Hmm... for someone who knows nothing about computers, Bill Gates has made quite a splash. Wouldn't you agree?

Unfortunately, I must disagree with the poster's statement. Although my biases are obvious, what the poster fails to realize is that Bill Gates' vision over the past few decades has shaped what you want as a PC consumer. It's not possible to answer this question, but take a moment to consider it: What would the computing world be like today if there never was a Microsoft? You'd like to think that another company would have filled the void, but obviously we can't be certain of that.

It always disappoints me when people have these gross expectations of software that they don't have with any other product. Software should be robust, feature rich, flexible and cheap (if not free). Software should be developed to encompass every business process under the sun, but must not fail under any circumstances. Although these principles seem entirely valid, if you have expectations such as these in an industry as complex and fast-moving as software, you will continue to be disappointed; plain and simple. However, if you embrace the opportunity to constantly improve communication and technology for the world, you will find a lot of joy in your work. The PC industry, technology across the board, and the global economy would be very different without Microsoft. Millions of developers, administrators and businesses make a living off of what Bill Gates has built.

I cannot speak for everyone, but I will say this: Bon voyage, Bill. Thank you for providing the means by which many, many people receive a paycheck.

That being said, I am in a bit of a dilemma also with my blog. The current blog software that I use was written by myself and is several years old. There are many good blogging engines out there and I believe that I am going to use one of those. In a way, it is a sad thing to think about. This blog was the first piece of MeWare that I ever wrote and I kind of hate to see it go. But, it has been a good blogging platform and hopefully I can maintain the history that is in this little personal Web outlet.

More to come soon...

Click here to download the sample solution for this tutorial

In ASP.NET, an HTTP Handler is a means by which to process a specific endpoint request. Specifically, an HTTP Handler is used to process specific file types from within your ASP.NET website or application. The .NET Framework gives you a tremendous amount of flexibility and power when creating custom processing for specific HTTP requests. In ASP.NET, an HTTP Handler is any component that implements the IHttpHandler interface. The contract of this interface defines two key members: the IsReusable property and the ProcessRequest method.

• IsReusable: Gets a value indicating whether another request can use the IHttpHandler instance
• ProcessRequest: Enables processing of custom HTTP requests. This is the heart of your custom HTTP Handler. The argument passed to this method is the HttpContext object of the current processing request.

Defining logic for these two members satisfies all that is necessary to create an HTTP Handler. When you have defined your handler, you will register the handler with the ASP.NET application using the <httpHandlers /> node of the Web.config. To register a handler, you must specify three attributes:

• verb: This is the HTTP verb(s) that your handler will be used for when processing requests. The options are GET and POST
• path: This is the path of the file to process. In this instance, any file with an extension of .simple.
• type: The fully qualified type name of your HTTP Handler. In our example, this is SimpleHandler

After you have set up your web application using the above settings, you have successfully created and registered a custom HTTP Handler.

Now that you have an understanding of how HTTP Handlers work, let's do something a little fancier with our handler.

In the previous example, we built an HTTP Handler that simply flushed text out to the browser. Although this may satisfy some requirements, most real world usage of HTTP Handlers will be more complex.

Since the HTTP Handler provides us with access to the current HttpContext, we have access to the current HttpResponse object as well. We can use this object to send specific file types to the client. We can also send entire files to the client with the addition of a single HTTP header. In our ComplexHandler example, we will configure the application to handle RSS requests to a blog, download Word documents and flush a custom file to the client, all from the same handler.

The RSS request queries my blog for the RSS feed. It then transforms that RSS feed using a custom XSL transformation to display on a page. This process could very easily be modified to use a custom RSS source or generate only the RSS rather than a transformation of the RSS.

As you can see, HTTP Handlers bring the power of ASP.NET processing to custom file types in an extremely useful way.

His musing was targetted at specific Microsoft applications such as SharePoint 2007 and Outlook 2007. Although I partially agree with his points, I feel that he is missing the main point of distinction: SharePoint is an application - not the web. Shown below are my thoughts that I also posted to the discussion of the blog entry.

Discussion Post:

I really like Tony's columns, but this one has a few points which are not entirely related to one another.

SharePoint is not the web, nor is it simply a website. SharePoint is an application. It is a powerful and highly configurable application that integrates with desktop applications (MS Office), back office applications (Dynamics/CRM), mail servers (Exchange) and yes, even Internet Explorer. Since SharePoint sites/portals are generally secured to only company employees or partners, the environment in which they run is essentially controlled/contained. Unfortunately, much of the integration required by this application is beyond the scope of W3C standards. That doesn't justify the point, but it does clarify it a bit.

Given their past, I know that it is easy to vilify Microsoft in the quest for a standard web. But Tony touched on Microsoft's effort with his mentioning of the rich standards support in VS2005 and Expression Web. The HTML editor in VS2005 will tell you if you are using an element or attribute that is out-dated or deprecated from the current standard. You can also choose to have your entire site examined for WCAG and if you have a violation of WCAG, it will tell you the WCAG section as well as instruct you as to what you must do to correct it. Also, all Microsoft provided ASP.NET 2.0 server controls emit standards compliant markup.

The bottom line is this; SharePoint and Outlook are applications - not the web. Although they use HTML, there is a significant difference. Standards have their place and are a very good thing, and when it comes to providing standards compliant tools for developers, Microsoft has made tremendous improvements.

I have been developing ASP Classic/ASP.NET applications on the IIS platform for 6 years now. I started with IIS5 on Win2K server. The product was good, but the advancements made in the last few years that embrace the .NET Framework have truly been amazing. ASP.NET, now in version 2.0, has taken web development to a level that I would have never imagined possible. It is no wonder that some open source guys (including MIT, where open source was born) are making statements like this:

ASP.NET 2.0 is a much more viable platform for sophisticated apps than it used to be. MIT recently switched from java to C# for 1st year developers and I see .NET as much as J2EE in app jobs. As well, when I go to more sophisticated sites there are alot more .aspx is the URLs these days.

It's taken a number of years for this to happen, but through a few versions of the technology, the .NET Framework it is gaining a level of sophistication and maturity that developers can no longer deny. The fact that the underlying platform is built to run hand-in-hand with IIS is most likely the largest cause for this recent change of market share in the web server market.

The title is The Dark Knight and it once again stars Christian Bale as Batman/Bruce Wayne, and Heath Ledger will play the villain as The Joker. Batman has always been one of my favorite comic book characters simply because he possesses no super-human powers to rely upon. I don't know, it kind of makes the story a bit more attractive.

I personally cannot wait to see how this movie plays out!

Download Solution: _05_2007_MasterPages.zip (16.0KB)

Allowing users to select their own theme for your Web application is a feature that is gaining large amounts of popularity amongst users. ASP.NET 2.0 offers many ways to accomplish a theme implementation for your website, such as specifying a theme name in the <%@ Page %> directive of a Web Form, specifying a Theme in the Web.config file for your application or setting the Theme property of the Page class. All of these options provide a great way for administrators to apply themes to their apps, but there are some significant drawbacks to each:

• Specifying a theme name in the <%@ Page %> directive of each Web Form is a nightmare from a maintainability standpoint. In Web apps that may have hundreds of Pages, you would have to update the Theme attribute in every Web Form.
• Storing the Theme in the <pages/> element of the Web.config file solves the issue of having to update each page individually, but it also comes with its own baggage. If you use the Publish Web Site option in Visual Studio 2005, VS will hard-code the theme name into the Theme attribute of the <%@ Page %> directive on all pages that have any CodeBehind specified. If you then later change the name of the Theme in the Web.config file, all ASPX content pages will reflect the change, but any pages with CodeBehind .dll files in the Bin directory of your app will still use the theme that was specified in the Web.config when you published the site. Also, changing the Theme in the Web.config will cause IIS to recycle the application. Again, this is less than ideal.
• Finally, setting the Theme programmatically by setting the Theme property of the Page is a pretty appetizing solution. Unfortunately, a Theme is applied to an ASP.NET Web Form very early in execution, so you must do so before the Page initializes. This is typically handled in a PreInit event handler for a page. Furthermore, this requires you to create this event handler in every page of your application that uses your Theme.

I know what many of you are saying: Why can't I just specify a PreInit event handler in the MasterPage that is used by all of my pages? Unfortunately this does not work because the MasterPage is first compiled, then applied to the Page. The Page class sets the Theme after the MasterPage has already been applied, thus we are once again stuck.

I have seen many posts on forums that show how to accomplish this through a rather lengthy process of using an HttpModule to set the theme. While this solution works fine, it's a bit of an over complication. To solve this issue we need look no further than one of the most useful techniques in object oriented programming: Inheritance.

By deriving a class from the System.Web.UI.Page class, we are able to create the functionality necessary to give our users a theme rich experience with a simple event handler. In this example, I am using a class named AppCookie to store the theme name and AppPageBase is my Page derived class. The Theme property of the AppCookie class is read from a PreInit event handler that is subscribed to the PreInit event from the body of the AppPageBase constructor.

The event handler body is somewhat simple. A new instance of an AppCookie is created and tested to see if the Theme property is empty. If the property is not empty, the specified theme is applied to the page. If it is empty, the default theme which is defined in the <appSettings/> element of my Web.config file is applied instead.

The last step of the process is to ensure that all pages in the application use our AppPageBase class as the base type for all ASP.NET pages. To do so, we change the inherited class on all CodeBehind class definitions to that of our custom class. We must also change the page base type for all pages in the application that may not use CodeBehind. To accomplish this, specify the pageBaseType attribute of the <pages/> element to be the name of our custom class. Finally, I then added a few <asp:LinkButton /> controls to a Web Form to allow the switching between themes to be done by the user.

This implementation allows the user to control the theme, but could very easily be modified to allow only administrators to control the theme. You could store the selected theme in a text or XML file, or use the Web Configuration API to change the value of the default theme in our app settings. If an admin only theme scenario is what you are facing, I would recommend using an external file to store the selected theme. This way IIS will not restart your app every time you make a theme change, as it would if this data was stored in the Web.config.

Code for Part 1: AppCookie, AppPageBase (A), Web.config 

Although META data in the <head/> of an HTML document does not carry as much weight with regard to search engines as it once did, it is still a valuable compliment to any Search Engine Optimization strategy. Unfortunately, when using a MasterPage in ASP.NET 2.0, we lose our declarative control over META data and must rely on programmatic alternatives. Adding a META tag to a Web Form that uses a MasterPage is accomplished by creating an instance of a System.Web.UI.HtmlControls.HtmlMeta object, assigning values to its properties and then adding it to the Controls collection of the Page.Header control. Obviously, this becomes troublesome when using a MasterPage on a Web Form that is only a content page and has no CodeBehind to perform this operation. Luckily, our AppPageBase can be extended to give us the ability to enter META data directly into the <%@ Page %> directive.

In our example we are creating two properties in our AppPageBase class; MetaDescription and MetaKeywords. These are simple string values that will be used to store description and keyword data. To output these values to the page, we will create and attach an event handler to the Init event of the Page in the same manner as before. The body of the event handler will create an instance of an HtmlMeta object and use the two properties defined earlier to add this to the <head/> of the resultant HTML output. Finally, we specify the values for the MetaDescription and the MetaKeywords as attributes of the <%@ Page %> directive for the Web Form.

If you view the pages, you will see that the theme is applied based on user selection. You'll also note by viewing the source code for page NoCodeBehind.aspx that the META data was properly added to the <head/> of the document without any CodeBehind.

Code for Part 2: AppCookie, AppPageBase (B), Web.config 

In closing, you can see where these two techniques can perform leaps and bounds in the maintenance of an ASP.NET 2.0 Web application. An important note: if you have an ASP.NET content page that you do not wish to be themed in your application, simply specify System.Web.UI.Page as the value of the Inherits attribute of the <%@ Page %> directive. This will override the base type from the Web.config. Also note that this article did not cover caching of user defined themed pages. If you wish to explore your caching options, read the ASP.NET Caching Overview on MSDN. 

For those who may not know, I grew up on a small dairy farm in Northeast Indiana. My family has been in the dairy business for over 6 decades and have operated the family farm since the 1890's. I worked on this farm from the time I was ten or eleven years old until I was about 21. At that time, I was working full time as a Web Developer and I was also in college at the local Purdue University campus. Farming was tough work. I would do my "chores" before classes and after wrestling practice when I was in high school. My summers were always full of work to be done and working on the farm was my only form of employment until I was 18 years old. I still work on the farm a few days a year to help out when help is necessary.

When I was 21, I left working on the farm and gave the cattle that I owned to my dad. By this time, the partnership between my parents and my older brother Russ had really started to show reward. Russ was introducing some ideas that would prove to be very fruitful. Dad listened and together they took action. Within a short period of time; production was up, equipment was newer, profitablity was increasing and the facilities were fast reaching maximum capacity for the herd. In a few years, capacity had been exceeded and the time for a new facility was apparent.

In late November of 2006, they broke ground on the production herd's new housing facility which measures 54' wide by 136' in length. The health of the herd has always been a priority to my family. Veterinary care is routine, sanitation practices are exercised daily and nutrition is carefully monitored. The new facility makes the task of herd care a much simpler process. The housing is more capacious and the feeding area is now indoors and no longer subject to weather elements. The facility was also designed with climate in mind, so it is warm in the winter and cool in the summer. This facility truly does make happy cows, as you can see from the last picture I took of the new facility. Cows are resting better than before and eating better than before (both statements that can be proved by the pictures below).

Although I no longer 'turn a regular shift' on the family farm, I am very proud of where it is now. There have been many doubters along the way and I am very proud of the fact that my parents, and most of all my brother, did not listen to any of them. You guys are great.

The reason I have the time to blog right now is because I am installing Visual Studio 2003 and 2005 on my system again. I have upgraded to Vista at the office and I have to reinstall all of my applications. I'm OK with that because I have been running the same install of XP for over 3 years without fault and sometimes it's nice to clean the slate with a fresh install. I really like Vista so far and if you have the opportunity to check it out at your local Best Buy or Circuit City, I recommend you do so just to see what's new.

On the music front, the Fort Wayne local band; Ong has posted some new songs on their MySpace page. I saw them perform at The Munchie Emporium back in October and the performed a song called: 'Diamonds for Lauren' that I have been wanting to hear again ever since that performance. Well, they have posted a recording of that song on their page and I highly recommend that you have a listen to it. Very good stuff.

Well, prepare yourselves New Englanders; drive safe and stay warm!