Protect Your ASP.NET App From SQL Parameter Injection

Securing your ASP.NET web app from SQL Injection attacks paramount in the design of any ASP.NET app. Say you are viewing a transaction of customer #448, andyour URL looks something like What is to stop customer 448 from typing in 449,  and viewing another customer’s transaction details? The situation can even escalate into typing in complete SQL statements and executing them inside the original statements you have coded.  Checking for let’s say a customer sessionID and matching it against the URL and the page will still have to be done by the app developer. This article will demonstrates a simple method of protecting against SQL Injection attacks by checking  for valid parameters in an existing ASP.NET application which can be used in any website. The main idea behind this technique is very simple and includes three components.

The Validation Class
This class contains static methods to check for valid values. For example, if you are expecting a string that is twenty characters long,it can check it for you and notify the application every time itencounters an invalid string on any page. There are several methods implemented in the example code. However, you can add your own and customize them to your needs.

This is the file where you keep all of your application keys. So for example, if we would like to check for a customerID and make sure it is an integer, we would add a key named <safeParameters> and set its value to orderID-int32. Now every time our application will encounter an orderID parameter it will automatically check to see if it has a valid integer value.

This file will contain a utility method to match all of our known parameter types to their value. This method will be called isValidParameter. Every time a page is being requested, this method will be executed and will then notify the application if the parameteris valid.

The idea behind these three components working together to prevent SQL Injection attacks  is very simple: prepare all your utility methods to check for valid parameters, define all your valid parameters and check for valid values on each page, take into consideration that if you are using a customerID in twenty pages on your application, they all must be of an integer value. Plugging these components into your application is fairly simple and will ensure that an already   running website will prompt you every time a hacker tries to change a query string regardless of whether your programmers have checked for valid parameters or not. Bear in mind that this is a plug-in, and like all plug-ins it will take its toll on your application performance. A truely secure application will embed any security methods inside the page object only using utility classes to assist. However, if invalid parameters are a problem for you, then this is a good solution.

How to Implement the Example:

Step 1: Add a new utility class and copy and paste the code in parameterCheck.cs into it. Do not forget to change the namespace to fit the needs of the application.

 public class parameterCheck{
public static bool isEmail(string emailString){
return System.Text.RegularExpressions.Regex.IsMatch(emailString,
public static bool isUSZip(string zipString){
return System.Text.RegularExpressions.Regex.IsMatch(zipString ,"^(\d{5}-\d{4})|(\d{5})$");

Step 2: In the Web.config file, add a key under the <appSettings> tag. This key will contain all of the parameters you wish to check for and the types they need to be. The name of the key is <safeParameters>, and the value can be for example: ordered-int32,customerEmail-email.

<add key="safeParameters" value="OrderID-int32,CustomerEmail-email,ShippingZipcode-USzip" />

Step 3: In your Global.asax copy and paste the code in the example into your Application_BeginRequest method.


ASP.NET Session State Best Practices

Session state is an integral part of many ASP.NET apps but it can also be a drag on performance or result in application errors if used inappropriately. Here are our ASP.NET Session State best practices to ensure you won’t be tripped up by any gotchas:

  • Do not overuse Session State for user data storage.
    One of the problems with Session State is that it is so convenient for user data storage – just store anything using Session["someName"] = someName.Text . This leads developers to overuse Session State and store data that would be better handled by another technique (for example, you can use ASP.NET Membership Profiles to store and retrieve user settings, or use caching for storing miscellaneous items).
  • Try to avoid storing complex objects in Session State.
    Session Sate can store objects of any type (including objects you create) however, they are stored by serializing and then de-serializing them which results in a big performance penalty. If possible try to only store ‘basic’ types such as Integer, Decimial, String, DateTime, GUID etc
  • Use an Out of Process mode if possible
    Session State provides for three configuration modes – In Process, Out of Process using stateview and Out of Process using SQL Server.
    In Process stores the session state data in memory with the same process as the application, this has the advantage of being the fastest mode but it also means that all session data is lost when the app restarts. The app restart is more common than many developers believe, in addition to server and IIS restarts any change in the web.config or global.asax file will restart the app and all session state data can be lost.
    Out of Process (stateserver) stores the session data in memory but in a different process, if you are running a web farm this can even be on a separate machine. Out of Process (SQLServer) stores the session data in SQL Server which is the most stable as it will be recoverable in all scenarios except a database failure but it is also the slowest. Both Out of Process modes protect the session data from loss due to an app restart.
  • Do not store sensitive data in Session State.
    SessionID’s which identify user sessions are sent in clear text and can be intercepted by nefarious users. Once a user’s SessionID has been obtained, data stored in the Session State associated with that SessionID can be easily accessed. Thus you should avoid using Session State to store sensitive data or use SSL or encryption of the data to protect it.
  • Allow users to log out of an application
    You should allow users to log out of the app, upon logon the app should call the Abandon method. This will reduce the scope for a malicious user to get hold of  the unique identifier in the URL and then use it for retrieving user data stored in session state.

ASP.NET Security Tutorial

Securing an ASP.NET application is paramount for any project. Here (in no particular order), in this tutorial we present the primary ASP.NET security best practices:

  • Ensure system patches are fully up-to-date
    Not really an ASP.NET specific best practice but since ASP.NET relies on the underling OS for its operation it is essential to ensure the OS to fully patched with the latest security updates.
  • Secure all connection strings
    Typically an app’s database will stored its most sensitive data so preventing unauthorized reading of the connection string is a must. The connection string should be stored in the web.config file and not in the code behind for pages and also not in the SqlDataSource control or other data source controls. For maximum security encrypt sensitive settings in config files – see Encrypt Connection Strings in ASP.NET for details.
  • Use parameterized queries or stored procedures instead of creating SQL commands by concatenating strings.
    It is possible to generate   the SQL for a command by building strings like below:

    SQLCmdStr = "Select * from users where username =' " & usernameTxt.Text  & "'

    This however allows for the possibility of SQL injection attacks by users directly typing SQL commands into text boxes which are then executed. Instead you can use a parameterized query as below:

    SQLCmdStr = “Select * from Users where Lastname =@LastName”
    SQLCmd.Parameters.Add(New SQLParameter(“@LastName”, ddl.SelectedItem.text))
  • Encrypt any sensitive data stored in View State
    View State is sometimes used to stored sensitive data sure as user names or even account numbers. Since View State is posted back to the server on every postback this data could be intercepted and read, therefore when any sensitive data is stored in View State the the page’s ViewStateEncryptionMode property should be set to true.
  • User input validation
    Always validate user input on the server even if it has been validated on the client since a user can easily bypass most client side validation by turning off javascript. The below code shows how to use Regex on the server-side to valid input:
  • using System.Text.RegularExpressions ;
    // Instance method:
    Regex regObj = new Regex(@"^[a-zA-Z'.\s]{1,40}$");
    // Static method:
    if (!Regex.IsMatch(Request.QueryString["InputName"],@"^[a-zA-Z'.\s]{1,40}$"))
       // Name does not match expression

    Note that user input does not only come from values input by the user on a form on the page. ASP.NET apps also take data form QueryStrings and cookies, these must also be validated in the same manner as input data.


5 Ways HTML5 can Speed Up Your ASP.NET Application

Html5 is often touted as a great solution for delivering multi-platform apps, but the performance boost of using Html5 in existing applications is often overlooked. Here we present 5 ways for you to use Html5 (plus CSS3 of course !) to boost the performance of your ASP.NET and ASP.NBET MVC apps.

  1. Use Html5 Input Types and Form Attributes
    One of the most common tasks in developing a web app is setup the input forms which will normally include client side validation (for example to ensure a valid email was input) , range restrictions (for example a minimum bid amount) and watermarks (ie textboxes with pre-input grayed-out text). This is normally implemented using javascript, ASP.NET simplifies many of these tasks by providing attributes for the ASP.NET TextBox however this is implemented in the final html by auto-generated javascript. This is results in a lot of extra page load and can complicated the debugging.
    Fortunately Html5 includes pre-defined input types such as email which performs many of these functions. For example, a textbox which only accepts an email address and has a placeholder (watermark) of “email address” would be

    <input type="email" placeholder="email address" />

    The are numerous input types included in Html5, a good example of these in operation is at Html5 Forms Demo

  2. Use CSS3 Instead of Images
    Images are often used for styling web elements, such as rounded corners, buttons, gradients, text effects (such as 3D or inset text). CSS3 provides support for all of these out-of-the-box so you page will no longer have to request and load images. With the introduction of IE9, all major browsers now support for these CSS3 properties, although it should be noted that rendering them in mozilla and webkit based browsers (such as Safari and Chrome) requires slightly different CSS code.
    See CSS Performance with Fewer Images for a full listing of all the available CSS3 styles to replace images.


ASP.NET ViewState Security

ASP.NET ViewState data is stored in a single Base64-encoded string  such as  this:

id="__VIEWSTATE" value="dDw3NDg2NdTI5MDg7Ozr4="/>

Since this value is not formatted in clear text, developers sometimes assume that their ViewState data is encrypted which is most certainly not the case. This data string can be reverse-engineered this and then viewed. This is an obvious security issue if sensitive data is being stored in ViewState.

To make ViewState secure, there are two choices, hash codes and ViewState encryption.

Use a hash code.

A hash code  is a cryptographically strong checksum. When you use a has code, ASP.NET calculates the checksum based on the current ViewState content data and then adds this to the hidden input field when the page  when is returned to the client.  On the page post back, ASP.NET then recalculates the checksum to  ensures a  match. If a malicious user were to  change the ViewState data, ASP.NET can detect the  the change reject the postback.
Hash codes are enabled by default,  however, sometimes developers elect  to disable hash codes to prevent problems on a web farm when  servers have different keys. Hash codes can be disabled on the page in the .aspx file’s Page directive:

<%@ Page EnableViewStateMac="false" ... %>

To disable hashing site-wide use the  ViewStateMac attribute of the pages  element in  web.config :

<pages enableViewStateMac="false" />

For more on hashing, please refer to C# Security – Hashing

Use ViewState Encryption.

Hash codes help to prevent ViewState data from being tampered with but they do not provide much assistance in preventing ViewState data from being read since hash codes can still be converted to clear text. To prevent ViewState being read, use the  ViewState Encryption, which can be turned on at the page level using the ViewStateEncryptionMode property of the Page directive:

<%@Page ViewStateEncryptionMode=”Always” … %>

Or site-wide in the web.config file:

<pages viewStateEncryptionMode=”Always” />

There are three settings for viewStateEncryptionMode:

  1. Always : All ViewState data is encrypted.
  2. Never : No ViewState data is encrypted.
  3. Auto : Data is only encrypted when specifically requested by the ASP.NET control.

The default setting is Auto so no data will be encrypted unless otherwise requested by a control on a page. For a control to request encryption in needs to call the Page.RegisterRequiresViewStateEncryption() method before it is rendered to HTML.

Note that using encryption incurs a performance penalty so it should only be used when necessary.

ASP.NET Control State for Custom Server Controls

State management is a perennial challenge for any web development framework – once a page is refreshed any data on the page (such as text already entered in textboxes) must be persisted using some method. Traditionally ASP.NET solves this problem using View State which inserts text directly into the html of the page which can then be read by the server when the page is posted to the server. This solution works well in most circumstances but the one major issue is performance – View State adds a large payload to each page request and will slow the ASP.NET site/app down. The issue is especially acute when using ASP.NET AJAX since there are numerous background hits on the server and each of which needs to contain the full View State payload.

Control State is designed to be a much more lightweight store of data than view state . Control State is designed to store   data a control is currently using. Technically, control state works in the same manner as view state—storing serializable data that’s placed in a hidden field when a page is rendered. ASP.NET actually puts   view state and control state data into the same hidden field. The only major difference is that control state is unaffected by the EnableViewState property, therefore even if EnableViewState is set to false, acontrol can still store and retrieve data from  control state.

Since control state cannot be disabled, you will need to  carefully restrict the amount of information stored. Normally, it is limited to something critical such as the current page index or else a data key value. To use control state in  a custom server control, you   begin by overriding the OnInit() method and the calling Page.RegisterRequiresControlState() to notify ASP.NET that the control needs to access control state.

protected override void OnInit(EventArgs e)

Unlike view state, control state cannot be accessed  directly through a collection and you must override two methods:  LoadControlState() and SaveControlState(). These methods use a slightly irregular pattern. The overall idea is that you need to take any control state which has been serialized by the base class and then combine that with an object which contains your new serializable object. You can do this using the System.Web.Pair class, as shown below:

string myData;
protected override object SaveControlState()
// Get state from the base class.
object baseStateObj = base.SaveControlState();
// Combine  with the state object you wish to store
// and then return the final object.
return new Pair(baseStateObj, myData);

This technique will enable you to only store  a single object. For storing several items of information, consider creating a custom class which encapsulates all these details (and ensure it includes the Serializable attribute). An alternative method is to  create a chain of Pair objects:

private string strData;
private int integerData;
protected override object SaveControlState()
// Get state from the base class.
object baseStateObj = base.SaveControlState();
// Combine with the state objects you want to store,
// and return the final object.
Pair pairA = new Pair(strData, integerData);
Pair pairB = new Pair(baseStateObj, pairA);
return pairB;


WCF Tracing

After deploying application a proper troubleshooting policy should be ready in order to perform maintenance activity of our project life cycle. Here we will see different tools available from Microsoft within visual studio in order to manage, configure, debug and troubleshoot WCF service after deployment. Note that if you are unfamiliar with WCF, please read my WCF Tutorial .

WCF Tracing can track all the events or only specified events in the program. Tracing is built upon the System.Diagnostics namespace of the .NET Framework. The Debug and Trace classes under this namespace are responsible for debugging and tracing purpose.

Tracing is turned off by default and needs to be enabled   to start using tracing. We can enable tracing by two ways. One is through code and another is from config file. Enabling tracing in configuration is the optimal method since we can easily turn it on and off as required. When debugging  is  no longer required we should turn tracing enable off.

Enabling Tracing

The following code snippet will enable tracing through configuration file:


<trace autoflush="true" />


<source name="System.ServiceModel"



<add name="TraceListeners"


initializeData= "c:\Log\trace.svclog"/>





In this example, the name and type of the trace listener is specified. The Listener is named TraceListeners and the standard .NET Framework trace listener (the native format for the tool - System.Diagnostics.XmlWriterTraceListener) is added as the type. The initializeData attribute is used to set the name of the log file for that Listener. Here the fully qualified file name is used as “c:\Log\trace.svclog”.

Tracing Levels:

Tracing Levels:
The tracing level is controlled by the switchValue setting. The available tracing levels are described below:

SL. No


Tracked Events

Content of the Tracked Events



No traces are emitted.



Out of memory exception, Stack overflow exception, Application start
errors, System hangs, Poison messages



All exception are logged

Unexpected processing has happened. The application was not able to
perform a task as expected. However, the application is still up and running.



Timeout exceeded, Credential rejected, throttling exceeded, receiving
queue nearing capacity

A possible problem has occurred or may occur, but the application
still functions correctly. However, it may not continue to work properly.



Channels and endpoints created, message enters/leaves transport, configuration
read, general helpful information

Important and successful milestones of application execution,
regardless of whether the application is working properly or not.



Debugging or application optimization

Low level events for both user code and servicing are emitted.


Activity Tracing

Tracing for transfers, activity boundaries, start/stop

Flow events between processing activities and components.



All listed events

Application may function properly. All events are emitted.

Trace Sources:

WCF defines a trace source for every assembly. Traces generated within an assembly are accessed by the listeners which are defined for that source. The below trace sources are defined:

  • System.ServiceModel: Logs all stages of WCF processing, whenever the configuration is read, a message is processed in transport, security processing, a message is dispatched in user code, and so on.
  • System.ServiceModel.MessageLogging: Logs all messages that flow through the system.
  • System.IdentityModel: Logs data for authentication and authorization.
  • System.ServiceModel.Activation: Logs the activity of creating and managing service hosts.
  • System.IO.Log: Logging for the .NET Framework interface to the Common Log File System (CLFS).
  • System.Runtime.Serialization: Logs when objects are read or written.
  • CardSpace: Logs messages related to any CardSpace identity processing that occurs within WCF context.


WCF Performance Tuning

WCF was introduced to overcome the constraints of previous distributed technologies like ASP.NET Web Services, WSE, .NET Enterprise Services and .NET Remoting and to provide a performance boost in addition. For an introduction to WCF please read my first WCF article - WCF Tutorial .

Performance is a central goal for web or app site, expecially since Google now includes site responsiveness a factor in their ranking algorithm.  For ASP.NET optimization tips, please see  my article titled 50 Tips to Boost ASP.NET Performance.  In this article I will  discuss   WCF performance tuning techniques.

Use DataContractSerializer:

Serialization  is the process of converting an object instance into a portable and transferable format.   Xml Serialization  is popular for its interoperability and binary Serialization  is more useful for transferring objects between two .NET  applications.

System.Runtime.Serialization.DataContractSerializer is   designed for WCF but can also be used for general serialization. The DataContractSerializer has some benefits over XmlSerializer:

  1. XmlSerializer can serialize only properties but DataContractSerializer can serialize fields in addition to  properties.
  2. XmlSerializer can serialize only public members but DataContractSerializer can serialize not only public members but also private and protected members.
  3. In performance terms,  DataContractSerializer is approximately 10% faster than XmlSerializer.

Select proper WCF binding:

System-provided WCF bindings are used to specify the transport protocols, encoding, and security details required for clients and services to communicate with each other. The below are the available  system-provided WCF bindings:


A binding   suitable for communication with WS-Basic Profile conformant Web Services such as ASMX-based services. This binding uses HTTP as the transport and Text/XML for message encoding.

2. WSHttpBinding:

A secure and interoperable binding   suitable for non-duplex service contracts.

3. WSDualHttpBinding:

A secure and interoperable binding  suitable for duplex service contracts or communication through SOAP intermediaries.

4. WSFederationHttpBinding:

A secure and interoperable binding that supports the WS-Federation protocol, enabling organizations that are in a federation to efficiently authenticate and authorize users.

5. NetTcpBinding:

A secure and optimized binding suitable for cross-machine communication between WCF applications

6. NetNamedPipeBinding:

A  reliable, secure, optimized binding suitable for on-machine communication between WCF applications.

7. NetMsmqBinding:

A queued binding suitable for cross-machine communication between WCF applications.

8. NetPeerTcpBinding :

A binding which enables secure, multi-machine communication.

9. MsmqIntegrationBinding :

A binding that is suitable for cross-machine communication between a WCF application and existing MSMQ applications.

In this context Juval Lowry has presented a nice decision making diagram:

WCF Performance Tuning

It should be noted that WCF also allows us to define our own custom bindings.

Use Tracing:

Tracing can track all the events or specified events in a  program. By default it is off. For debugging purposes we have to make enable it explicitly either through code or using a config file setting which is preferable. If  debugging is not required we should disable tracing. For more details reader can read my article titled “Tracing in WCF”.

Close Proxy:

The proxy represents a service contract. It provides the same operations as service’s contract along with some additional methods for managing the proxy life cycle and the connection to the service. It is a recommended best practice to always close the proxy when the client is finished using it. When we close the proxy, the session with the service is terminated and the connection is closed as well and thus can serve to process new requests in better way.

It should be noted that calling a proxy in a using statement (see the below code snippet) is actually not the optimal  or safest method.

using (ServiceProxy proxyClient = new ServiceProxy())
The above code will be translated to something as follows:
    ServiceProxy proxyClient = new ServiceProxy();
                if (proxyClient != null)

The problem with this method is that proxyClient.Dispose() will throw an exception when the proxy is in a faulted state .So to close the proxy even under faulted state the below is the suggested approach:

ServiceProxy proxyClient = new ServiceProxy();
                if (proxyClient.State != System.ServiceModel.CommunicationState.Closed)


Throttling is a way of mitigating potential DoS (denial of service) attacks. Using ServiceThrottlingBehavior we can set smooth loading and resource allocations on the server. In WCF, there are three service-level throttles that are controlled by ServiceThrottlingBehavior.

1. MaxConcurrentCalls: The maxConcurrentCalls attribute lets us specify the maximum number of simultaneous calls for a service. When the maximum number of simultaneous calls has been met and a new call is placed, the call is queued and will be processed when the number of simultaneous calls is below the specified maximum number. The default value is 16.

2. MaxconcurrentSessions: The maxconcurrentSessions attribute specifies the maximum     number of connections

to a single service. The channels below the specified limit will be active/open. It should be noted that this throttle is effectively disabled for non-sessionful channels (such as default BasicHttpBinding).The default value is 10.

3. MaxConcurrentInstance: The maxConcurrentInstance attribute specify the maximum number of simultaneous service instances. While receiving new instance request the maximum number has already been reached, the request is queued up and will be completed when the number of instances is below the specified maximum. The default value is total of the two attributes maxConcurrentSessions and maxConcurrentCalls.

From general feedback it is has been noted that the default settings for the above mentioned three attributes are very conservative and are insufficient in real production scenarios and thus developers need to increase those default settings.

Hence Microsoft has increased the default settings in WCF4.0 as follows:

1. MaxConcurrentSessions: default is 100 * ProcessorCount

2. MaxConcurrentCalls: default is 16 * ProcessorCount

3. MaxConcurrentInstances: default is the total of MaxConcurrentSessions and MaxConcurrentCalls

Now we have a new parameter which is the multiplier “ProcessorCount” for the settings. The main reason for this is that we do not need to change the settings in deployment from a low end system to a multiple processor based system. The value for MaxConcurrentSessions is also increased from 10 to 100.


There are three types of quotas in WCF transports:

1. Timeouts. Timeouts are used for the mitigation of DOS attacks which rely on tying up resources for an extended period of time.

2. Memory allocation limits: Memory allocation limits prevent a single connection from exhausting the system resources and denying service to other connections.

3. Collection size limits: Collection size limits restrict the consumption of resources which indirectly allocate memory or are in limited supply.

As per MSDN the transport quotas available for the standard WCF transports: HTTP(S), TCP/IP, and named pipes are

as follows:




Min Value

Default Value






1 min

Maximum time to wait for a connection to

close before the transport will raise an exception.





8 KB

Size in bytes of the transmit and receive

buffers of the underlying transport.  Increasing this buffer size can

improve throughput when sending large messages.





5 Min

Maximum lifetime of an active pooled

connection.  After the specified time elapses, the connection will close

once the current request is serviced.

This setting only applies to pooled






2 Min

Maximum time a pooled connection can remain

idle before being closed.

This setting only applies to pooled connections.






Maximum number of unserviced connections

that can queue at an endpoint before additional connections are denied.





512 KB

Maximum amount in bytes of memory that the

transport will devote pooling reusable message buffers.  When the pool

cannot supply a message buffer, a new buffer is allocated for temporary use.

Installations that create many channel

factories or listeners can allocate large amounts of memory for buffer

pools.  Reducing this buffer size can greatly reduce memory usage in

this scenario.





64 KB

Maximum size in bytes of a buffer used for

streaming data.  If this transport quota is not set or the transport is

not using streaming, then the quota value is the same as the smaller of the

MaxReceivedMessageSize quota value and Integer.MaxValue.





Maximum number of incoming connections that

can be serviced.  Increasing this collection size can improve

scalability for large installations.

Connection features such as message

security can cause a client to open more than one connection.  Service

administrators should account for these additional connections when setting

this quota value.

Connections waiting to complete a transfer

operation can occupy a connection slot for an extended period of time.

Reducing the timeouts for send and receive operations can free up connection

slots quicker by disconnecting slow and idle clients.






Maximum number of outgoing connections that

can be associated with a particular endpoint.

This setting only applies to pooled






200 ms

Maximum time to wait after a send operation

for batching additional messages in a single operation.  Messages are

sent earlier if the buffer of the underlying transport becomes full.

Sending additional messages does not reset the delay period.






Maximum number of channels that the

listener can have waiting to be accepted.

There is an interval of time between a

channel completing an accept and the next channel beginning to wait to be

accepted.  Increasing this collection size can prevent clients that

connect during this interval from being dropped.





64 KB

Maximum size in bytes of a received

message, including headers, before the transport will raise an exception





1 Min

Maximum time to wait for a connection to be

established before the transport will raise an exception.





1 Min

Maximum time to wait for a read operation

to complete before the transport will raise an exception.





1 Min

Maximum time to wait for a write operation

to complete before the transport will raise an exception.

Without  proper settings of quotas (see the below configuration settings) the exceptions will rise which may cause to terminate the service.


Other quotas of the ReaderQuotas property that can be used to restrict message complexity to provide protection from denial of service (DOS) attacks, these are:

  1. MaxDepth: The maximum nested no depth per read. The default is 32.
  2. MaxStringContentLength: The maximum string length allowed by the reader.  The default is 8192.
  3. MaxArrayLength: The maximum allowed array length of data being received by WCF from a client. The default is 16384.
  4. MaxBytesPerRead: The maximum allowed bytes returned per readThe default is 4096.
  5. MaxNameTableCharCount: The maximum characters in a table name. The default is 16384.


Windows Communication Foundation ( WCF ) Tutorial

In this WCF tutorial we introduce the primary reasons for moving from other technologies to WCF as well as how to get started using WCF. Prior to .Net 3.0 it was not an easy matter to select a particular technology for communicating between systems due to the number of technologies available from Microsoft. For example, users could have used Web Service to communicate between a Java based application and a .Net application; WSE users could have take advantage of some of the WS-* message protocols; MSMQ has the ability to queue messages which helps to communicate between intermittently connected solutions; Enterprise services (the successor of COM+) helps to build distributed application easily; .Net Remoting is a fast way to move messages between two .NET applications. All the above mentioned technologies have their pros and cons. Using WCF now we can take the advantage of all the above distributed technologies in a unified manner and WCF is the successor to all these message distribution technologies.

Performance comparison between distributed technologies:

When we migrate distributed applications made with ASP.NET Web Services, WSE, .NET Enterprise Services and .NET Remoting to WCF, it will in almost all cases result in a performance boost:

Other Distributed Technologies WCF Performance Advantage
ASP.NET Web Service 25%—50% faster
.NET Remoting 25% faster
WSE 2.0/3.0 implementations. 400% faster
.NET Enterprise Service 100% faster subject to the load.

Whereas the other Microsoft distributed technologies do not have too many limitations in running on Windows operating system, an application built with WCF can run only on Windows XP SP2, Windows Vista or Windows Server 2008.

In the next part of our WCF tutorial we take a more indepth look at WCF and how to get started using it.

Programming Model

A WCF service is made up of three parts: the service, one or more endpoints and a hosting environment.

A service is basically a class written in a .Net compliant language which contains some methods that are exposed through the WCF service. A service may have one or more endpoints – an endpoint is responsible for communication from the service to the client.
Endpoints also have three parts which are known as ‘ABC’: ‘A’ for Address, ‘B’ for Binding and ‘C’ for Contracts.

Address: Address specifies the info about where to find the service.

Binding: Binding specifies the info for how to interact with the service.

Contracts: Contracts specifies the info for how the service is implemented and what it offers.

Finally a hosting environment where the service is contained.

WCF bindings: System-provided WCF bindings are used to specify the transport protocols, encoding, and security details required for clients and services to communicate with each other. As per MSDN followings are the system-provided WCF bindings:

< BasicHttpBinding: A binding that is suitable for communication with WS-Basic Profile conformant Web Services like ASMX-based services. This binding uses HTTP as the transport and Text/XML as the message encoding.

A secure and interoperable binding that is suitable for non-duplex service contracts.

WSDualHttpBinding: A secure and interoperable binding that is suitable for duplex service contracts or communication through SOAP intermediaries.

WSFederationHttpBinding: A secure and interoperable binding that supports the WS-Federation protocol, enabling organizations that are in a federation to efficiently authenticate and authorize users.

A secure and optimized binding suitable for cross-machine communication between WCF applications

A secure, reliable, optimized binding that is suitable for on-machine communication between WCF applications.

A queued binding that is suitable for cross-machine communication between WCF applications.

NetPeerTcpBinding :
A binding that enables secure, multi-machine communication.

MsmqIntegrationBinding :

MsmqIntegrationBinding: A binding that is suitable for cross-machine communication between a WCF application and existing MSMQ applications.

It should be noted that WCF also allows us to define our own custom bindings.

Creating a WCF service

In order to create a WCF service in Visual Studio, select WCF>WCF Service Library from the New Project dialog.

This will create the several files in a new project. Apart from the AppConfig file there are two more files – Service1.cs and IService1.cs . Service1.cs is an implementation of the IService1.cs interface.

Working with the Interface:

We need a service contract to create a new service. The service contract is the interface of the service. It consists of all the methods which are exposed along with input parameter(s) and return value.

Interface IService1.cs:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.Serialization;
using System.ServiceModel;
using System.Text;

namespace WcfServiceLibrary1
    public interface IService1

        int Addition(int x,int y);

        Customer GetDataUsingDataContract(Customer cust);


    public class Customer
        String name;
        string contactNo;

        public string Name
            get { return name; }
            set { name = value; }

        public string ContactNo
            get { return contactNo; }
            set { contactNo = value; }


In the following class we can see that interface IService1is implemented.