Born to Thrive

As I mentioned in the previous post on the Presentation Layer Technology Matrix, one of skills measured by the 70-565 exam is the ability to "Identify the appropriate technology" and "Analyze and refine the logical design of the application", therefore below is the data access layer technology matrix that should help you identify what type of technology should be used in the given scenarios:

Consider using ADO.NET Core if:

Consider using ADO.NET Data Services Framework if:

Consider using ADO.NET Entity Framework if:

Consider using ADO.NET Sync Services if:

Consider using LINQ to Data Services if:

Consider using LINQ to DataSets if:

Consider using LINQ to Entities if:

Consider using LINQ to Objects if:

Consider using LINQ to XML if:

One of the skills measured by the 70-565 exam is the ability to "Analyze and refine the logical design of the application" or "Identify the appropriate technology", therefore below is the presentation layer technology matrix with the scenarios when a given technology should be considered.

Mobile Applications

Consider using the .NET Compact Framework if:

Consider using ASP.NET for Mobile if:

Consider using Silverlight for Mobile if:

Rich Client Applications

Consider using Windows Forms if:

Consider using WPF if:

Consider using Windows Forms with WPF user controls if:

Consider using WPF with Windows Forms controls if:

Consider using XBAP if:

Rich Internet Applications

Consider using Silverlight if:

Consider using Silverlight with AJAX if:

Web Applications

Consider using ASP.NET Web Forms if:

Consider using ASP. NET Web Forms with AJAX if:

Consider using ASP.NET Web Forms with Silverlight controls if:

Consider using ASP.NET MVC if:

Consider using ASP.NET Dynamic Data if:

Writing functional tests to validate that your application returns expected results (which can be done using Unit  Tests or Web Tests) is one thing but making sure when you go live and more users start using your application that it actually will run is a whole new ball game. That's why to avoid surprises and lots of costs, load testing should be part and parcel of every enterprise application development effort. And that's why Visual Studio 2008 provides the options of adding and running load tests, however that functionality is only available in Test Edition or Team Suite Edition. I used Visual Studio 2008 Team Suite Edition (90-day Trial) that can be downloaded from here. But to work with load tests you will also need a set of computers known as a rig, which are a controller  and agents, and those must be installed separately using Visual Studio Team System 2008 Test Load Agent, which includes both agent and controller software (I used 90-day Trial that can be downloaded from here). A rig is required as an agent is used to run tests and generate simulated load whereas the controller is used to coordinate the agents and collect the test results. With that software installed, a load test can be created to test if your application:

• performs under light loads for short duration (smoke testing)
• will run successfully for a sustained duration under heavy load (stress testing)
• is responsive (performance testing)

First you specify the load pattern as shown below. This allows you to perform a test with the constant number of users or with the range of users to see how the application performs when more users utilize it.

Next you can choose a test mix model as shown below. You can choose that what test is being run by a user  to be determined by a number of tests or number of users or user pace.

Next you can specify the probability of a virtual user running a given test in a load test scenario as shown below. This lets you simulate load more realistically. Instead of having just one workflow through your applications, you can have several workflows, which is a closer approximation of how end users interact with your applications. A virtual user randomly selects a test, based on the probability you specified in the mix. For example, if you have two tests, each 50% in the mix, then a new virtual user chooses to run the first test roughly half the time. In a 50/50 mix, if one test is long, and another is short, more load comes from the long test.

Next you can test how a web application performs when users use different browsers as shown below. That allows you better simulate the load when users start accessing your web application using different browsers.

Next you specify what network type will be used by users to run your application - intranet, internet, dial-up, etc, as shown below. When you create a load test, you might want to simulate that load is being generated through more than one type of network connection. A network profile is a simulation of network bandwidth at the application layer. It does not simulate latency.

Next, you specify what to monitor when performing the load test as shown below. You can specify what computers to monitor - controller, agent computers and other computers - hosts of your application - and then what results to gather, which is done by specifying performance counters for each computer.

And finally, you can specify run settings as shown below. You can have more than one run setting in a load test. Only one of the run settings may be active for a load test run, only because the run settings are a set of properties that influence the way a load test runs. You specify test run duration or the maximum number of request and response details of failed requests to store, or the highest level of validation rule that will run in a load test (validation rule are associated with web test requests and if this run setting is set to Medium, all validation rules marked as medium or low will be run).

By clicking Finish button you close the wizard and you can see the load test window as below with all the options that have been added.

Next, you can run the test and observe results - either as graphs or records in a table. Here you can see all monitored counters and any threshold validations.

That gives you a very good idea how your system will perform under going live with more realistic load than a few developers and testers. And although performing those kind of tests should be done by testers, the reality shows something else - that that's not the case in vast majority of situations. Most often testers are only knowledgeable to do functional testing and most complex testing like load testing of a large web application can only be done by a professional developer, especially in smaller companies where there are no testes at all.  That's why each professional enterprise application developer should know how to use load tests not only to pass the 70-565 exam but to know how to test an application before going live to provide the best quality of service and return on investment by avoiding problems in production.

The most common automated tests that developers write are of course Unit Tests, but Visual Studio offers more than Unit Testing. Unit tests are perfect for testing your business and data access layer, but not really good for testing presentation layer. Making sure that your business objects return valid results is one but making sure that your web application can correctly display the results, or authenticate a user, or process a request with other requests being processed at the same time, or redirect to other pages as required (ie. error page), etc. is actually what really should be tested because that's the layer of the application a user interacts with and by making sure that your business object can return a correct result a developer cannot guarantee that the application can correctly display that result. That's why there are Web Tests, which are part of Visual Studio 2008 Test Edition and Team Suite Edition. The benefits of using Web Tests are:
You can create Web tests for use in an extensive set of testing purposes:

• Create functional tests that exercise your Web applications.
• Create data-driven tests.
• Create and run tests that can test the performance of your applications.
• Use .NET languages for test authoring, debugging, and test extensibility.

• Hidden field correlation including VIEWSTATE
• Redirects
• Dependent requests
• Authentication
• Security through HTTPS/SSL

One of the 70-565 exam topics is Designing and Developing an Application Framework and it looks like 25% of all questions are about designing and developing an application framework. If to read what the topic covers, you find that there are questions about defining the interaction between framework components, which is defining data APIs, security APIs, abstract classes, class interfaces, and data contracts. There's been plenty of posts and discussion whether to use interfaces or abstract classes, but I noticed that there isn't enough with regard to implementing an interface, which is whether an interface should be implemented implicitely or explicitely. Those are two choices presented by IntelliSense to implement an interface as shown below.

• interface method/property is not accessible from the class object as it were private. In the example above, rule object of type EmailRule cannot call Evaluate method, but has to be cast to the interface type first: (rule as IRule).Evaluate
• interface method/property cannot be abstract or virtual, which means that a class that explicitely implements an interface must provide the implemention of the method and that implemention cannot be overriden or marked as abstract so it can be provided by classes that inherit from the abstract class

Unit testing is something that most developers are familiar with and a lot of companies also require writing them. The idea of unit testing is to test the smallest testable part of the application, but only part that is public - public properties and public methods. Anything that is non-public cannot be utilized from outside so it can be tested when testing the public member, so the unit tests should be written the way to cover the code that touches private, internal or protected members. That is especially true if you do the Test-Driven Developement. However, sometimes it is valid to test those non-visible members when the number of tests to write in that scenario is significantly smaller than normally a developer would have to write the test those members via public members, which is most common in large or complex applications. This post is not intended to demonstrate the pros and cons of testing non-public members and whether such practice should be avoided or followed, but to demonstrate how to perform those tests if needed or required. Below is a class library project with one class that has all non-public members and a separate test project with a normal unit test.
[Demo.cs]

The class has private and public constructor, private, protected and internal fields and methods and a private class with a private field. The test purpose will be to have ability to access all those members, which can be done in few ways:

• using Microsft.VisualStudio.TestTools.UnitTesting.PrivateObject class. PrivateObject requires a type and it uses reflections to access all members, so it doesn't require any other operations and works with any Visual Studio edition that has UnitTesting Framework.
  
  
  
  Below is the unit test for the Demo class using PrivateObject class.
  [PrivateObject_Test.cs]
  
• using PrivateAccessor. PrivateAccessor is an assemly with a target class with all its members made as public. The assembly name is TargetAssemblyName_Accessor.dll. It can be created straight from IDE (requires Visual Studio 2008 Professional or higher) or from command line using Publicize.exe tool. Once the assembly has been referenced within a test unit project, unit tests can access and validate all members of the target class, which within the accessor assembly has a name TargetClass_Accessor. Below is the unit test for the Demo class using the PrivateAccessor, and if to compare this code with the code above, tesing with PrivateAccessor is more elegant but such tests are executed against an accessor class / accessor assembly, which is not the class / assembly that will be delivered to the user plus any changes in a target class also require regenerating the accessor assembly so a developer must be extra cautious when using the private accessor to make sure that he/she is testing the right verions of a class / assembly.
  [PrivateAccessor_Test.cs]
  

• protected members - create a class within a unit test and have that class inherit from the base class and output the results via public property.
• internal members - add InternalsVisibleToAttribute either to AssemblyInfo.cs file in or your class with internal members. The attribute requies the assembly name with the unit tests to which the internal members will be made visible i.e. [assembly:InternalsVisibleTo("Exam_70_565.UnitTests.ClassLibrary.Test")]

One of the topics on the 70-565 exam is "Stabilizing and Testing an Application" and about 17% of questions on the exam cover that topic. I don't know how many questions are there on the exam but if it is 50, then testing, code review and resolving a bug should appear on about 9 questions. When reading the exam skill measured tab on the Microsoft web site, one can notice that it mentions only performance, functional and integration testing. It doesn't even mention unit testing. And there's a few other test types that I think every enterprise application developer should be familiar with and as always they might appear in some questions on the exam.

• ACCEPTANCE TESTING - testing to verify a product meets customer specified requirements. A customer usually does this type of testing on a product that is developed externally
• BIG BANG INTEGRATION TESTING - In big bang Integration testing, individual modules of the programs are not integrated until every thing is ready. This approach is seen mostly in inexperienced programmers who rely on 'Run it and see' approach. In this approach, the program is integrated without any formal integration testing, and then run to ensures that all the components are working properly.
• BLACK BOX TESTING - testing without knowledge of the internal workings of the item being tested. Tests are usually functional
• BOTTOM-UP TESING - In bottom up integration testing, module at the lowest level are developed first and other modules which go towards the 'main' program are integrated and tested one at a time. Bottom up integration also uses test drivers to drive and pass appropriate data to the lower level modules. As and when code for other module gets ready, these drivers are replaced with the actual module. In this approach, lower level modules are tested extensively thus make sure that highest used module is tested properly.
• COMPATIBILITY TESTING - testing to ensure compatibility of an application or Web site with different browsers, OSs, and hardware platforms. Compatibility testing can be performed manually or can be driven by an automated functional or regression test suite
• CONFORMANCE TESTING - testing to verify implementation conformance to industry standards
• FUNCTIONAL TESTING – testing to validate an application or Web site conforms to its specifications and correctly performs all its required functions. This entails a series of tests which perform a feature by feature validation of behavior, using a wide range of normal and erroneous input data. This can involve testing of the product's user interface, APIs, database management, security, installation, networking, etc. Funcitonal testing can be performed on an automated or manual basis using black box or white box methodologies
• INTEGRATION TESTING - testing in which modules are combined and tested as a group. Modules are typically code modules, individual applications, client and server applications on a network, etc. Integration testing follows unit testing and precedes system testing
• LOAD TESTING - load testing is a generic term covering Performance Testing and Stress Testing
• PERFORMANCE TESTING - performance testing can be applied to understand your application or WWW site's scalability, or to benchmark the performance in an environment of third party products such as servers and middleware for potential purchase. This sort of testing is particularly useful to identify performance bottlenecks in high use applications. Performance testing generally involves an automated test suite as this allows easy simulation of a variety of normal, peak, and exceptional load conditions
• REGRESSION TESTING -Similar in scope to a functional test, a regression test allows a consistent, repeatable validation of each new release of a product or Web site. Such testing ensures reported product defects have been corrected for each new release and that no new quality problems were introduced in the maintenance process. Though regression testing can be performed manually an automated test suite is often used to reduce the time and resources needed to perform the required testing
• SMOKE TESTING - a quick-and-dirty test that the major functions of a piece of software work without bothering with finer details. Originated in the hardware testing practice of turning on a new piece of hardware for the first time and considering it a success if it does not catch on fire
• STRESS TESTING - testing conducted to evaluate a system or component at or beyond the limits of its specified requirements to determine the load under which it fails and how. A graceful degradation under load leading to non-catastrophic failure is the desired result. Often Stress Testing is performed using the same process as Performance Testing but employing a very high level of simulated load
• SYSTEM TESTING - testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing falls within the scope of black box testing, and as such, should require no knowledge of the inner design of the code or logic
• TOP DOWN INTEGRATION TESTING - is an incremental integration testing technique which begins by testing the top level module and and progressively adds in lower level module one by one. Lower level modules are normally simulated by stubs which mimic functionality of lower level modules. As you add lower level code, you will replace stubs with the actual components. Top Down integration can be performed and tested in breadth first or depth firs manner.
• UNIT TESTING - functional and reliability testing in a development environment. The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect. Each unit is tested separately before integrating them into modules to test the interfaces between modules. Unit testing has proven its value in that a large percentage of defects are identified during its use.
• WEB TESTING - A Web test, also called a declarative Web test, consists of a series of HTTP requests. Web tests work at the protocol layer by issuing HTTP requests. Web tests are used to test the functionality of Web applications and to test Web applications under load. Web tests, although useful by themselves, are also used in load tests, which allow for aggregating several Web tests to simulate a real user load on your Web site
• WHITE BOX TESTING - testingbased on an analysis of internal workings and structure of a piece of software. Also known as Structural Testing and Glass Box Testing

As always before studying for the exam, I usually look for some tips from those who have taken the exam. As always I googled it, but this time I couldn’t find much information. The exam is not very popular plus there is no self-paced training kit book so there are no book reviews whether the book is sufficient for the exam or what parts are missing, which usually gives me a hint what to expect on the exam. Here are the few web sites I found that describe the exam:

• how-to-prepare-70-565-net35
• exam-70-565-prep-guide
• 70-565-passed
• how-to-pass-70-565-mcpd-enterprise-application-developer

• Learning UML 2.0
• Learning WCF
• Professional ASP.NET 3.5: In C# and VB
• Pro .NET 2.0 Windows Forms and Custom Controls in C#
• Distributed Application Developer Self-Paced Training Kit 70-529 (I took that exam)
• Patterns of Enterprise Application Architecture
• The Art of Unit Testing: With Examples in .Net
• Design Patterns: Elements of Reusable Object-Oriented Software
• Microsoft Application Architecture Guide 2.0
• Performance Testing Guidance for Web Applications
• Microsoft Integration Pattern
• Improving .NET Application Performance and Scalability
• Enterprise Solution Patterns using Microsoft.Net
• Deploying .NET Framework-Based Applications
• Improving Web Services Security: Scenarios and Implementation Guidance for WCF

My two previous posts described how to extend a basic behavior of controls without changing them. Ajax control extenders add Ajax/JavaScript behavior to controls and control adapters can provide different rendering for controls without changing them. One of the disadvantages of control extenders is that they can extend only 1 control, so there is 10 controls to extend, 10 extenders must be added to a page. And if we want to add an extender to each control (we want to extend) in the whole ASP.NET application, we would have to go through all pages and add a lot of code. That would be definitely tedious and could take a lot of time if an application has many pages. But that's where control adapters come in handy. We would need to create an adapter for the control being extended and override CreateChildControls method to generate ControlExtender markup and add it to as a child the control. Make sure that if the adapter overrides the Render and RenderChildren method, it calls the RenderChildren method from an override of the Render method. Of course it is not very common to add extenders to every single control type within a Web application (especially because Ajax Control Extenders require Ajax ScriptManager on a page so we would need to make sure that one is present on the page that contains a control to which an extender will be added), but there might be situations that it would be desirable. For developers who are not aware of this solution that would mean a lot of tedious work so most probable that task would either not be accomplished as someone would decide that it wouldn't be worth so much resources (time and money) or would take a lot of time (and money). In situations like that you can really see the difference between a developer for whom developing is a mere means of earning money and a thriving developer for whom it is also a hobby and excitement.

It was last week when I took the 70-564 exam and I passed with the score 985/1000. It looks like I got 1 question wrong. Nevertheless, I have earned Microsoft Certified Professional ASP.NET 3.5 Developer title.

• there is 50 (!) questions (70-503 (WCF) exam also has 50 questions but on the other hand 70-505 (Windows Forms 3.5) exam has only 40 questions) and 120 minutes
• questions are not harder than those for 70-562 exam, so if you can pass that exam, you can pass this one
• there is very few questions on Ajax - MCTS ASP.NET 3.5 exam (70-562) had about 10 questions on Ajax but this one maybe 3 or 4. Also I think 1 question was exactly the same as I had at 70-562 exam
• there is a lot of questions on state management, which is in line with the exam objectives (Manage state of controls and Design a state management strategy).
• main focus of questions is to test the ability to identify appropriate usage, so in oder words 70-562 exam requires a tester to know how to use something  whereas 70-564 exam requires to know when to use something or which one to use in this scenario. 
• the most crucial aspect at the exam is to read questions very carefully - most questions will contain a list of requirements that almost all answers will meet but there will, of course, only 1 answer (unless it is multiple choice question) that will meet every single requirement and every single word in all the requirements. 
• very often requirement(s) will contain a comma separated list ie.types of files or activities so make sure that answers will satisfy all elements from the list(s). 

When reviewing for the 70-564 exam  I did some practice with Control Adapters and more specifically ASP.NET Web Control Adapters and Page Adapters. It reminded me that not many .NET Web developers are aware of their existence, even though control adapters have been available since .NET 2.0. Of course it doesn't mean that every Web application must utilize a control adapter but in certain scenarios they might save a lot of time required to accomplish the same task without using control adapters. Simply, control adapters are controls that inherit from System.Web.UI.Adapters.ControlAdapter base class. Moreover, control adapters for ASP.NET Web Controls inherit from System.Web.UI.WebControls.Adapters.WebControlAdapter base class and ASP.NET page control adapters inherit from System.Web.UI.Adapters.PageAdapter base class. They are all abstract classes so to create a control adapter, one must inherit them. Control adapters adapt or modifies behavior at key points in the life cycle of the control for which a control adapter has been created. At each stage in the life cycle, where a call to a life cycle method is made, the ASP.NET page framework checks to see if there is an associated adapter for the control and calls on the adapter's associated method instead of the control's method. In many cases, the adapter method may simply defer back to the control's method. An exception to this behavior are adapters for state management in that the adaptive behavior is additive to the control's state. Control adapters are most commonly used to provide target-specific processing during a specific stage of the control life cycle or to customize target-specific rendering. WebControlAdapter class have additional several methods that are specific to rendering tags. PageAdapter class is the starting point for rendering a Web page adaptively. Additionally, the PageAdapter class defines properties and methods that enable adaptive rendering in the context of typical page-level tasks, such as caching or managing page-state persistence. So simply control adapters are a way of providing different renderings for controls without actually modifying the controls themselves. Because control adapters are designed to provide alternate renderings for different clients, you specify control adapter mappings in a .browser file, which is where associations between User Agent strings and browser capabilities are defined. Browser files can be added either in the local App_Browsers directory of an ASP.NET Web application or in the machine-wide %SYSTEM%\Microsoft.NET\Framework\v2.0.50727\Config\Browsers directory. Even though control adapters are associated with a specific browser type, they can be added to the Default.browser file and hence be applied to all clients. Below is an example of creating and using a page adapter, but the same rules apply for creating any control adapter.
ViewStatePageAdapter.cs

using System.Web.UI.Adapters;

using System.Web.UI;

public class ViewStatePageAdapter:PageAdapter 

{

public override PageStatePersister GetStatePersister()

{

return new SessionPageStatePersister(this.Page);

}

protected override void Render(HtmlTextWriter writer)

{

base.Render(writer);

writer.RenderBeginTag(HtmlTextWriterTag.Div);

writer.Write("Copyright 2009");

writer.RenderEndTag();

}

}

<browsers>

<browser refID="Default">

<controlAdapters>

<adapter controlType="System.Web.UI.Page"

adapterType="ViewStatePageAdapter" />

</controlAdapters>

</browser>

</browsers>

public partial class _Default : System.Web.UI.Page 

{

protected override void OnPreRenderComplete(EventArgs e)

{

this.ClientScript.RegisterClientScriptBlock(

this.GetType(),

"DisplayViewState",

"<script>window.status=('ViewState: ' + document.forms[0]['__VIEWSTATE'].value.length + ' bytes');</script>");

}

}

<%@ Page Language="C#" AutoEventWireup="true"  CodeFile="Default.aspx.cs" Inherits="_Default" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head runat="server">

<title>View State Page Adapter Test</title>

</head>

<body>

<form id="form1" runat="server">

<div>

<asp:GridView ID="GridView1" runat="server" DataSourceID="AdvantureWorks" 

AllowPaging="True" AutoGenerateColumns="False" DataKeyNames="EmployeeID" 

PageSize="50" CellPadding="4" ForeColor="#333333" GridLines="None">

<RowStyle BackColor="#EFF3FB" />

<Columns>

<asp:BoundField DataField="EmployeeID" HeaderText="EmployeeID" 

InsertVisible="False" ReadOnly="True" SortExpression="EmployeeID" />

<asp:BoundField DataField="NationalIDNumber" HeaderText="NationalIDNumber" 

SortExpression="NationalIDNumber" />

<asp:BoundField DataField="ContactID" HeaderText="ContactID" 

SortExpression="ContactID" />

<asp:BoundField DataField="LoginID" HeaderText="LoginID" 

SortExpression="LoginID" />

<asp:BoundField DataField="ManagerID" HeaderText="ManagerID" 

SortExpression="ManagerID" />

<asp:BoundField DataField="Title" HeaderText="Title" SortExpression="Title" />

<asp:BoundField DataField="BirthDate" HeaderText="BirthDate" 

SortExpression="BirthDate" />

<asp:BoundField DataField="MaritalStatus" HeaderText="MaritalStatus" 

SortExpression="MaritalStatus" />

<asp:BoundField DataField="Gender" HeaderText="Gender" 

SortExpression="Gender" />

<asp:BoundField DataField="HireDate" HeaderText="HireDate" 

SortExpression="HireDate" />

<asp:CheckBoxField DataField="SalariedFlag" HeaderText="SalariedFlag" 

SortExpression="SalariedFlag" />

<asp:BoundField DataField="VacationHours" HeaderText="VacationHours" 

SortExpression="VacationHours" />

<asp:BoundField DataField="SickLeaveHours" HeaderText="SickLeaveHours" 

SortExpression="SickLeaveHours" />

<asp:CheckBoxField DataField="CurrentFlag" HeaderText="CurrentFlag" 

SortExpression="CurrentFlag" />

<asp:BoundField DataField="rowguid" HeaderText="rowguid" 

SortExpression="rowguid" />

<asp:BoundField DataField="ModifiedDate" HeaderText="ModifiedDate" 

SortExpression="ModifiedDate" />

</Columns>

<FooterStyle BackColor="#507CD1" Font-Bold="True" ForeColor="White" />

<PagerStyle BackColor="#2461BF" ForeColor="White" HorizontalAlign="Center" />

<SelectedRowStyle BackColor="#D1DDF1" Font-Bold="True" ForeColor="#333333" />

<HeaderStyle BackColor="#507CD1" Font-Bold="True" ForeColor="White" />

<EditRowStyle BackColor="#2461BF" />

<AlternatingRowStyle BackColor="White" />

</asp:GridView>

<asp:SqlDataSource ID="AdvantureWorks" runat="server" 

ConnectionString="<%$ ConnectionStrings:AdventureWorks %>" 

SelectCommand="SELECT HumanResources.Employee.* FROM HumanResources.Employee">

</asp:SqlDataSource>

</div>

</form>

</body>

</html>

Before .NET 3.5 to extend a control meant usually to inherit from a base control and add extra functionality or create a custom control that would contain a control to extend with additional items ie. javascript. But .NET 3.5 introduced another way to extend a control, which is through Ajax Control Extender, but I have experienced that still many developers are not aware of that fact and still use either inheritance (in java keyword extends is equivalent of keyword inherits in VB.NET or ":" in C#) or create a custom control where they could take advantage of ExtenderControl class. That class enables you to programmatically add AJAX functionality (or simple javascript) to an ASP.NET server control. Since it's not based on inheritance, there is no limitation of extending only unsealed controls.Also one extender may extend different types of controls (TextBox, Button, MyTextBox, etc.) - before it would require creating custom class for each type of controls being extended. I believe that's why AjaxControlToolkit contains so many control extenders ie. SliderExtender, RoundedCornersExtender or ModalPopupExtender. But even though there always will be a business need (or rather functional requirement) to create a custom control extender ie. FocusExtender that will apply different css style whenever a target control gets focus and reverts it back to the default css style when a target control has lost focus. Plus target control can be any type of control - TextBox, Button, DropDownList, etc.
Control extender is created by creating a new project of type: ASP.NET Ajax Server Control Extender.

using System;

using System.Collections.Generic;

using System.Web.UI;

namespace Extenders

{

[TargetControlType(typeof(Control))]

public class FocusExtender : ExtenderControl

{

protected override IEnumerable<ScriptDescriptor>

GetScriptDescriptors(Control targetControl)

{

ScriptBehaviorDescriptor desc = new ScriptBehaviorDescriptor(

"Extenders.FocusBehavior", targetControl.ClientID);

desc.AddProperty("onFocusCssClass", OnFocusCssClass);

desc.AddProperty("defaultCssClass", DefaultCssClass);

yield return desc;

}

protected override IEnumerable<ScriptReference>

GetScriptReferences()

{

ScriptReference sRef = new ScriptReference();

sRef.Name = "Extenders.FocusBehavior.js";

sRef.Assembly = this.GetType().Assembly.FullName;

yield return sRef;

}

public string OnFocusCssClass

{

get

{

String s = (ViewState["OnFocusCssClass"] as String);

return s ?? "";

}

set

{

ViewState["OnFocusCssClass"] = value;

}

}

public string DefaultCssClass

{

get

{

String s = (ViewState["DefaultCssClass"] as String);

return s ?? "";

}

set

{

ViewState["DefaultCssClass"] = value;

}

}

}

}

Type.registerNamespace('Extenders');

Extenders.FocusBehavior = function(element)

{

Extenders.FocusBehavior.initializeBase(this, [element]);

this._onFocusCssClass = null;

this._defaultCssClass = null;

this._focusHandler = null;

this._blurHandler = null;

}

Extenders.FocusBehavior.prototype =

{

initialize : function()

{

Extenders.FocusBehavior.callBaseMethod(this, 

'initialize');

var e = this.get_element();

this._focusHandler = Function.createDelegate(

this, this._onFocus);

this._blurHandler = Function.createDelegate(

this, this._onBlur);

$addHandler(e, 'focus', this._focusHandler);

$addHandler(e, 'blur', this._blurHandler);

},

dispose : function()

{

var e = this.get_element();

if (this._focusHandler)

{

$removeHandler(e, 'focus', this._focusHandler);

this._focusHandler = null;

}

if (this._blurHandler)

{

$removeHandler(e, 'blur', this._blurHandler);

this._blurHandler = null;

}

Extenders.FocusBehavior.callBaseMethod(this, 'dispose');

},

_onFocus : function(evt)

{

var e = this.get_element();

if (e != null)

{

e.className = this._onFocusCssClass;

}    

},

_onBlur : function(evt)

{

var e = this.get_element();

if (e != null)

{

e.className = this._defaultCssClass;

}

},

get_defaultCssClass : function()

{

return this._defaultCssClass;

},

set_defaultCssClass : function(value)

{

this._defaultCssClass = value;

this.raisePropertyChanged('defaultCssClass');

},

get_onFocusCssClass : function()

{

return this._onFocusCssClass;

},

set_onFocusCssClass : function(value)

{

this._onFocusCssClass = value;

this.raisePropertyChanged('onFocusCssClass');

}

}

Extenders.FocusBehavior.registerClass('Extenders.FocusBehavior', Sys.UI.Behavior);

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>

<%@ Register Assembly="Extenders" Namespace="Extenders" TagPrefix="MI" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head runat="server">

<title>Untitled Page</title>

<style type="text/css">

.Normal

{

background-color: White;

color:Black;

font-weight:normal;

}

.Highlight

{

background-color: Blue;

color:White;

font-weight:bold;

}

.HighlightButton

{

background-color: Yellow;

color:Red;

font-weight:bold;

}

</style>

</head>

<body>

<form id="form1" runat="server">

<div>

<asp:ScriptManager ID="ScriptManager1" runat="server" />

Username:

<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>

Password:

<asp:TextBox ID="TextBox2" runat="server" TextMode="Password"></asp:TextBox>

<asp:DropDownList ID="DropDownList1" runat="server">

<asp:ListItem>Value1</asp:ListItem>

<asp:ListItem>Value2</asp:ListItem>

</asp:DropDownList>

<asp:Button ID="Button1" runat="server" Text="Button1" />

<MI:FocusExtender ID="focusExtender1" runat="server" TargetControlID="TextBox1" OnFocusCssClass="Highlight"

DefaultCssClass="Normal" />

<MI:FocusExtender ID="focusExtender2" runat="server" TargetControlID="TextBox2" OnFocusCssClass="Highlight"

DefaultCssClass="Normal" />

<MI:FocusExtender ID="focusExtender3" runat="server" TargetControlID="DropDownList1"

OnFocusCssClass="Highlight" DefaultCssClass="Normal" />

<MI:FocusExtender ID="focusExtender4" runat="server" TargetControlID="Button1" OnFocusCssClass="HighlightButton"

DefaultCssClass="Normal" />

</div>

</form>

</body>

</html>