How to make ASP.NET 3rd party controls run faster
How to make ASP.NET 3rd party controls run faster
Join the DZone community and get the full member experience.Join For Free
xMatters delivers integration-driven collaboration that relays data between systems, while engaging the right people to proactively resolve issues. Read the Monitoring in a Connected Enterprise whitepaper and learn about 3 tools for resolving incidents quickly.
The following document will explore the basics of enhancing 3rd party ASP.NET components performance by leveraging the Empty Client (an ASP.NET extension) pipeline.
1.1 What is the Empty Client?
This architecture is an emerging open source methodology which offers a different approach to architecting, developing and deploying AJAX applications. In order to shed some light on this methodology, we will compare it to the classic Thin and Thick (also referred to as Fat or Smart) client approach and to traditional AJAX structures.
VWG centralized Ajax pipeline
It also achieves the highest scalability and performance that, in the past, were enabled only with the Thick client approach. It is called the Empty Client because it doesn’t run any logic or data manipulation on the client, it doesn’t expose data or logic, nor does it require exposing web services consumed by the client, which is a very common non-secure practice on traditional AJAX development methods. It is also referred to as Clever Client because with this approach the UI control’s process is an integral part of the control just like a single layered desktop control only pided into the control rendering part (on the client) and the control’s logic part (on the server); it executes on top of traditional and standard web platforms and creates the feeling of a native client-side application that usually run as Thick or Fat client only with a Thin client footprint. The Empty Client differs from the Thin client also because it runs on any plain browser with no plug-ins and it does not transfer bitmaps. Thus, by allowing central computing with the strong processing power that clients typically have today the Empty Client really offers the best of both worlds.
This document is targeted towards software architects and advance developers who would like to learn the basics of ASP.NET controls upgrade to become Empty Client native controls.
This document describes the general process of migration; reading this document should make it possible for the reader to estimate the amount of work required to wire-up and transform an existing ASP.NET control into a native, functional equivalent Empty Client control.
Important Note: This document does not replace a detailed developers’ guide of the upgrade tasks, although, it should provide general understanding of how Empty Client controls are built, what parts are reusable when upgrading ASP.NET controls and what parts should be adjusted or recreated.
1.4 General and essential assumptions
- This document assumes that the reader has the source code for the components you are migrating in and that you are legally allowed to use it.
- This document assumes that the reader has basic knowledge on custom controls creation for the ASP.NET platforms.
- This document assumes that the reader has some basic web architecture understanding as well as familiarity with the major different browsers on the market.
1.5 Empty Client standard development tool
Empty Client applications are coded using standard .NET languages (C#.NET/VB.NET) and utilize the productive proven VB6 and WinForms development paradigm to develop generic web applications including WYSIWYG form designer and a web designated theme designer which makes it possible to customize web controls look & feel as well as behaviors.
1.6 Web / ASP.NET extension
Empty Client replaces the pipeline protocol and creates a new pipeline; however purely based on the standard ASP.NET technology. It uses ASP.NET including its base objects (Server, Session, Application, Request and Response), deployed on standard IIS (no server installation required) and the code is parsed by the standard .NET CLR.
This constitutes the following benefits:
- Interactive with any ASP.NET application (including mutual containment)
- Any ASP.NET control can be Wrapped in by a click of a button
- Interacts with any other web technology
- Reduces risks in terms of infrastructures and use known and proven MS underlying technologies.
- XCopy deployment
2. Why bother upgrading controls to native Empty Client?
2.1 Increasing demand for VB 6.0 and WinForms upgrade
Plain Web is the most preferred deployment model due to a centralized application deployment efforts and the ability to consume application everywhere.
WinForms applications are starting to find their ways to the web. The Empty Client is the only technology out there that can run WinForms compliant code over web without having to rewrite the code and being able to leverage almost 100% of the legacy code investments.
The source WinForms applications often use third party controls so the migration process often needs to supply replacements for those controls. The migration project’s engineers and architect always prefer a native Empty Client control over wrapping-in an external control.
Recent Microsoft announcements to stop supporting VB 6.0 have increased the market request for VB 6.0 application modernization. However they all want to end-up with a web application rather than a desktop one – even if based on .NET. Here too, the source VB 6.0 apps often use third party controls and so that the migration process often needs to supply replacements for those controls. The migration project’s engineers and architect always prefer a native Empty Client control over wrapping-in an external control.
2.2 Rapid development paradigm
Using the most proven and intuitive rapid development patterns, Empty Client – Visual WebGui framework makes it possible for developers from a wider skill levels range to develop complex high-end line of business applications.
- Truly WYSIWYG, drag & drop Form based designer
- Simple data-binding using Visual Studio standard desktop-like UI
- Controls and themes point & click designer
- Events handling as simple as VB 6.0 or WinForms development
And many more…
2.3 Performance (benchmarked)
Empty Client unique runtime and pipeline, runs up to 10 times faster than any other traditional ASP.NET components which can be concluded by the following graphs collected by performance specialist MS MVP Mr. Wiktor Zychlah:
Received and sent data
Requests per second
2.3.1 Low bandwidth consumption
Having balanced presentation state both on the client and on the server, Empty Client apps’ optimized protocol transfers much less data between the client and the server. Latest benchmarks indicate consumption of around 10% of traditional ASP.NET Ajax based equivalent applications.
2.3.2 Largest number of concurrent users
Empty Client state-full architecture, result in much less CPU consumption on the server (< 50%) due to the ability of the server to immediately run the event handling code on the live state. Furthermore, the fact that there is no need for mass objects’ constructions and disposals on the server dramatically reduced the CPU usage.
The Empty Client paradigm is secured by-design due to the fact that nothing except for UI commands and one static kernel is downloaded to the client. This means that:
- No sensitive/hidden data is sent to the client. Neither the infrastructure nor the developers can perform security violations by sending sensitive data to client machines.
- The server exclusively handles interaction with data and other services.
- The client is responsible to render UI and send events to the server; in any case it can never control the server’s behavior.
- Each client request is validated by the single layer server code which constitutes a single point access control center.
2.5 Scalability and deployment economy
Empty Client is fully scalable and redundant across web farms due to a unique capability of enabling serialization of the entire state model into a floating state server (preferably cluster DB based state server). A single IIS server can server between 200-400 concurrent users and even more since it reduces the CPU usage dramatically.
2.6 Multiple presentation layers support
One of the outcomes of Empty Client architecture is a generic object model that is completely separated from UI rendering. This architecture which is often described as decoupled presentation layer provides the ability to render the UI and consume the application practically from any device which can receive and send XML.
The application itself runs on the server and acts on objects containing only metadata and data and the client only renders the UI as reflected from the current application state on the server.
2.7 Cloud optimized architecture
Empty Client enables the heaviest organization’s desktop apps on the cloud with no UI compromises and at no-cost. Being a highly optimized server-centric architecture; Empty Client has high value and support the model of cloud computing scenarios in terms of compatibility and optimizations considerations.
2.8 Controls & Themes design and extensibility model
Being pure web architecture, Empty Client utilizes the web server and client technologies underneath; therefore, it is possible to create new controls based on the same concepts and set of tools. Customization and extensibility features:
- Theme designer – enables visual point & click editing of themes/skins.
- Control level designer – enables visual point & click editing & creation of new controls (inherited or from scratch)
- Wrapping in new ASP.NET based controls (i.e. Infragistics, Telerik, DevExpress, ComponentOne, Syncfusion etc.)
3. Empty Client control
3.1 Controls’ structure
An Empty Client control consists of:
- Server-side part written in .NET and represents its entire API and set of server-side events (which are the default ones in the Empty Client concept.
3.2 How does it work?
The following diagrams show the runtime flow of Empty Client.
The first one shows the flow of the initial request that the client performs to the server, while the second one shows the normal flow throughout the application run.
- Initial Request Scenario
• The Kernel contains the controls’ client codes and some common protocol mechanisms.
• The Context object reside within the IIS/ASP.NET session and holds the relevant state of the currently active tree of controls according to the current shown state of the user in the application.
• The server is responsible to serve the Kernel resources for download according to the specific requesting browser/device.
- Runtime Flow Scenario
• At runtime, the client renders the deltas of the entire view using a combined XSLT assembled from all the common XSLTs and control specific XSLTs, according to the commands sent from the server.
• The client sends over highly optimized queue of events according to which the server runs the relevant event handlers.
3.3 The server part of the control
The server-side code of each control contains most of its code:
- Rich set of event handlers
- Desktop like set of properties
- All sorts of Calculations
- Data-binding code
- Most of the validations
- Render-Attributes code (part of the protocol - will be explained further in this document)
- Designer specific code
- ShouldSerzlize methods (code dom supportive)
- “DesignTime” forked behaviors
- Specific Editors and design behaviors (Located in separate classes)
Following is an edited (shortened) sample code from within Button.cs (a thorough description of each part follows this piece of code):
public enum ButtonStyle
/// The Button control
[ToolboxBitmapAttribute( typeof(Button), "Gizmox.WebGUI.Forms.Button.bmp")]
[DesignTimeController("Gizmox.WebGUI.Forms.Design.ButtonController, …, …")]
[SilverlightControl("Gizmox.WebGUI.Silverlight.Controls.BindableFlat…,… ")] [SilverlightControl("Gizmox.WebGUI.Silverlight.Controls.Bindable…,…,…")]
public class Button : Control, IButtonControl
/// Reference to the images list
private ImageList mobjImageList = null;
/// Creates a new <see cref="Button"/> instance.
/// Fires an event.
protected override void FireEvent(IEvent objEvent)
// disable button after click when ClickOnce property is true
if (this.ClickOnce && objEvent.Type == "Click")
this.EnabledInternal = false;
// invoke base method
/// Renders the attributes to be sent to the client
///<param name="objContext">The current context</param>
protected override void RenderAttributes(IContext objContext, IAttributeWriter objWriter)
base.RenderAttributes (objContext, objWriter);
// add attributes to conterol element
// Set text align attribute
// Get image.
ResourceHandle objImage = this.Image;
if (objImage != null)
// add attributes to control element
// render context menu if needed
// render ClickOnce attribute
[DefaultValue(-1), RefreshProperties(RefreshProperties.Repaint), SRDescription("ListViewItemImageIndexDescr"), Localizable(true), SRCategory("CatBehavior")]
public int ImageIndex
if (mintImageIndex != value)
mintImageIndex = value;
mstrImageKey = string.Empty;
/// Gets or sets the text.
public override string Text
if(base.Text != value)
base.Text = value;
/// Gets or sets the alignment of the image on the button control.
public ContentAlignment ImageAlign
menmImageAlign = value;
/// Code dom: Shoulds the serialize image.
protected bool ShouldSerializeImage()
return (mobjImage != null);
Above each control’s server-side class there are a few attributes that describe the mapping of the different designers and tool-box items, Empty Client client-side resources tag name and mappings to other presentation layer’s resources; i.e. the matching Silverlight client control.
The FireEvent() function which overrides the base Control’s method, maps the types of the events which are relevant for this control to the actual server event handlers that should be raise accordingly.
This method is part of the Empty Client protocol. It provides the set of properties that the client needs to receive in order to render or re-render this control entirely.
The first line of code in this method is the an invocation of the base class’s RenderAttributes method since the “dynasty” of base classes (Control and Component) contain many common attributes which are not control specific.
In some controls there is a mode of partially rendering of the controls, this method is called RenderUpdatedAttributes, most of the events will not end up fully rendering the controls or even partially but rendering only the deltas according to the minimal set of changes required. This behavior is an integral part of the Empty Client client-server protocol algorithm.
Properties and Methods
The set of methods and properties define the UI logic/behavior and the component’s API. Those methods and properties are similar in nature to a single layered control (such as WinForms).
Should Serialize Methods
Those are designer related properties, which define the Code DOM what properties should be serialized within the automatically generated InitializeComponents code and in what conditions.
3.4 The client part of the control
The client-side code of each control consists of:
- Multi-browser supportive CSS (represents a dynamic styling format).
- Multi-browser supportive XSLT document (represents the transformation to plain HTML).
- The client-side code of each control contains the following pieces of code:
// Get the pressed key
var intKeyCode = Web_GetEventKeyCode(objEvent);
// Check if enter or Spacebar was pressed.
if (intKeyCode==mcntEnterKey || intKeyCode==mcntSpaceKey)
//raise the click event
- The naming format of function, i.e. Button_KeyPress reflects the name of the file ‘_’ its descriptive name (significant functionality description). This way the line:
Invokes the method Click within the Events code file.
- Multi-browser supportive CSS (represents a dynamic styling format); follows is an edited and shortened version of ButtonSkin.Button.css.
border:transparent 1px solid;
- It is rapidly noticeable that the file is assembled of standard CSS classes and parameters.
- The parameters are collected and filled by the first time that the client approaches the server.
- All of the CSSs together are served within a single flat and size optimized CSS file.
- Multi-browser supportive XSLT document (represents the transformation to plain HTML); follows follows is an edited and shortened version of ButtonSkin.Button.xslt:
<!-- Draws the content of a flat button -->
<!-- Apply button attributes -->
<!-- Draw button frame -->
<!-- Draws the content of a normal button -->
<!-- Disable styles that are not used in button -->
4. Upgrade of ASP.NET based controls to Empty Client
In this section the general process of migrating ASP.NET controls into Empty Client will be described. The following steps will be described and further explained:
- Copy the server code into a Visual WebGui .cs file.
- Analyze the control and move all the UI logic to the server.
Step 1: Copy the server code into a Visual WebGui .cs file start adding the RenderAttributes method
Open a Visual WebGui project and then a new class and copy the ASP.NET server code to it. Most of the server UI behavior code is reusable in this level.
The object model should align to the Empty Client object model, which is actually an extended form of the WinForms object model. For instance, each component should inherit the “Component” class if it has no UI expression or inherit “Control” class if it has a UI expression. This object model is best described here: http://msdn.microsoft.com/en-us/library/system.windows.forms.aspx.
Furthermore, in this step should start planning and adding the RenderAttributes method, the basic purposes of this method and a small sample is found under the “Server-side part of the control” section of the “Control’s structure” chapter above.
Step 2: Analyze the control and move all the UI logic to the server
Although it is possible to add client-side code into Visual WebGui or use the client-client invocation methodology it is still a server centric architecture by-default. In order to preserve the secured and responsive nature of Empty Client native controls, it is much recommended to move at least all of the non-frequent events to the server and add support for client-client invocation mechanism in order to provide the end developer the ability to choose between client handled event code and server handled event code.
Adjusting the existing XSLT and HTMLs should be transformed into Visual WebGui compliant XSLT. Applying many of the control’s properties will be a very simple task using the common templates in Visual WebGui as shown in the code bellow:
<!-- Draw the button content -->
In the Button’s control partial XSLT above; two common templates are being used (applied) from the Visual WebGui’s available common templates:
- Styles (tplApplyStyles) applying the dynamic definitions within the style HTML attributes which are required for styling aspects in the button contents.
- Padding (tplApplyPaddings) applying the dynamic definitions within the style HTML attributes which are required for padding aspects in the button contents.
In the process of choosing what existing code is reusable, you should think of the following guidelines:
- ASP.NET Ajax callbacks should be replaced with Visual WebGui’s standard pipeline calls
- It is recommended that the Visual WebGui naming standards would be kept in order for the internal kernel compiler to perform an efficient variables scoping.
- It is highly recommended to replace common libraries with Visual WebGui internal services (samples are shown below).
// Get the pressed key
var intKeyCode = Web_GetEventKeyCode(objEvent);
// Executig selection of list item
ListView_Select(strGuid, strId, objWindow, Web_IsShift(objEvent), Web_IsControl(objEvent), true);
// Handles the click event and forces raise Web_OnClick(objEvent,objWindow, true);
In the code sample above:
- Data_IsCriticalEvent method verifies if this event is considered a critical event according to the current server code and control’s definitions.
- Web_OnClick method is responsible to raise an actual click event through Visual WebGui pipeline.
// Exit on disabled control
// Get the multiselect attribute.
var objNode = Data_GetNode(strGuid);
var blnMultiple = Xml_IsAttribute(objNode,"Attr.Multiple","1");
In the code sample above:
- Data_IsDisabled method figures out if the control is disabled of not.
- Data_GetNode method retrieves the updated xml node of a specified control from the “state behind” (client-side state).
- XML_IsAttribute method checks the value of an attribute within the “state behind” (client-side state) xml node.
Existing CSSs can be reused almost as is, the only consideration here would be whether the imported control should be theme-able or not. If it is, the parameters method, as shown bellow should conform to Empty Client standards.
In the code sample bellow, taken from the ListView CSS file, it is shown that most of the CSS attributes are dynamically created by the server through the object model once the current theme is downloaded to the client. There are a few constant attributes:
Opinions expressed by DZone contributors are their own.