Enumerate the Steps for creating a Shared Assembly

Step 1: Generate a Strong Name Key:

D:\Project\DLL\sn -k dll.snk

The above statement will write a Kay pair to dll.snk file

Step 2: Associate the Strong Name Key with source code

Step 2.1: Create a program to be used as DLL - First.cs

using System;
using System.Reflection;

public class Employee
public string Data()
return "Anuj Ranjan";

a) Save the file as First.cs in D:\Project\DLL\First.cs
b) Compile the program to create a DLL from the Command Prompt as given below:

D:\Project\DLL>csc /t:library First.cs

c) The above statement will create a DLL named First.dll, with the strong name key in it.

Step 2.2: Create another program to implement the DLL - Second.cs

using System;

public class Trial
public static void Main()
Employee e = new Employee();

Save the file as Second.cs in D:\Project\Implement\Second.cs

Step 3: Install the DLL in GAC

D:\Project\DLL\GACUTIL -i First.dll

GACUTIL is a command which is used to install a strong named dll in the Global Assembly Cache.

Step 4: Add the reference of the DLL in the program

D:\Project\Implement\csc /r:d:\Project\DLL\First.dll Second.cs

Step 5: Execute the program


Fundamental Windows Communication Foundation Concepts

WCF programming model consists of a runtime and a set of APIs and is used for creating systems that communicate (sends and receives messages) between clients and services.

Messaging and Endpoints

The main concept of WCF is Message–Based Communication. In the programming model anything that can can be modeled as a message (an HTTP request, a Message Queuing – MSMQ, etc), can be represented in a uniform way. This concept enables a unified API across contrasting transport mechanisms.

A client is an application which initiates a communication, while a service is an application which responds to the client's request. However, the client and the service may not be necessarily different applications, a single application may in fact act both as a client and a service (Duplex Services and Peer–to– Peer Networking).

As Endpoints are points or spots for message exchange, they define all the information required to facilitate message exchange. A WCF service can expose single or multiple endpoints (application endpoints or infrastructure endpoints or both). The client generated endpoint should be compatible with one of the service's endpoints.

Endpoints describe the address (location of the endpoint where the messages should be send), binding (how a client can communicate with the endpoint by sending messages), contracts (form of the message) and behaviors (local implementation details of the endpoint). This information can be exposed by the service as metadata, that can be processed to generate appropriate WCF clients and communication stacks.

Communication Protocols

The two elements required in the communication stack is given below:
  • Transport protocol – Messages can be exchanged over the internet using common protocols such as HTTP and TCP. Protocols that support communication with Message Queuing applications and nodes on a Peer Networking mesh are also included.
  • Encoding mechanisms – Encoding mechanisms specify the format of a message. Following encoding mechanisms are provided by WCF:
    a) Text encoding – this is an interoperable encoding.
    b) Message Transmission Optimization Mechanism (MTOM) encoding – this is an interoperable way for efficiently sending unstructured binary data to and from a service.
    c) Binary encoding – this is implemented for efficient transfer.
Note: Even more encoding mechanisms (for example, a compression encoding) can be added using the built-in extension points of WCF.

Message Patterns

Amongst the several messaging patterns supported by WCF, the most common Message Exchange Patterns include Request–Reply, One–Way, and Duplex. The variety of interactions supported by different protocols depends on the fact that they support different Message Exchange Patterns (MEX).

The messages exchanged in WCF is secure and reliable (a feature of WCF APIs and runtime).

Conversion of Seconds to Hours:Minutes:Seconds format

Recently I faced a requirement of converting seconds to Hours:Minutes:Seconds format. After some R&D, I found the following solution:


DECLARE @in_seconds int

SET @in_seconds = 3661 -- One Hour One Minute and One Second

SELECT CONVERT(CHAR(8), DATEADD(SECOND, @in_seconds, 0), 108) As Hour_Minute_Second



Note: This SQL code is applicable only for time less than 24 hours.

Message Patterns in WCF Services

Client applications and WCF services communicate by passing XML messages. Message Exchange Patterns illustrate how clients and services communicate by passing messages. There are three message exchange patterns supported by WCF:

·         Request – Reply Message Exchange Pattern
·         One – Way Message Exchange Pattern (also called Datagram)
·         Duplex Message Exchange Pattern (also called Callback)

Request – Reply Message Exchange Pattern

After sending message to a WCF service, a client application waits for the reply in Request – Reply pattern. This is the default and classic pattern for both WCF and Web Services. Since the client has asked a question, and it expects an answer, it waits for the service to send a message back containing the answer.

The Request – Reply message exchange pattern is used when a client requests a service to perform an action, and it needs some confirmation. Fault exception is handled in Request – Reply pattern. The Request – Reply pattern is the most used message exchange pattern.

In Request – Reply Message Exchange Pattern, only the client can initiate a communication with the service.

One – Way Message Exchange Pattern

The One – Way Message Exchange Pattern is also known as Datagram or Fire and Forget. This pattern is used when a client requests the service to take an action but it does not need any confirmation. Thus neither the service sends a reply message not the client waits for a reply. A client sends a message (request) to a WCF service but the service does not send a reply message to the client. The client does not wait for the reply and proceeds with other processing work. Some scenario’s for one-way pattern includes logging in and out, maintenance tasks, heads down data entry and other repetitive tasks etc.

An implication of using one – way pattern is that even if a method call fails due to an exception or invalid data, the service does not notify the client. If the client needs to be notified about the failure of the service request, then this pattern should not be used. This pattern should be used when the client does not need to wait for a reply from the WCF service.

In One – Way Message Exchange Pattern, only the client can initiate a communication with the service.

Duplex Message Exchange Pattern

The Duplex Message Exchange Pattern is also known as Callback. Both the client and the service can initiate a communication in the duplex pattern. It can be used for transactions. The client calls the service, which after processing the request, callbacks the client with the reply. In the meanwhile, instead for waiting for the reply (as in Request – Reply pattern), the client proceeds with other tasks.

This pattern should be used when the client (after the client has called the service) expects a notification or alert from the WCF service.

Note: The One – Way and Duplex patterns provides opportunities to fine-tune the performance of applications and to add more flexibility regarding what happens after a client calls a service.

The presence of One – Way and Duplex patterns in WCF is a major advantage of WCF over Web Services.