VS 2008 by Mehul

Finding which column belongs to which table from database MsSql

2008-09-06T23:13:00.001+05:30

Finding a column from the database

select * from syscolumns where name ='empid'

Finding an object from database

Select * from sysobjects where name='employee'

Finding the table name to which the column belongs

select * from sysobjects where id in(select id from syscolumns where name like'empid%'

Getting displayed the columns and tables to gather

Select a.name, b.name from sysobjects a, syscolumns b

Where a.id = b.id

Fuzzy Mathematics: Fuzzy Logic, Fuzzy Sets, Fuzzy Numbers.

2008-05-26T18:15:00.001+05:30

In this Chapter we will take a good long look at fuzzy logic, and a brief look at fuzzy sets and fuzzy numbers. (Later chapters will look more deeply into fuzzy sets and fuzzy numbers.)

1.1 Fuzzy Logic.

In conventional logic, a statement is either true or false, with nothing in between. This principle of true or false was formulated by Aristotle some 2000 years ago as the Law of the Excluded Middle, and has dominated Western logic ever since.

Fuzzy logic offers a better way of representing reality. In fuzzy logic, a statement is true to various degrees, ranging from completely true through half-truth to completely false.

The basic idea of multi-valued logic has been explored to some extent by a number of mathematicians in this century, but the real breakthrough was made by Prof. Lotfi Zadeh of the University of California in Berkeley. In 1965 he published a paper on the theory of fuzzy sets; that paper has given rise to hundreds of papers on fuzzy mathematics and fuzzy systems theory. Most importantly, fuzzy theory was adopted wholeheartedly by the Japanese, and their advances in the field of fuzzy control have won the attention of engineers throughout the world. Fuzzy theory gives us a whole new approach to the mathematics of thinking; it is a change of paradigm for Western world scientists and mathematicians, and like all changes of paradigm has been initially strenuously resisted, except in the Far East, where two-valued Aristotelian logic has not been too deeply ingrained.

The computer tool which your knowledge engineer will be using for expert system development is FLOPS (Fuzzy LOgic Production System), developed originally in the early 1980's at the Kemp-Carraway Heart Institute by Douglas Tucker and William Siler for medical image analysis.

FLOPS is based on fuzzy systems theory: fuzzy logic; fuzzy sets; and fuzzy numbers. The use of fuzzy mathematics gives FLOPS some important advantages. It is possible to reason in terms of words, such as small, medium, fast, slow and so on, rather than in terms of numbers; ambiguities and contradictions can be easily handled; and uncertainties pose no problems.

In this chapter we will consider fuzzy logic, with a continuous gradation of truth values ranging from false to true. We define the truth of a statement or value as being the confidence we have that the statement or value is correct. Truth is measured numerically; in most fuzzy systems literature, as ranging from zero (false) to one (true). FLOPS uses a different scale; confidences in FLOPS range from 0 (false) to 1000 (true), since this scale economizes computer memory requirements. This difference in scale is sufficiently obvious.

I have defined what truth is for a single statement. But now consider the truth of the combination of two statements, A AND B. A and B are both assertions; for example, Ashok is a man, or I don't have much free time this week. In conventional logic, of course both A and B must be either true or false. The statement (A AND B) is true only if both A and B are individually true; otherwise, the statement (A AND B) is false. Now, how do we define the fuzzy truth value of the statement (A AND B) if the fuzzy truth values of A and B separately are known? Fuzzy logic gives a remarkably simple answer to this problem: the truth of (A AND B) together is the minimum of the truth value of A and the truth value of B.

Similarly, consider the statement (A OR B), which in conventional logic is true if statement A or statement B or both are true, and is only false if both A and B are false. In fuzzy logic, the truth of (A OR B) is simply the maximum of the truth value of A and the truth value of B.

It is hard to see the practical importance of these simple rules of logic by themselves. However, most Western reasoning has its foundation in logic; these simple but new rules of logic have great impact on patterns of reasoning. And it is with patterns of reasoning that we are most concerned in constructing expert systems; it is patterns of real-life productive human reasoning that we are trying to emulate. Fuzzy logic gives us the theoretical tools to do this.

Fuzzy Sets

In mathematics, the concept of set is very simple, but very important. A set is simply a collection of things. The things can be most anything you want - numbers, names of autos, you name it. Things either belong to the set or don't belong, similar to the idea in logic that statements are either true or false. In 1965, Lotfi Zadeh proposed the idea of a fuzzy set; a fuzzy set is one to which objects can belong to different degrees, called grades of membership. in FLOPS, we measure the confidence that the member belongs to the fuzzy set as a number ranging from zero (absolutely false) to 1000 (absolutely true). One of my favorite fuzzy sets comes from the TV show MASH:

Character	Fuzzy Sets:
	Men	Athletes
Hawkeye	1000	500
BeeGee	1000	750
Lt.Col. Penobscot	1000	1000
Hot Lips Hooli han	0	950
Klinger	900	250

This simple idea of different grades of membership in a fuzzy set is extremely helpful in constructing expert systems. We will be concerned with fuzzy sets of descriptive words, where the grade of membership represents our confidence that the descriptor is true of whatever we are considering. Usually, we will use the term confidence rather than grade of membership. This permits us to use ordinary language in describing things in a precise way.

As an example, consider a fuzzy set speed, with members Slow, Medium and Fast.

Of course, we have to define in some way how to go back and forth between the description of speed in numbers and the description of speed in words. This is done through defining membership functions, which look something like this:

Of course, different experts would have different feelings about what speeds should be classified as Fast, Medium or Slow. Leaving a good deal of overlap on the adjacent membership functions is a very good idea; it lends robustness to the reasoning system. Membership functions need not be made up of straight lines; curvilinear shapes are available.

Other useful fuzzy sets are not descriptions of numbers, but of (in a broad sense) categories. These fuzzy sets are not word descriptors of "how much", but are answers to "what is it?" For example, fuzzy set color might have members Red, Green and Blue. Fuzzy set car might have members Ford, Chevrolet, Toyota and Buick.

In fuzzy sets like speed and color it is very likely that two or more descriptors might have non-zero confidences at the same time; that is fine, since we are seldom certain that one descriptor is entirely right and the others are entirely wrong. These are ambiguities, and as mentioned above they lend strength to the reasoning process. But in other fuzzy sets like car, it is not possible for a car to be both a Buick and a Chevrolet. In this case, if more than one member has a non-zero confidence, we have a contradiction. Contradictions need to be resolved before leaving our program, often by examining more data.

1.3 Fuzzy Numbers.

The final major member of our fuzzy systems arsenal is the fuzzy number. A fuzzy number is simply an ordinary number whose precise value is somewhat uncertain. Here, for example, is a fuzzy two.

Here our confidence that numbers 1.5 or less belong to the fuzzy 2 is zero, as is our confidence that numbers 2.5 or greater belong to the fuzzy 2. Our confidence that 1.6 belongs to the fuzzy 2 is 200; for 1.7, 400; and so on to confidence 1000 for 2. For numbers greater than 2, the confidence declines as the number increases, being 800 for 2.1, 600 for 2.2, and so on to zero confidence for 2.5.

A very convenient way to describe fuzzy numbers is to use modifying words. For example, the fuzzy two shown in Figure 1 could be completely specified by "roughly 2". Other modifying words available are "nearly", "about" and "crudely", with progressively larger uncertainties. These words are called hedges in fuzzy math circles.

With fuzzy numbers, we can make approximate comparisons. It is quite possible, for example, to ask if an input person's age is approximately equal to about 30. This is often very useful when our data or imprecise, or when we don't want the rigidity of accepting a person 30 years old but rejecting one thirty years plus one day old.

A very convenient way to describe fuzzy numbers is to use modifying words. For example, the fuzzy two shown in Figure 2 could be completely specified by "roughly 2". Other modifying words available are "nearly", "about" and crudely, with progressively larger uncertainties. These words are called hedges in fuzzy math circles.

Sample

2008-04-15T17:25:00.001+05:30

This is the Sample Blog updated by me from GDATA API

How to use SQL statements with LINQ

2008-04-07T11:48:00.001+05:30

Here is the answer. You can use it like this.

String strSQL="select * from player_Master where player_Id={0}";

IEnumerable<Player_Master> PlayerList = context11.ExecuteQuery<Player_Master>(strSQL, "10023");

Player_Master Paly11 = PlayertList.Single<Player_Master>();

Response.Write(Play11.PlayerName);

This is just a simpel

Difference Between .NET Remoting and Web Services

2008-03-29T17:22:00.001+05:30

1. Web services can only be accessed over HTTP whereas .NET Remoting can be accessed over various protocols like TCP, HTTP etc.

2. Web services operate in a stateless environment since its HTTP, a stateless protocol whereas .NET remoting support state management (as in through Singleton and SingleCall objects)

3. Web services are more reliable than .NET Remoting.

4. Web services are easy to create and use while .NET Remoting are complex to be created.

5. Web services support heterogeneous environments i.e. support interoperability across platforms, on the other hand .NET remoting requires client to be built using .NET, thus it does'nt support heterogeneous environment.

6. Web Services support datatypes defined in the XSD type system while .NET remoting provides support for rich type system using binary communication.

This question was asked me in an interview.

.Net Remoting a simple example

2008-03-29T16:04:00.003+05:30

What Is .NET Remoting?

As you may already know that application domains and processes are two mechanisms for isolation between applications. Processes are the main insulator between two different applications. Application domains is another extra isolation layer between different applications, but its main purpose is to isolate parts of code inside the same application. These parts will have the same isolation and restrictions as if they are different applications.

Now, what if for one reason or another we need to use a part of code located at different application domain running within the same application, located in different process running on the same machine, or located inside another process running on a different machine?. For uses like this, .Net remoting does exists.

Microsoft .Net Remoting is created to solve these problems. It provides a solution for communication between application domains and processes in a seamlessly and transparent way. This is due to the power of .Net remoting programming model and run time support.

When Microsoft developers designed .Net remoting framework, they have taken into consideration flexibility and customizability. This is done by separating the remotable object - in other words the object that you need to call remotely (located at another application domain or process) - from the client or server application domain and from any specific mechanism of communication. You can replace one communication protocol with a different one without the need to recompile the client or the server. Another flexibility related feature is that .Net remoting is a language independent framework, you can choose any application mode to communicate from. You can communicate using a web application, a console application, or a Windows Service. Any application can host a remoting object and provides its services to any client whether or not it is located within the same process boundaries, or in separate processes located on one machine or a set if disparate machines.

It is worth mentioning that objects in different application domains communicate using one of two techniques or methods. The first one is by transporting copies of objects across application domain boundaries. The second one is by using a proxy to exchange messages between them. .Net remoting framework uses the second technique.

.Net Remoting components

To allow an application located in different application domain or process to communicate with another one using .Net remoting technique, you have to just build the following:

A remotable object. Which is an object that contain some properties and methods located in one application domain and you need to call its methods or properties from another application domain or process.

A host application. This is the host of the remotable object. It is also called the server application. The main task of this host is to listen to requests for the hosted remotable object.

A client application. This is the application which makes requests for the remotable object.

Types of Remotable Objects

There are 3 types of remotable objects that you can configure and choose from depending on the requirements of your application.

Single Call: The remotable object is intended to be called from one client / one instance at a time.

Singleton Call: Several clients / several instances of the remotable object can be utilized

Activation: Richer than Singleton in the regard of other aspects.

How Does .NET Remoting Works?

As we mentioned previously you need to build a remotable type or object, a host or server application, and a client application to be able to communicate. In the client application you need only to create a new instance of the remotable object by using "New" or the instance creation function. When you do this the remoting system creates a proxy object that looks like the remote type to the client. When the client calls a method of the remotable type it actually call the method on the created proxy. The remoting system receives that call and routes it to the server process, it then processes the request, and returns the result to the client proxy, which in turn returns it to the client application. The client application will get the feeling of the remotable object as it is running inside the same process not inside another one. The proxy object is the system component that creates the impression that the server object is in the client's process not in a separate process or computer.

To get the above scenario to work perfectly, you actually need to know about two things: the first is channels, and the second is configuration.

Channels

If you try to build the remoting system yourself, you will need to learn network programming and a wide array of protocols and serialization formats. For purposes like that .NET remoting provides the concept of transport channel that represents the combination of the underlying technologies required to open a network connection and to use a particular protocol to send the bytes to the receiving application.

Channels are the transport media used to send / receive messages between applications across remoting boundaries (these boundaries can be between application domains, processes, or computers). A channel is an object that takes a stream of data, packages it according to a specific network protocol, and then sends the package to the other side. Channels can be categorized as channels which can send messages, channels which can receive messages, or channels which can perform both sending and receiving like the two .NET channels "HTTPChannel" and "TCPChannel".

By using the channel concept or technique you can plug in a wide range of protocols even if the common language runtime is not at the other end of the channel. You can also create your own channel object using whatever network protocol you prefer if it is not supported by the .NET framework.

You have to register at least one channel to use with the remoting infrastructure before being able to call the remotable type from the client application. You can register a channel in one of two ways: by calling "ChannelServices.RegisterChannel ", or by using a configuration file. You have to choose a specific port for your channel to listen on. If you are not sure whether a port is available or not, use 0 (zero) when you configuring your channel's port and the remoting system will choose an available port for you.

Configuration

The .NET remoting infrastructure needs specific information to work successfully and smoothly. That information is what we call configurations. You can choose one of the available two ways to configure your remotable types depending on your own preferences. The first way is by calling configuration methods directly from your server and client code, and this is what we call programmatic configuration. The second way is by creating an XML configuration file (.config file). To configure your remotable type properly whether by programmatic configuration or through a configuration file you have to provide the following information:

The activation type of your remotable object.

The name or address of the metadata that describes the remotable type.

The kind of the registered channel and the port number.

The URL that uniquely identifies the remotable type.

You should now recall that a .Net remoting application consists of three components. These are the remotable type, the host or server, and the client. In this part of our tutorial we will build a .NET remoting application using a technique nearly suitable for any scenario you may need to use .NET remoting with.

Building a .Net Remoting Application

.NET remoting has a very straightforward technique. If you want to build an application that uses .Net remoting to communicate across application domain boundaries all what you have to do is to implement the three components mentioned above. You also need to configure the remoting system to use remote activation for the remotable type. This requirements applies whatever the complexity of your remoting scenario.

Building a Remotable Type

The remotable object is a very typical / standard object, the difference is just it is being called from outside its application domain. To give any object the ability to be called from outside its application domain boundaries, the class that declare that object must inherit from "MarshalByRefObject" class. The "MarshalByRefObject" class is the base class for objects being communicated across application domains boundaries by exchanging messages using a proxy. So, when our class inherits this class, it automatically gets the same ability of communication as the "MarshalByRefObject" class. Also, the remotable class must be compiled into a .DLL library to be able to call its services. The following lines of code shows you an example of how to code a remotable type. First, open up your MS Visual Studio .NET, create new project, then add a new class to the created project. As shown in our example below the class name is "TheRemotableObject".

Public Class TheRemotableObject

Inherits MarshalByRefObject

Private List As String() = {"String1", "String2", "String3"}

Public Function ViewItem(ByVal ItemNum As Integer) As String

If ItemNum > List.GetUpperBound(0) _

Or ItemNum < List.GetLowerBound(0) Then Return "Error"

Return List(ItemNum)

End Function

End Class

The class shown in the above piece of code is a remotable class because it inherits the "MarshalByRefObject". It has a private list of strings and one public method or service. The method's mission is to take an integer list index as an input parameter, checks that the input is within the list boundaries and if so returns the specified or selected string to the caller.

Save the file containing the above created class - in our case it will be saved as "TheRemotableObject.vb". To compile this class into a library, use your command line tools shipped with the .NET framework SDK as shown in the following command line.

Note that: you should first run the [ Start / Programs / Microsoft Visual Studio 2005 / Visual Studio Tools / Visual Studio 2005 Command Prompt ] to be able to use the "vbc" compiler. You also have to run the following command from inside the directory inside which you saved the class file.

> vbc /t:library TheRemotableObject.vb

As a result of running the above command a new file "TheRemotableObject.dll" is now created at the same location as the "TheRemotableObject.vb" file.

Building a Host Application

Building such a remotable object as shown in the pervious section is not enough to make the required communication across application domains boundaries. Indeed, you need to build another kind of application to perform the communication process. You can think of building such a remotable type or object as just remarking this object as "could be shared or called remotely" but no more. You stilll need some kind of application being able of receiving calls to this newly created remotable object, identifying these calls, creating an instance from the called object, running the required service or method, and finally returning results to the caller. This is the host / server / listener application. A host application does its job by the mean of using channels. Channels are objects responsible of handling the network protocols and serialization formats on your behalf. In addition, the host application registers your remotable type with the .NET remoting system so that it can use your channel to listen for requests for your object. Host applications can be of any type. It can be a Windows forms application, an ASP.NET application, a Windows service application, a console application, or any type of a managed application.

Now, to an example:

Close all open projects or solutions, and create a new console application in a new directory (in our example we will name it example2). As a console application you will find module that is created by default (Module). Rename "Module1" as "Listener". Double click the "Listener" icon and change the module name shown in the code window. Add the imports statement and the lines of code inside the "Main" sub as shown in the following code snippet:

Imports System.Runtime.Remoting

Module Listener

Sub Main()

RemotingConfiguration.Configure("Listener.exe.config")

System.Console.WriteLine("Listener: Press <Enter> to exit ...")

System.Console.ReadLine()

End Sub

End Module

In the above code we firstly configure the remoting infrastructure by using a configuration file named "Listener.exe.config". Then we send a message to the user, and waiting till the user hits the <enter> key to exit. The last line main and only purpose is to keep the application running till the <enter> key is pressed.

The configuration file is an XML file specifying some configurations like the name and the URI of the remotable type, the kind of the used channel (whether it is an http or tcp channel), the port number to listen on, and the server activation mode. The remoting system uses the information in this file to listen for remote requests and route them to an instance of the remotable object or type. Below is a copy of the listener configuration file.

<system.runtime.remoting>

<wellknown

mode="Singleton"

type="TheRemotableObject, RemotableType"

objectUri="TheRemotableObject.rem"

</service>

</channels>

</application>

</system.runtime.remoting>

</configuration>

To compile the above "Listener.vb" module we will use the command line tools like in compiling the remotable object class above. Before compilation you have to save a copy of the "The remotableObject.dll" created in the previous example in the same directory with the "Listener.vb". Then save the above configuration file under the name specified in the listener module code file (which is "Listener.exe.config") in the same directory as the "Listener.vb" file. Position your command line prompt at the directory that contains the three files mentioned above then run the following command line.

> vbc /r:TheRemotableObject.dll Listener.vb

As a result you will get "Listener.exe" file in the same directory with the "Listener.vb".

Building a Client Application

To build a client application that utilizes the remotable type "TheRemotableObject" and hosted by the "Listener" application created above, you have to register this client application as a client for the specified remotable type. When you do this, the client application will call the remotable type as if it does exist in the same application domain with the client. The following code example shows you how to build a client application.

Close all open projects and solution in your Visual Studio .NET 2005 then create a new console application giving it a name and a directory to be created in (in our example the project name will be "Example3"). Rename the default created module "Module1" to "Client" then double click its icon to open the code file. Rename the module to "Client". Add the imports statement and the lines of code inside the "Main" sub as shown in the following code snippet.

Imports System.Runtime.Remoting

Module Client

Sub Main()

RemotingConfiguration.Configure("Client.exe.config")

Dim RM As New TheRemotableObject()

System.Console.WriteLine("Result = " + RM.ViewItem(1))

End Sub

End Module

As shown in the code above you have to configure the remoting infrastructure with the "Client.exe.config" XML configuration file. Then you define and create a new instance of the remotable type "TheRemotableObject". Call the remotable method "ViewItem" then write the result to the console. Although the "TheRemotableObject" type is not in the same application domain with the "Client" but you will be able to call its services "ViewItem" remotly and will be able to receive the results. Of course the last two lines of code in the "Main" subroutine will be marked as error but this is not a matter, just ignore it.

Write the following configuration file and save it under the name "Client.exe.config" at the same directory of the "Client.vb" code file.

<system.runtime.remoting>

<wellknown

type="TheRemotableObject, RemotableType"

Url="http://localhost:8989/TheRemotableObject.rem"

</client>

</application>

</system.runtime.remoting>

</configuration>

The configuration file tells the remoting system that the type information of the remotable type can be found in the "TheRemotableType" assembly. This remotable object located at "http://localhost:8989/TheRemotableObject.rem". If you want to run this application over a network, you have to write the remote computer name instead of "localhost" in the url above. You must pay attention when you write a configuration file. Although it is simple but most errors comes from incorrect settings or mismatching between settings in the two configuration files used by client and host applications.

Now put a copy of the "TheRemotableObject.dll" created in example1 and compile the above "Client.vb" using command line tools as follows.

> vbc /r:TheRemotableObject.dll Client.vb

As a result you will get "Client.exe" file at the same directory with the "Client.vb".

Running The Complete .NET Remoting application

Now The situation is : We have one directory called "Example2" (which is the listener directory) that contains "Listener.exe", "Listener.exe.config", and "TheRemotableObject.dll" files. We have another directory called "Example3" (which is the client directory) that contains "Client.exe", "Client.exe.config", and "TheRemotableObject.dll" files. Note: "Example2", and "Example3" are depicted as "L" and "cl" in the figure below.

Figure 1 - The host listing to the client and fulfill its requests

To run and test the remoting process between these two different applications where each one of them has its own application domain and process boundaries do the following: Run the command line prompt at the listener directory and type: Listener, then press <enter>. A message will be displayed as shown in figure1 in the above window. Now open a new command prompt in the client directory and type: Client, then press <enter>. When you do so the client application will call the remotable type, while the server at the other side of the channel listening for any requests. It receives the client request, process it then returns the results back to the client. The client gets the result and displays it to you at the client command prompt as shown in figure1 in the second window.

Some Useful links

2008-03-24T18:37:00.001+05:30

Links Related to INDIA

Some Good Views About Life
Some Good Posters
India Today
India World
Indolink
The Times of India

Gujarat Samachar : Sandesh

Weather - India
Listern to GARBA Audio
Links related to India
Consulate General of India

Other Useful Links

CNN News
BBC News
Good Magazines, TIME, People,...
Good Search Engines
Links to Astronomy
INS Home Page
VISA Informations
National Park Service
California Travel & Tourism

Bay Area Favorites
Silicon Valley Gateway
Virtual Job Search
The Right Place for Job Hunting
Career Mosaic
General Aid

Integrated System Design
Microprocessor Design Resource
EE Times
UNIX Reference Desk
Another UNIX Reference Desk
Mirco Times
Dictonary of Computing Contents
Library Online/Quick Reference
Missile Cammando - Game

NASA Web Page
Shuttle/MIR Web Page
NSSDC Photo Gallery
HST Picture Gallery
Big Bear Solar Observatory
SEDS:Good Astro Search Engine
Apollo Lunar Surface Journal

Guide to fun & freeware

Live DOUBLE LIFE in one!

Top 10 Business Movies according to Inc.com. Interestingly, most of them show businessmen as greedy bad guys.

Some GOOD Thoughts

Using Application Configuration file

2008-03-20T19:36:00.001+05:30

This article covers using application configuration files in Microsoft .NET. It briefly outlines the concept of application configuration files In particular, it discusses using the System.Configuration namespace

Application Configuration Background

Building configurable applications is not a new concept. The idea of applications relying on configuration parameters to dictate behavior at run time has been around for many years. For those of us who were around Microsoft-based programming prior to .NET, the most common example is the use of INI files. INI files are simple text-based files with key and value pairs; the key is used to fetch the value, and the value is then used in some way to influence the application settings and/or resulting behavior. This way, you can modify the configuration file to drive program behavior without having to recompile the application.

INI files generally worked great, except for the following drawbacks:

Everyone wrote their own parsers for dealing with them.
You had to have them on the machine where the application was running.
They required disk operations to read their files.

Microsoft moved away from INI files and towards storing everything in the Registry, which made application deployment much more difficult. As a result, Microsoft moved back to the concept of an "xcopy deployment," by which programmers deployed applications by simply copying files. Redmond used XML and some objects built into the Microsoft .NET Framework to bring new life to our old friend the application configuration file.

System.Configuration Basics

The System.Configuration namespace provides the functionality for reading configuration files. Microsoft released an XML schema dictating the format for configuration files that can be read using the System.Configuration API, enabling the accessing object to automatically consume the configuration files. This way, you can allow configuration files to be read without having to develop

The name and storage location of an application configuration file depends on the application type with which it is being used. A configuration file for an executable (.exe) is located in the same directory as the application. The file is the name of the application with a .config extension. For example, notepad.exe would have a configuration file of notepad.exe.config. A configuration file for an ASP.NET application is called web.config and is located in the root of the application's virtual directory.

appSettings Section

An application configuration file follows a specific XML schema. The appSettings section is a predefined section of the configuration file designed to make it very easy to retrieve a value based on a given name. This is the easiest way to add application-specific settings into an application configuration file. The appSettings section of the configuration file consists of a series of "add" elements with "key" and "value" attributes. While the appSettings section is predefined, it is not included in a configuration file by default and must be manually added. A simple example of a configuration file would be the following:

<?xml version="1.0"
encoding="utf-8" ?>

<add key="ConnectionString"

value="Server=localhost;Database=Northwind;Integrated

Security=false;User Id=sa;Password=;" />

</appSettings>

</configuration>

The AppSettings property of the ConfigurationSettings object in the System.Configuration namespace is used to get the settings. For example, to read either of the settings above, the following sample code would do the trick:

// Read appSettings

string title = ConfigurationSettings.AppSettings["ApplicationTitle"];

string connectString =

ConfigurationSettings.AppSettings["ConnectionString"];

Now, you could easily set a dynamic title value or read database connection string information from the application configuration file. This gives you the freedom to adjust settings without having to recompile any code.

Customized Configuration Sections

If you have distinct groupings of configurations to be included in the application configuration file, consider creating a custom configuration section in lieu of the appSettings section. This will allow you more organizational structuring around the storage of various settings. You include a custom section by including the configSections element in the configuration file and a sub-element called section that defines the custom section and the handler for reading it. The .NET Framework contains an IConfigurationSectionHandler interface that dictates the required functionality handlers provide by allowing you to use custom handlers with the Configuration if you so choose. This example just uses handlers the .NET Framework already provides. Continuing the example from the previous section, the following configuration file contains a custom section and specifies which handler to use for reading:

<?xml version="1.0"
encoding="utf-8" ?>

<section name="sampleSection"

type="System.Configuration.SingleTagSectionHandler" />

</configSections>

<sampleSection ApplicationTitle="Sample Console Application"

ConnectionString="Server=localhost;Database=Northwind;

Integrated Security=false;User Id=sa;

Password=;" />

<add key="ApplicationTitle"

value="Sample Console Application" />

<add key="ConnectionString"

value="Server=localhost;Database=Northwind;

Integrated Security=false;User Id=sa;Password=;" />

</appSettings>

</configuration>

The following code reads the configuration settings into a dictionary, where you can easily access the values:

// Read customSection

System.Collections.IDictionary sampleTable = (IDictionary)

ConfigurationSettings.GetConfig("sampleSection");

string title = (string)sampleTable["ApplicationTitle"];

string connectString = (string)sampleTable["ConnectionString"];

Customized Configuration Sections and Groups

The issue with custom configuration sections alone is that they rely on attributes to store all of the settings as a part of a single element. This can become cumbersome when a large number of configurations are contained within a section or additional related sections. You can further organize similar custom sections into a section group, which makes it easier to work with numerous configurations and helps eliminate naming conflicts with custom configuration sections. This is especially useful where your application contains reference to several other DLLs that read configuration information from the host applications configuration file. A sectionGroup element is simply placed around one or more section elements to create a group. Expanding the example configuration file, the following configuration file contains a custom group, section, and the pre-defined appSettings:

<?xml version="1.0"
encoding="utf-8" ?>

<section name="sampleSection"

type="System.Configuration.SingleTagSectionHandler" />

<section name="utilitySection"

type="System.Configuration.NameValueSectionHandler,

System,Version=1.0.5000.0, Culture=neutral,

PublicKeyToken=b77a5c561934e089" />

</sectionGroup>

</configSections>

<sampleSection ApplicationTitle="Sample Console Application"

ConnectionString="Server=localhost;Database=Northwind;

Integrated Security=false;User Id=sa;

Password=;" />

<add key="ApplicationTitle"

value="Sample Console Application" />

<add key="ConnectionString"

value="Server=localhost;Database=Northwind;

Integrated Security=false;User Id=sa;

Password=;" />

</utilitySection>

</CodeGuru>

<add key="ApplicationTitle"

value="Sample Console Application" />

<add key="ConnectionString"

value="Server=localhost;Database=Northwind;

Integrated Security=false;User Id=sa;Password=;" />

</appSettings>

</configuration>

Note the extra "Version," "Culture," and "PublicKeyToken" specified in defining a section group. These all come from what the machine.config configures on the local machine. Occasionally, it has worked for me without them, but other times an exception is thrown that it can't create the appropriate handler. I've found that if I include those items, it consistently works.

The following code can access the items in the custom group by loading the group into a NameValueCollection for easy access to the key and value pairs:

// Read custom sectionGroup

NameValueCollection collection = (NameValueCollection)

ConfigurationSettings.GetConfig("CodeGuru/utilitySection");

string title = collection["ApplicationTitle"];

string connectString = collection["ConnectionString"];

Note the path-like statement required to find the appropriate section to read when accessing the custom section.

Possible Enhancements

This article has touched on some of the basics of using application configuration files, including the ability to define your own sections and groups of sections. Here are a couple of additional items for you to ponder about application configuration settings:

Introduce some form of encryption to keep configuration settings safe. While the application configuration files are secured by operating system permissions, that won't always prevent prying eyes from seeing the information they contain. The use of plain text-based XML makes it insecure to store items such as connection string information that contain passwords within the configuration file. Building your own wrapper around the System.Configuration or creating a custom configuration section and implementing the IConfigurationSectionHandler interface in a custom handler allows you to build your own methods to include encryption to keep information secure in the application configuration file.
Use application configuration settings to dynamically assign field and/or property values. This won't work for standalone DLLs that don't have a configuration file, but it will work if your DLL is utilized by an executable or ASP.NET application, as is often the case with utility libraries or business logic components.

System Development Life Cycle

2008-03-14T16:51:00.001+05:30

SDLC

SDLC is the process of developing information systems through investigation, analysis, design, implementation and maintenance. SDLC is also known as information systems development or application development. It is also known as Waterfall Model

The software development life cycle (SDLC) is the entire process of formal, logical steps taken to develop a software product. The phases of SDLC can vary somewhat but generally include the following:

Requirements Analysis

Extracting the requirements of a desired software product is the first task in creating it. While customers probably believe they know what the software is to do, it may require skill and experience in software engineering to recognize incomplete, ambiguous or contradictory requirements.

Specification

Specification is the task of precisely describing the software to be written, in a mathematically rigorous way. In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed, although safety-critical software systems are often carefully specified prior to application development. Specifications are most important for external interfaces that must remain stable.

Software architecture

The architecture of a software system refers to an abstract representation of that system. Architecture is concerned with making sure the software system will meet the requirements of the product, as well as ensuring that future requirements can be addressed. The architecture step also addresses interfaces between the software system and other software products, as well as the underlying hardware or the host operating system.

Coding

Reducing a design to code may be the most obvious part of the software engineering job, but it is not necessarily the largest portion.

Testing

Testing of parts of software, especially where code by two different engineers must work together, falls to the software engineer.

Documentation

An important task is documenting the internal design of software for the purpose of future maintenance and enhancement. Documentation is most important for external interfaces.

Software Training and Support

A large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are occasionally resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, its very important to have training classes for the most enthusiastic software users (build excitement and confidence), shifting the training towards the neutral users intermixed with the avid supporters, and finally incorporate the rest of the organization into adopting the new software. Users will have lots of questions and software problems which leads to the next phase of Software.

Maintenance

Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. Not only may it be necessary to add code that does not fit the original design but just determining how software works at some point after it is completed may require significant effort by a software engineer. About 2/3 of all software engineering work is maintenance, but this statistic can be misleading. A small part of that is fixing bugs.

Process Models

There are several methodologies or models that can be used to guide the software development lifecycle. Some of these include:
--Linear or Waterfall Model
--Rapid Application Development (RAD)
--Joint Application Development (JAD)
--Prototyping Model
--Fountain Model
--Spiral Model
--Build and Fix
--Synchronize-and-Stabilize

Rapid Application Development

"Rapid Application Development (RAD) is an incremental software development process model that emphasizes a very short development cycle typically 60-90 days". The RAD approach encompasses the following phases:
1.Business Modeling
2.Data Modeling
3.Process Modeling
4.Application Generation
5.Testing and Turnover

Business Modeling

The information flow among business functions is modeled in am way that answers the following questions:
1.What information drives the business process?
2.What information is generated?
3.Who generates it?
4.Where does the information go?
5.Who processes it?

Data Modelling

The information flow defined as part of the business modeling phase is refined into a set of data objects that are needed to support the business. The characteristic of each object is identified and the relationship between these objects are defined.

Process Modelling

The data objects defined in the data-modeling phase are transformed to achieve the information flow necessary to implement a business function. Processing the descriptions are created for adding, modifying, deleting or retrieving data object.

Application Generation

RAD assumes the use of the RAD tools like VB,VC++,Delphi etc rather than creating
software using conventional third generation programming languages. The RAD works to reuse
existing program components or create reusable components. In all cases, automated tools are used to facilitate construction of the software.

Testing and Turnover

Since the RAD process emphasizes reuse, many of the program components have already been tested. This minimize the testing and development time.

Data Flow Diagrams Notations

2008-03-14T16:42:00.001+05:30

DFD

Data Flow Diagrams

A data flow diagram is a graphical technique that depicts information flow and the transforms that are applied as data move from input to output. The data flow diagram is also known as 'data flow graph'. Various symbols are used to depict the data from one level to another level.
The data flow diagram must be used to represent the system or software at any level of abstraction. In fact data flow diagram may partitioned into the levels that represent increasing information flow for functional modeling as information on flow modeling. In doing so it satisfies the second operational analysis principle i.e., creating a functional model.

Notation
Logical data flow diagrams can be completed using only four simple notations, i.e. special symbols or icons and the annotation that associates them with a specific system the Yourdon approach is used.

1.DataFlow

Data move in a specific direction from an origin to a destination in the form of a document. The data flow is a "packet of data".

2.Process

People procedure or devices that use or produce data. The physical component is not identified.

3.Source or Destination

External sources or destinations of data interact with the system but are outside its boundary.

4.Data Store

Here data are stored or referenced by process in the system.

Structure of Software Requirements Specification Document

2008-03-14T16:13:00.001+05:30

1. Introduction

1.1 Purpose of this document
Describes the purpose of the document, and the intended audience.

1.2 Scope of this document
Describes the scope of this requirements definition effort. Introduces the requirements elicitation team, including users, customers, system engineers, and developers.
This section also details any constraints that were placed upon the requirements elicitation process, such as schedules, costs, or the software engineering environment used to develop requirements.

1.3 Overview
Provides a brief overview of the product defined as a result of the requirements elicitation process.

1.4 Business Context
Provides an overview of the business organization sponsoring the development of this product. This overview should include the business's mission statement and its organizational objectives or goals.

2. General Description

2.1 Product Functions
Describes the general functionality of the product, which will be discussed in more detail below.

2.2 Similar System Information
Describes the relationship of this product with any other products. Specifies if this product is intended to be stand-alone, or else used as a component of a larger product. If the latter, this section discusses the relationship of this product to the larger product.

2.3 User Characteristics
Describes the features of the user community, including their expected expertise with software systems and the application domain.

2.4 User Problem Statement
This section describes the essential problem(s) currently confronted by the user community.

2.5 User Objectives
This section describes the set of objectives and requirements for the system from the user's perspective. It may include a "wish list" of desirable characteristics, along with more feasible solutions that are in line with the business objectives.

2.6 General Constraints
Lists general constraints placed upon the design team, including speed requirements, industry protocols, hardware platforms, and so forth.

3. Functional Requirements

This section lists the functional requirements in ranked order. Functional requirements describes the possible effects of a software system, in other words, what the system must accomplish. Other kinds of requirements (such as interface requirements, performance requirements, or reliability requirements) describe how the system accomplishes its functional requirements. Each functional requirement should be specified in a format similar to the following:

Short, imperative sentence stating highest ranked functional requirement.

Description
A full description of the requirement.

Criticality
Describes how essential this requirement is to the overall system.

Technical issues
Describes any design or implementation issues involved in satisfying this requirement.

Cost and schedule
Describes the relative or absolute costs associated with this issue.

Risks
Describes the circumstances under which this requirement might not able to be satisfied, and what actions can be taken to reduce the probability of this occurrence.

Dependencies with other requirements
Describes interactions with other requirements.

... others as appropriate

b) <Name of second highest ranked requirement>
And so forth...

4. Interface Requirements

This section describes how the software interfaces with other software products or users for input or output. Examples of such interfaces include library routines, token streams, shared memory, data streams, and so forth.

4.1 User Interfaces
Describes how this product interfaces with the user.

4.1.1 GUI
Describes the graphical user interface if present. This section should include a set of screen dumps or mockups to illustrate user interface features.
If the system is menu-driven, a description of all menus and their components should be provided.

4.1.2 CLI
Describes the command-line interface if present. For each command, a description of all arguments and example values and invocations should be provided.

4.1.3 API
Describes the application programming interface, if present. For each public interface function, the name, arguments, return values, examples of invocation, and interactions with other functions should be provided.

4.1.4 Diagnostics or ROM
Describes how to obtain debugging information or other diagnostic data.

4.2 Hardware Interfaces
Describes interfaces to hardware devices.

4.3 Communications Interfaces
Describes network interfaces.

4.4 Software Interfaces
Describes any remaining software interfaces not included above.

5. Performance Requirements

Specifies speed and memory requirements.

6. Design Constraints

Specifies any constraints for the design team using this document.

6.1 Standards Compliance

6.2 Hardware Limitations
... others as appropriate

7. Other non-functional attributes

Specifies any other particular non-functional attributes required by the system. Examples are provided below.

7.1 Security
7.2 Binary Compatibility
7.3 Reliability
7.4 Maintainability
7.5 Portability
7.6 Extensibility
7.7 Reusability
7.8 Application Affinity/Compatibility
7.9 Resource Utilization
7.10 Serviceability
... others as appropriate

8. Preliminary Object-Oriented Domain Analysis

This section presents a list of the fundamental objects that must be modelled within the system to satisfy its requirements. The purpose is to provide an alternative, "structural" view on the requirements stated above and how they might be satisfied in the system.

8.1 Inheritance Relationships
This section should contain a set of graphs that illustrate the primary inheritance hierarchy (is-kind-of) for the system.

8.2 Class descriptions
This section presents a more detailed description of each class identified during the OO Domain Analysis.

Each class description should conform to the following structure:

8.2.1 <Class name>

8.2.1.1 Abstract or Concrete:
Indicates whether this class is abstract or concrete.

8.2.1.2 List of Superclasses:
Names all immediate superclasses.

8.2.1.3 List of Subclasses:
Names all immediate subclasses.

8.2.1.4 Purpose:
States the basic purpose of the class.

8.2.1.5 Collaborations:
Names each class with which this class must interact in order to accomplish its purpose, and how.

8.2.1.6 Attributes:
Lists each attribute (state variable) associated with each instance of this class, and indicates examples of possible values (or a range).

8.2.1.7 Operations:
Lists each operation that can be invoked upon instances of this class. For each operation, the arguments (and their type), the return value (and its type), and any side effects of the operation should be specified.

8.2.1.8 Constraints:
Lists any restrictions upon the general state or behavior of instances of this class.

9. Operational Scenarios

This section should describe a set of scenarios that illustrate, from the user's perspective, what will be experienced when utilizing the system under various situations.
In the article Inquiry-Based Requirements Analysis (IEEE Software, March 1994), scenarios are defined as follows:

In the broad sense, a scenario is simply a proposed specific use of the system. More specifically, a scenario is a description of one or more end-to-end transactions involving the required system and its environment. Scenarios can be documented in different ways, depending up on the level of detail needed. The simplest form is a use case, which consists merely of a short description with a number attached. More detailed forms are called scripts. These are usually represented as tables or diagrams and involved identifying an action and the agent (doer) of the action. FOr this reason, a script can also be called an action table.
Although scenarios are useful in acquiring and validating requirements, they are not themselves requirements, because the describe the system's behavior only in specific situations; a specification, on the other hand, describes what the system should do in general.

10. Preliminary Schedule

This section provides an initial version of the project plan, including the major tasks to be accomplished, their interdependencies, and their tentative start/stop dates. The plan also includes information on hardware, software, and wetware resource requirements.
The project plan should be accompanied by one or more PERT or GANTT charts.

11. Preliminary Budget

This section provides an initial budget for the project, itemized by cost factor.

12. Appendices

Specifies other useful information for understanding the requirements. All SRS documents should include at least the following two appendices:

12.1 Definitions, Acronyms, Abbreviations
Provides definitions of unfamiliar definitions, terms, and acronyms.

12.2 References
Provides complete citations to all documents and meetings referenced or used in the preparation of this document.

Ajax An Overview

2008-03-13T17:37:00.001+05:30

AJAX is a cross-platform technique that can be use on different operating system and web application based on JavaScript and DOM. It is a powerful approach of web application technique using client-side scripting to exchange data with the web server. This means that with AJAX, web pages increases interactivity and faster responsiveness of user interface by having an independent communication with the server. Gone are the traditional ways of web browsing whereby a new page communicates with each user's request. This creates dynamic web application user interface that renders effective usability of every desktop applications. AJAX primary purpose is to increase the web page's interactivity, speed, functionality, and usability.

Ajax, by definition, is not technology. In fact, it is an application of several technologies. Ajax incorporates several existing web application like XHTML and CSS for standard-based presentation; the Document Object Model for dynamic display and interaction; XML and XSLT for data interchange between the server and the client; the XMLHttpRequest to exchange asynchronous data with the web server; and the use of JavaScript as the core code for running AJAX application.

To understand AJAX, first we must know how the traditional web application works. The classic web interface trigger an HTTP request back to web server. The server then process and retrieve data before returning an HTML page to the users. This process as a model for hypertext medium makes technical sense. But as web application evolves this process does not make the user interface more interactive and practical.

AJAX, on the other hand, eliminates this problem. AJAX speed up the loading of any web application with the use of intermediary between the user and the server called AJAX engine. This adding of another layer application of eliminates the start-stop-start-stop nature on the web. The browser loads an AJAX engine at the start of session.

The AJAX engine allows the user interface and the application to interchange data asynchronously-independent of the communication to the server. So the interaction between the user and the web never slows down, no point of waiting for the server to do something.

AJAX is a powerful technique that grows exceedingly as web application. That is, AJAX is now part of the guiding principle as web 2.0 flourishes and become a practical reality. With the power of AJAX, many of the business and marketing web site are integrated with AJAX application server platform now. Most of the major products of Google such as Gmail, Google Maps, and Google Suggest are employing AJAX application. Other web services like the photo-sharing application Flickr, Amazon's A9.com, and the new Yahoo! maps depends on AJAX. The application of AJAX comes from simple function to the most complex program like Google Maps.

How to use transaction in LINQ using C#

2008-03-06T15:17:00.001+05:30

I looked in to the LINQ and found very interesting. LINQ generates DataContext class which provides classes and methods which is used in OR-Mapping. You can also use your own stored procedures and views with LINQ. You may require using transaction with your own Stored Procedures for Insert, Delete or updating operations.

System.Data.Common.DbTransaction class provides the Transaction object.

Lets start with new project, you can select new project from Start -> All Programs -> Microsoft Visual Studio 2008and click on Microsoft Visual Studio 2008. Create new Asp.net website. Right click on website from solution explorer and select LINQ to SQL classes from Add New Item.

This will generate dbml file in App_Code folder. Select the tables, views, stored procedures and function from server explorer and drag it on dbml file. DataContext class generates methods for each SPs, functions and views.

System.Data.Common.DbTransaction trans = null;

DataClassesDataContext objDataClass = new
DataClassesDataContext();

try
{

// Open the connection
objDataClass.Connection.Open();

// Begin the transaction
trans = objDataClass.Connection.BeginTransaction();

// Assign transaction to context class
// All the database operation perform by this object
//will now use transaction
objDataClass.Transaction = trans;

//Perform the Operations

///Insert

//Update

//Delete

}

catch (Exception ex)
{

// Rollback transaction
if (trans != null)
trans.Rollback();

}
finally
{

// Close the connection

if (objDataClass.Connection.State == ConnectionState.Open)

objDataClass.Connection.Close();

}

Fig - Code for Transaction in LINQ using C#

Linq Performance Test

2008-03-05T15:06:00.001+05:30

LINQ vs Loop - A performance test

The future holds for C#. The addition of LINQ has brought a variety of query keywords to the language. "Anything" can be queried; Collections, DataTables, SQL databases, XML documents, and Arrays. Custom queryable objects can also be created by implementing IQueryable. But all this costs you. The question is how much?

I decided to create a simple test to see how much of a performance hit LINQ is. The simple test I deviced finds the numbers in an array that are less than 10. The code is quoted below.

static
void Main(string[] args)

{

const
int SIZE = 100000, RUNS = 10000;

int[] intData = new
int[SIZE];

for (int i = 0; i < SIZE; i++)

intData[i] = i;

DateTime dtStartTime = DateTime.Now;

for (int t = 0; t < RUNS; ++t)

{

int[] less = (from xData in intData

where xData < 10

select xData).ToArray();

}

TimeSpan dtCompletTime = DateTime.Now - dtStartTime;

Console.WriteLine(string.Format("LINQ: {0}, avg. {1}",

dtCompletTime, new
TimeSpan(dtCompletTime.Ticks / RUNS)));

DateTime dtStartTimeFor2 = DateTime.Now;

for (int t = 0; t < RUNS; ++t)

{

var l = new
List<int>();

foreach (var i in intData)

if (i < 10)

l.Add(i);

int[] less2 = l.ToArray();

}

TimeSpan dtCompletTimeFor2 = DateTime.Now - dtStartTimeFor2;

Console.WriteLine(string.Format("Loop: {0}, avg. {1}",

dtCompletTimeFor2, new
TimeSpan(dtCompletTimeFor2.Ticks / RUNS)));

Console.ReadLine();

}

Initially, I assumed the performance impact would not be too large, since its equivalent is the straightforward imperative loop, which should not be too hard for a compiler to deduce given static typing and a single collection to iterate across. Or?

LINQ: 00:00:23.4539536, avg. 00:00:00.0023453
Loop: 00:00:10.5456736, avg. 00:00:00.0010545

As you can see, the performance impact is huge. LINQ performs 50 times worse than the traditional loop! This seems rather wild at first glance, but the explanation is this: The keywords introduced by LINQ are syntactic sugar for method invocations to a set of generic routines for iterating across collections and filtering through lambda expressions. Naturally, this will not perform as good as a traditional imperative loop, and less optimization is possible.

Using Linq With Array List

static
void Main(string[] args)

{

Console.WriteLine("Using Linq on Array List");

ArrayList arrList = new
ArrayList();

arrList.Add(

new
Student

{

FirstName = "Mehul",

LastName = "Talajia",

Scores = new
int[] { 98, 92, 81, 60 }

});

arrList.Add(

new
Student

{

FirstName = "Anil",

LastName = "Patel",

Scores = new
int[] { 75, 84, 91, 39 }

});

arrList.Add(

new
Student

{

FirstName = "Pranav",

LastName = "Vyas",

Scores = new
int[] { 88, 94, 65, 91 }

});

arrList.Add(

new
Student

{

FirstName = "Piyush",

LastName = "Gohel",

Scores = new
int[] { 97, 89, 85, 82 }

});

DateTime dtStartArrayLINQ = DateTime.Now;

var query = from
Student student in arrList

where student.Scores[0] > 95

select student;

foreach (Student s in query)

Console.WriteLine(s.LastName + ": " + s.Scores[0]);

TimeSpan dtEndArrayLinq = DateTime.Now - dtStartArrayLINQ;

int intTmpTicks = 4;

DateTime dtStartArrayLoop = DateTime.Now;

foreach (Student a in arrList)

{

if (a.Scores[0] > 95)

{

Console.WriteLine(a.LastName + ": " + a.Scores[0]);

}

TimeSpan dtEndArrayLoop = DateTime.Now - dtStartArrayLoop;

Console.WriteLine(string.Format("LINQ: {0}, avg. {1}",

dtEndArrayLinq , new
TimeSpan(dtEndArrayLinq.Ticks / intTmpTicks)));

Console.WriteLine(string.Format("Loop: {0}, avg. {1}",

dtEndArrayLoop , new
TimeSpan(dtEndArrayLoop.Ticks / intTmpTicks)));

Console.Read();

}

LINQ: 00:00:00.0467946, avg. 00:00:00.0116986
Loop: 00:00:00, avg. 00:00:00

Having seen the performance impact, I am still of the view that LINQ is a great step towards a more declarative world for developers. Instead of saying "take these numbers, iterate over all of them, and insert them into this list if they are less than ten", which is an informal description of a classical imperative loop, you can now say "from these numbers, give me those that are less than ten". The difference may be subtle, but the latter is in my opinion far more declarative and easy to read.

This may very well be the next big thing, but it comes at a cost. So far, my advice is to create simple performance tests for the cases where you consider adopting LINQ, to spot possible pitfalls as early as possible.

Free .NET3.5 C# Ajax Books

2008-03-04T18:46:00.001+05:30

Free .NET 3.5 C# Books

Ajax Foundation Free E-Bool

http://rapidshare.com/files/96917539/Foundations_Of_Ajax__2005_.pdf

C# 2008 Free E-Book

http://rapidshare.com/files/95627537/Pro_C_2008_and_the_NET_3_5_Platform_Fourth_Edition-3783.zip

http://rapidshare.com/files/95629422/_new__www.free-ebooks-download.org-...ro_ASP.NET_3.5_in_C__2008.zip

Coding Standards

2008-02-28T19:18:00.002+05:30

Introduction

Anybody can write code. With a few months of programming experience, you can write 'working applications'. Making it work is easy, but doing it the right way requires more work, than just making it work.

Believe it, majority of the programmers write 'working code', but not 'good code'. Writing 'good code' is an art and you must learn and practice it.

Everyone may have different definitions for the term 'good code'. In my definition, the following are the characteristics of good code.

Reliable
Maintainable
Efficient

Most of the developers are inclined towards writing code for higher performance, compromising reliability and maintainability. But considering the long term ROI (Return On Investment), efficiency and performance comes below reliability and maintainability. If your code is not reliable and maintainable, you (and your company) will be spending lot of time to identify issues, trying to understand code etc throughout the life of your application.

Purpose of coding standards and best practices

To develop reliable and maintainable applications, you must follow coding standards and best practices.

The naming conventions, coding standards and best practices described in this document are compiled from our own experience and by referring to various Microsoft and non Microsoft guidelines.

There are several standards exists in the programming industry. None of them are wrong or bad and you may follow any of them. What is more important is, selecting one standard approach and ensuring that everyone is following it.

How to follow the standards across the team

If you have a team of different skills and tastes, you are going to have a tough time convincing everyone to follow the same standards. The best approach is to have a team meeting and developing your own standards document. You may use this document as a template to prepare your own document.

Distribute a copy of this document (or your own coding standard document) well ahead of the coding standards meeting. All members should come to the meeting prepared to discuss pros and cons of the various points in the document. Make sure you have a manager present in the meeting to resolve conflicts.

Discuss all points in the document. Everyone may have a different opinion about each point, but at the end of the discussion, all members must agree upon the standard you are going to follow. Prepare a new standards document with appropriate changes based on the suggestions from all of the team members. Print copies of it and post it in all workstations.

After you start the development, you must schedule code review meetings to ensure that everyone is following the rules. 3 types of code reviews are recommended:

Peer review – another team member review the code to ensure that the code follows the coding standards and meets requirements. This level of review can include some unit testing also. Every file in the project must go through this process.
Architect review – the architect of the team must review the core modules of the project to ensure that they adhere to the design and there is no "big" mistakes that can affect the project in the long run.
Group review – randomly select one or more files and conduct a group review once in a week. Distribute a printed copy of the files to all team members 30 minutes before the meeting. Let them read and come up with points for discussion. In the group review meeting, use a projector to display the file content in the screen. Go through every sections of the code and let every member give their suggestions on how could that piece of code can be written in a better way. (Don't forget to appreciate the developer for the good work and also make sure he does not get offended by the "group attack"!)

Naming Conventions and Standards

Note :

The terms Pascal Casing and Camel Casing are used throughout this document.

Pascal Casing - First character of all words are Upper Case and other characters are lower case.

Example: BackColor

Camel Casing - First character of all words, except the first word are Upper Case and other characters are lower case.

Example: backColor

Use Pascal casing for Class names

public class HelloWorld

{

...

}

Use Pascal casing for Method names

void SayHello(string name)

{

...

}

Use Camel casing for variables and method parameters

int totalCount = 0;

void SayHello(string name)

{

string fullMessage = "Hello " + name;

...

}

Use the prefix "I" with Camel Casing for interfaces ( Example: IEntity )

Do not use Hungarian notation to name variables.

In earlier days most of the programmers liked it - having the data type as a prefix for the variable name and using m_ as prefix for member variables. Eg:

string m_sName;

int nAge;

However, in .NET coding standards, this is not recommended. Usage of data type and m_ to represent member variables should not be used. All variables should use camel casing.

Some programmers still prefer to use the prefix m_ to represent member variables, since there is no other easy way to identify a member variable.

Use Meaningful, descriptive words to name variables. Do not use abbreviations.

Good:

string address

int salary

Not Good:

string nam

string addr

int sal

Do not use single character variable names like i, n, s etc. Use names like index, temp

One exception in this case would be variables used for iterations in loops:

for ( int i = 0; i < count; i++ )

{

...

}

If the variable is used only as a counter for iteration and is not used anywhere else in the loop, many people still like to use a single char variable (i) instead of inventing a different suitable name.

Do not use underscores (_) for local variable names.

All member variables must be prefixed with underscore (_) so that they can be identified from other local variables.

Do not use variable names that resemble keywords.

Prefix boolean variables, properties and methods with "is" or similar prefixes.

Ex: private bool _isFinished

Namespace names should follow the standard pattern

Use appropriate prefix for the UI elements so that you can identify them from the rest of the variables.

There are 2 different approaches recommended here.
1. Use a common prefix ( ui_ ) for all UI elements. This will help you group all of the UI elements together and easy to access all of them from the intellisense.
1. Use appropriate prefix for each of the ui element. A brief list is given below. Since .NET has given several controls, you may have to arrive at a complete list of standard prefixes for each of the controls (including third party controls) you are using.

Control	Prefix
Label	lbl
TextBox	txt
DataGrid	dtg
Button	btn
ImageButton	imb
Hyperlink	hlk
DropDownList	ddl
ListBox	lst
DataList	dtl
Repeater	rep
Checkbox	chk
CheckBoxList	cbl
RadioButton	rdo
RadioButtonList	rbl
Image	img
Panel	pnl
PlaceHolder	phd
Table	tbl
Validators	Val
DATA TYPES
Integer	int
Double	dbl
String	str
Char	chr
Long	lng
Unsigned Int	uint
Boolean	is

File name should match with class name.

For example, for the class HelloWorld, the file name should be helloworld.cs (or, helloworld.vb)

Use Pascal Case for file names.

Indentation and Spacing

Use TAB for indentation. Do not use SPACES. Define the Tab size as 4.

Comments should be in the same level as the code (use the same level of indentation).

Good:

// Format a message and display

string fullMessage = "Hello " + name;

DateTime currentTime = DateTime.Now;

string message = fullMessage + ", the time is : " + currentTime.ToShortTimeString();

MessageBox.Show ( message );

Not Good:

// Format a message and display

string fullMessage = "Hello " + name;

DateTime currentTime = DateTime.Now;

string message = fullMessage + ", the time is : " + currentTime.ToShortTimeString();

MessageBox.Show ( message );

Curly braces ( {} ) should be in the same level as the code outside the braces.

Use one blank line to separate logical groups of code.

Good:

bool SayHello ( string name )

{

string fullMessage = "Hello " + name;

DateTime currentTime = DateTime.Now;

string message = fullMessage + ", the time is : " + currentTime.ToShortTimeString();

MessageBox.Show ( message );

if ( ... )

{

// Do something

// ...

return false;

}

return true;

}

Not Good:

bool SayHello (string name)

{

string fullMessage = "Hello " + name;

DateTime currentTime = DateTime.Now;

string message = fullMessage + ", the time is : " + currentTime.ToShortTimeString();

MessageBox.Show ( message );

if ( ... )

{

// Do something

// ...

return false;

}

return true;

}

There should be one and only one single blank line between each method inside the class.

The curly braces should be on a separate line and not in the same line as if, for etc.

Good:

if ( ... )

{

// Do something

}

Not Good:

if ( ... ) {

// Do something

}

Use a single space before and after each operator and brackets.

Good:

if ( showResult == true )

{

for ( int i = 0; i < 10; i++ )

{

}

Not Good:

if(showResult==true)

{

for(int i= 0;i<10;i++)

{

}

Use #region to group related pieces of code together. If you use proper grouping using #region, the page should like this when all definitions are collapsed.

Keep private member variables, properties and methods in the top of the file and public members in the bottom.

Good Programming practices

Avoid writing very long methods. A method should typically have 1~25 lines of code. If a method has more than 25 lines of code, you must consider re factoring into separate methods.

Method name should tell what it does. Do not use mis-leading names. If the method name is obvious, there is no need of documentation explaining what the method does.

Good:

void SavePhoneNumber ( string phoneNumber )

{

// Save the phone number.

}

Not Good:

// This method will save the phone number.

void SaveDetails ( string phoneNumber )

{

// Save the phone number.

}

A method should do only 'one job'. Do not combine more than one job in a single method, even if those jobs are very small.

Good:

// Save the address.

SaveAddress ( address );

// Send an email to the supervisor to inform that the address is updated.

SendEmail ( address, email );

void SaveAddress ( string address )

{

// Save the address.

// ...

}

void SendEmail ( string address, string email )

{

// Send an email to inform the supervisor that the address is changed.

// ...

}

Not Good:

// Save address and send an email to the supervisor to inform that

// the address is updated.

SaveAddress ( address, email );

void SaveAddress ( string address, string email )

{

// Job 1.

// Save the address.

// ...

// Job 2.

// Send an email to inform the supervisor that the address is changed.

// ...

}

Use the c# or VB.NET specific types (aliases), rather than the types defined in System namespace.

int age; (not Int16)

string name; (not String)

object contactInfo; (not Object)

Some developers prefer to use types in Common Type System than language specific aliases.

Always watch for unexpected values. For example, if you are using a parameter with 2 possible values, never assume that if one is not matching then the only possibility is the other value.

Good:

If ( memberType == eMemberTypes.Registered )

{

// Registered user… do something…

}

else if ( memberType == eMemberTypes.Guest )

{

// Guest user... do something…

}

else

{

// Un expected user type. Throw an exception

throw new Exception ("Un expected value " + memberType.ToString() + "'.")

// If we introduce a new user type in future, we can easily find

// the problem here.

}

Not Good:

If ( memberType == eMemberTypes.Registered )

{

// Registered user… do something…

}

else

{

// Guest user... do something…

// If we introduce another user type in future, this code will

// fail and will not be noticed.

}

Do not hardcode numbers. Use constants instead. Declare constant in the top of the file and use it in your code.

However, using constants are also not recommended. You should use the constants in the config file or database so that you can change it later. Declare them as constants only if you are sure this value will never need to be changed.

Do not hardcode strings. Use resource files.

Convert strings to lowercase or upper case before comparing. This will ensure the string will match even if the string being compared has a different case.

if ( name.ToLower() == "john" )

{

//…

}

Use String.Empty instead of ""

Good:

If ( name == String.Empty )

{

// do something

}

Not Good:

If ( name == "" )

{

// do something

}

Avoid using member variables. Declare local variables wherever necessary and pass it to other methods instead of sharing a member variable between methods. If you share a member variable between methods, it will be difficult to track which method changed the value and when.

Use enum wherever required. Do not use numbers or strings to indicate discrete values.

Good:

enum MailType

{

Html,

PlainText,

Attachment

}

void SendMail (string message, MailType mailType)

{

switch ( mailType )

{

case MailType.Html:

// Do something

break;

case MailType.PlainText:

// Do something

break;

case MailType.Attachment:

// Do something

break;

default:

// Do something

break;

}

Not Good:

void SendMail (string message, string mailType)

{

switch ( mailType )

{

case "Html":

// Do something

break;

case "PlainText":

// Do something

break;

case "Attachment":

// Do something

break;

default:

// Do something

break;

}

Do not make the member variables public or protected. Keep them private and expose public/protected Properties.

The event handler should not contain the code to perform the required action. Rather call another method from the event handler.

Do not programmatically click a button to execute the same action you have written in the button click event. Rather, call the same method which is called by the button click event handler.

Never hardcode a path or drive name in code. Get the application path programmatically and use relative path.

Never assume that your code will run from drive "C:". You may never know, some users may run it from network or from a "Z:".
In the application start up, do some kind of "self check" and ensure all required files and dependencies are available in the expected locations. Check for database connection in start up, if required. Give a friendly message to the user in case of any problems.
Error messages should help the user to solve the problem. Never give error messages like "Error in Application", "There is an error" etc. Instead give specific messages like "Failed to update database. Please make sure the login id and password are correct."

When displaying error messages, in addition to telling what is wrong, the message should also tell what should the user do to solve the problem. Instead of message like "Failed to update database.", suggest what should the user do: "Failed to update database. Please make sure the login id and password are correct."

Show short and friendly message to the user. But log the actual error with all possible information. This will help a lot in diagnosing problems.

Do not have more than one class in a single file.

Have your own templates for each of the file types in Visual Studio. You can include your company name, copy right information etc in the template. You can view or edit the Visual Studio file templates in the folder C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\ItemTemplatesCache\CSharp\1033. (This folder has the templates for C#, but you can easily find the corresponding folders or any other language)

Avoid having very large files. If a single file has more than 1000 lines of code, it is a good candidate for refactoring. Split them logically into two or more classes.

Avoid public methods and properties, unless they really need to be accessed from outside the class. Use "internal" if they are accessed only within the same assembly.

Avoid passing too many parameters to a method. If you have more than 4~5 parameters, it is a good candidate to define a class or structure.

If you have a method returning a collection, return an empty collection instead of null, if you have no data to return. For example, if you have a method returning an ArrayList, always return a valid ArrayList. If you have no items to return, then return a valid ArrayList with 0 items. This will make it easy for the calling application to just check for the "count" rather than doing an additional check for "null".

Use the AssemblyInfo file to fill information like version number, description, company name, copyright notice etc.

Logically organize all your files within appropriate folders. Use 2 level folder hierarchies. You can have up to 10 folders in the root folder and each folder can have up to 5 sub folders. If you have too many folders than cannot be accommodated with the above mentioned 2 level hierarchy, you may need re factoring into multiple assemblies.

Make sure you have a good logging class which can be configured to log errors, warning or traces. If you configure to log errors, it should only log errors. But if you configure to log traces, it should record all (errors, warnings and trace). Your log class should be written such a way that in future you can change it easily to log to Windows Event Log, SQL Server, or Email to administrator or to a File etc without any change in any other part of the application. Use the log class extensively throughout the code to record errors, warning and even trace messages that can help you trouble shoot a problem.

If you are opening database connections, sockets, file stream etc, always close them in the finally block. This will ensure that even if an exception occurs after opening the connection, it will be safely closed in the finally block.

Declare variables as close as possible to where it is first used. Use one variable declaration per line.

Use StringBuilder class instead of String when you have to manipulate string objects in a loop. The String object works in weird way in .NET. Each time you append a string, it is actually discarding the old string object and recreating a new object, which is a relatively expensive operations.

Consider the following example:

public string ComposeMessage (string[] lines)

{

string message = String.Empty;

for (int i = 0; i < lines.Length; i++)

{

message += lines [i];

}

return message;

}

In the above example, it may look like we are just appending to the string object 'message'. But what is happening in reality is, the string object is discarded in each iteration and recreated and appending the line to it.

If your loop has several iterations, then it is a good idea to use StringBuilder class instead of String object.

See the example where the String object is replaced with StringBuilder.

public string ComposeMessage (string[] lines)

{

StringBuilder message = new StringBuilder();

for (int i = 0; i < lines.Length; i++)

{

message.Append( lines[i] );

}

return message.ToString();

}

ASP.NET

Do not use session variables throughout the code. Use session variables only within the classes and expose methods to access the value stored in the session variables. A class can access the session using System.Web.HttpCOntext.Current.Session

Do not store large objects in session. Storing large objects in session may consume lot of server memory depending on the number of users.

Always use style sheet to control the look and feel of the pages. Never specify font name and font size in any of the pages. Use appropriate style class. This will help you to change the UI of your application easily in future. Also, if you like to support customizing the UI for each customer, it is just a matter of developing another style sheet for them

Comments

Good and meaningful comments make code more maintainable. However,

Do not write comments for every line of code and every variable declared.

Use // or /// for comments. Avoid using /* … */

Write comments wherever required. But good readable code will require very less comments. If all variables and method names are meaningful, that would make the code very readable and will not need many comments.

Do not write comments if the code is easily understandable without comment. The drawback of having lot of comments is, if you change the code and forget to change the comment, it will lead to more confusion.

Fewer lines of comments will make the code more elegant. But if the code is not clean/readable and there are less comments, that is worse.

If you have to use some complex or weird logic for any reason, document it very well with sufficient comments.

If you initialize a numeric variable to a special number other than 0, -1 etc, document the reason for choosing that value.

The bottom line is, write clean, readable code such a way that it doesn't need any comments to understand.

Perform spelling check on comments and also make sure proper grammar and punctuation is used.

Exception Handling

Never do a 'catch exception and do nothing'. If you hide an exception, you will never know if the exception happened or not. Lot of developers uses this handy method to ignore non significant errors. You should always try to avoid exceptions by checking all the error conditions programmatically. In any case, catching an exception and doing nothing is not allowed. In the worst case, you should log the exception and proceed.

In case of exceptions, give a friendly message to the user, but log the actual error with all possible details about the error, including the time it occurred, method and class name etc.

Always catch only the specific exception, not generic exception.

Good:

void ReadFromFile ( string fileName )

{

try

{

// read from file.

}

catch (FileIOException ex)

{

// log error.

// re-throw exception depending on your case.

throw;

}

Not Good:

void ReadFromFile ( string fileName )

{

try

{

// read from file.

}

catch (Exception ex)

{

// Catching general exception is bad... we will never know whether

// it was a file error or some other error.

// Here you are hiding an exception.

// In this case no one will ever know that an exception happened.

return "";

}

No need to catch the general exception in all your methods. Leave it open and let the application crash. This will help you find most of the errors during development cycle. You can have an application level (thread level) error handler where you can handle all general exceptions. In case of an 'unexpected general error', this error handler should catch the exception and should log the error in addition to giving a friendly message to the user before closing the application, or allowing the user to 'ignore and proceed'.

When you re throw an exception, use the throw statement without specifying the original exception. This way, the original call stack is preserved.

Good:

catch

{

// do whatever you want to handle the exception

throw;

}

Not Good:

catch (Exception ex)

{

// do whatever you want to handle the exception

throw ex;

}

Do not write try-catch in all your methods. Use it only if there is a possibility that a specific exception may occur and it cannot be prevented by any other means. For example, if you want to insert a record if it does not already exists in database, you should try to select record using the key. Some developers try to insert a record without checking if it already exists. If an exception occurs, they will assume that the record already exists. This is strictly not allowed. You should always explicitly check for errors rather than waiting for exceptions to occur. On the other hand, you should always use exception handlers while you communicate with external systems like network, hardware devices etc. Such systems are subject to failure anytime and error checking is not usually reliable. In those cases, you should use exception handlers and try to recover from error.

Do not write very large try-catch blocks. If required, write separate try-catch for each task you perform and enclose only the specific piece of code inside the try-catch. This will help you find which piece of code generated the exception and you can give specific error message to the user.

Write your own custom exception classes if required in your application. Do not derive your custom exceptions from the base class SystemException. Instead, inherit from ApplicationException.

Extension method

2008-02-14T21:00:00.005+05:30

Extension methods enable you to "add" methods to existing types without creating
a new derived type, recompiling, or otherwise modifying the original type.
Extension methods are a special kind of static method, but they are called as if
they were instance methods on the extended type.

The most common extension methods are the LINQ standard query operators that add
query functionality to the existing System.Collections..::.IEnumerable
and System.Collections.Generic.IEnumerable(T)
types. To use the standard query operators, first bring them into scope with a
using System.Linq directive. Then any type that
implements IEnumerable(T) appears to have instance methods such as GroupBy,
OrderBy, Average, and so on.

You can see these additional methods in IntelliSense statement completion when
you type "dot" after an instance of an IEnumerable(T) type such as List(T) or Array.

The following example shows how to call the standard query operator OrderBy
method on an array of integers. The expression in parentheses is a lambda
expression. Many standard query operators take lambda expressions as parameters,
but this is not a requirement for extension methods.

class ExtensionMethods2
{

    static void Main()
    {    
        int[] ints = { 10, 45, 15, 39, 21, 26 };
        var result = ints.OrderBy(g => g);
        foreach (var i in result)
        {
            System.Console.Write(i + " ");
        }   
    }
}
//Output: 10 15 21 26 39 45

Extension methods are defined as static methods but are called by using instance method syntax. Their first parameter specifies which type the method operates on, and the parameter is preceded by the modifier.
Extension methods are only in scope when you explicitly import the namespace
into your source code with a using directive.

The following example shows an extension method defined for the System.String class. Note that it is defined inside a non-nested, non-generic static class:

namespace ExtensionMethods
{

public static class MyExtensions

{

public static int WordCount(this String str)

{
return str.Split( char[] { ' ', '.', '?' }, StringSplitOptions.RemoveEmptyEntries).Length;

}

}
using ExtensionMethods;
string s = "Hello Extension Methods";
int i = s.WordCount();

In code you invoke the extension method with instance method syntax. However, the intermediate language (IL) generated by the compiler translates your code into a call on the static method. Therefore, the principle of encapsulation is not really being violated. In fact, extension methods cannot access private variables in the type they are extending.

In general, you will probably be calling extension methods far more often than implementing your own. Because extension methods are called by using instance method syntax, no special knowledge is required to use them from client code. To enable extension methods for a particular type, just add a using directive for the namespace in which the methods are defined. For example, to use the standard query operators, add this using directive to your code:

Binding Extension Methods at Compile Time

You can use extension methods to extend a class or interface, but not to override them. An extension method with the same name and signature as an interface or class method will never be called. At compile time, extension methods always have lower priority than instance methods defined in the type itself. In other words, if a type has a method named P_Operation(int i), and you have an extension method with the same signature, the compiler will always bind to the instance method. When the compiler encounters a method invocation, it first looks for a match in the type's instance methods. If no match is found, it will search for any extension methods that are defined for the type, and bind to the first extension method that it finds

General Guidelines

In general, I recommend that you implement extension methods sparingly and only
when you have to. Whenever possible, client code that must extend an existing
type should do so by creating a new type derived from the existing type.

When using an extension method to extend a type whose source code you cannot change, you run the risk that a change in the implementation of the type will cause your extension method to break.

If you do implement extension methods for a given type, remember the following
two points:

An extension method will never be called if it has the same signature as a
method defined in the type.
Extension methods are brought into scope at the namespace level. For example, if
you have multiple static classes that contain extension methods in a single namespace named Extensions, they will all be brought into scope by the using Extensions; directive.

Implementers of class libraries should not use extension methods to avoid
creating new versions of assemblies. If you want to add significant new
functionality to a library, and you own the source code, you should follow the
standard .NET Framework guidelines for assembly versioning

Standard Query Operators for LINQ

2008-02-09T19:26:00.000+05:30

Where	Restriction operator based on predicate function
Select/SelectMany	Projection operators based on selector function
Take/Skip/ TakeWhile/SkipWhile	Partitioning operators based on position or predicate function
Join/GroupJoin	Join operators based on key selector functions
Concat
OrderBy/ThenBy/ OrderByDescending/ ThenByDescending	Sorting operators sorting in ascending or descending order based on optional key selector and comparer functions
Reverse	Sorting operator reversing the order of a sequence
GroupBy	Grouping operator based on optional key selector and comparer functions
Distinct	Set operator removing duplicates
Union/Intersect	Set operators returning set union or intersection
Except	Set operator returning set difference
AsEnumerable	Conversion operator to IEnumerable<T>
ToArray/ToList	Conversion operator to array or List<T>
ToDictionary/ToLookup	Conversion operators to Dictionary<K,T> or Lookup<K,T> (multi-dictionary) based on key selector function<
OfType/Cast	Conversion operators to IEnumerable<T> based on filtering by or conversion to type argument
SequenceEqual	Equality operator checking pairwise element equality
First/FirstOrDefault/ Last/LastOrDefault/ Single/SingleOrDefault	Element operators returning initial/final/only element based on optional predicate function
ElementAt/ ElementAtOrDefault	Element operators returning element based on position
DefaultIfEmpty	Element operator replacing empty sequence with default-valued singleton sequence
Range	Generation operator returning numbers in a range
Repeat	Generation operator returning multiple occurrences of a given value
Empty	Generation operator returning an empty sequence
Any/All	Quantifier checking for existential or universal satisfaction of predicate function
Contains	Quantifier checking for presence of a given element
Count/LongCount	Aggregate operators counting elements based on optional predicate function
Sum/Min/Max/Average	Aggregate operators based on optional selector functions
Aggregate	Aggregate operator accumulating multiple values based on accumulation function and optional seed

New Things in VS 2008

2008-02-05T20:53:00.000+05:30

1. LINQ Support

2. Expression Blend Support

3. Windows Presentation Foundation

4. VS 2008 Multi-Targeting Support

5. AJAX support for ASP.NET

6. JavaScript Debugging Support

7. Nested Master Page Support

8. LINQ Intellisense and Javascript Intellisense support for silverlight applications

9. Organize Imports or Usings

10. Intellisense Filtering

11. Intellisense Box display position

12. Visual Studio 2008 Split View

13. HTML JavaScript warnings, not as errors

14. Debugging .NET Framework Library Source Code

15. In built Silverlight Library

16. Visual Studio LINQ Designer

17. Inbuilt C++ SDK

18. Multilingual User Interface Architecture - MUI

19. Microsoft Popfly Support

20. Free Tools and Resources

Lambda Expressions

2008-02-03T20:09:00.000+05:30

A lambda expression is an anonymous function that can contain expressions and statements, and can be used to create delegates or expression tree types.

All lambda expressions use the lambda operator =>, which is read as "goes to". The left side of the lambda operator specifies the input parameters (if any) and the right side holds the expression or statement block. The lambda expression x => x * x is read "x goes to x times x." This expression can be assigned to a delegate type as follows:

delegate int del(int i);
del myDelegate = x => x * x;
int j = myDelegate(5); //j = 25
To create an expression tree type:

using System.Linq.Expressions;
// ...
Expression = x => x * x;
The => operator has the same precedence as assignment (=) and is right-associative.

Lambdas are used in method-based LINQ queries as arguments to standard query operator methods such as Where and Where(IQueryable, String, array<>[]()[]).

When you use method-based syntax to call the Where method in the Enumerable class (as you do in LINQ to Objects and LINQ to XML) the parameter is a delegate type System..::.Func<(Of <(T, TResult>)>). A lambda expression is the most convenient way to create that delegate. When you call the same method in, for example, the System.Linq..::.Queryable class (as you do in LINQ to SQL) then the parameter type is an System.Linq.Expressions..::.Expression where Func is any Func delegates with up to five input parameters. Again, a lambda expression is just a very concise way to construct that expression tree. The lambdas allow the Where calls to look similar although in fact the type of object created from the lambda is different.

In the previous example, notice that the delegate signature has one implicitly-typed input parameter of type int, and returns an int. The lambda expression can be converted to a delegate of that type because it also has one input parameter (x) and a return value that the compiler can implicitly convert to type int. (Type inference is discussed in more detail in the following sections.) When the delegate is invoked by using an input parameter of 5, it returns a result of 25.

Lambdas are not allowed on the left side of the is or as operator.

All restrictions that apply to anonymous methods also apply to lambda expressions. For more information, see Anonymous Methods (C# Programming Guide).

Expression Lambdas
A lambda expression with an expression on the right side is called an expression lambda. Expression lambdas are used extensively in the construction of Expression Trees. An expression lambda returns the result of the expression and takes the following basic form:

(input parameters) => expression
The parentheses are optional only if the lambda has one input parameter; otherwise they are required. Two or more input parameters are separated by commas enclosed in parentheses:

(x, y) => x == y
Sometimes it is difficult or impossible for the compiler to infer the input types. When this occurs, you can specify the types explicitly as shown in the following example:

(int x, string s) => s.Length > x
Specify zero input parameters with empty parentheses:

() => SomeMethod()
Note in the previous example that the body of an expression lambda can consist of a method call. However, if you are creating expression trees that will be consumed in another domain, such as SQL Server, you should not use method calls in lambda expressions. The methods will have no meaning outside the context of the .NET common language runtime.

A statement lambda resembles an expression lambda except that the statement(s) is enclosed in braces:

(input parameters) => {statement;}
The body of a statement lambda can consist of any number of statements; however, in practice there are typically no more than two or three.

delegate void TestDelegate(string s);
…
TestDelegate myDel = n => { string s = n + " " + "World"; Console.WriteLine(s); };
myDel("Hello");
Statement lambdas, like anonymous methods, cannot be used to create expression trees.

Lambdas with the Standard Query Operators
Many Standard query operators have an input parameter whose type is one of the Func<(Of <(T, TResult>)>) family of generic delegates. The Func<(Of <(T, TResult>)>) delegates use type parameters to define the number and type of input parameters, and the return type of the delegate. Func delegates are very useful for encapsulating user-defined expressions that are applied to each element in a set of source data. For example, consider the following delegate type:

public delegate TResult Func(TArg0 arg0)
The delegate can be instantiated as Func myFunc where int is an input parameter and bool is the return value. The return value is always specified in the last type parameter. Func defines a delegate with two input parameters, int and string, and a return type of bool. The following Func delegate, when it is invoked, will return true or false to indicate whether the input parameter is equal to 5:

Func myFunc = x => x == 5;
bool result = myFunc(4); // returns false of course
You can also supply a lambda expression when the argument type is an Expression, for example in the standard query operators that are defined in System.Linq.Queryable. When you specify an Expression argument, the lambda will be compiled to an expression tree.

A standard query operator, the Count method, is shown here:

int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };
int oddNumbers = numbers.Count(n => n % 2 == 1);
The compiler can infer the type of the input parameter, or you can also specify it explicitly. This particular lambda expression counts those integers (n) which when divided by two have a remainder of 1.

The following method will produce a sequence that contains all the elements in the numbers array that occur before the “9” because that is the first number in the sequence that does not meet the condition:

var firstNumbersLessThan6 = numbers.TakeWhile(n => n <>) with the greater than or equal operator (>=).

var firstSmallNumbers = numbers.TakeWhile((n, index) => n >= index);
Type Inference in Lambdas
When writing lambdas, you often do not have to specify a type for the input parameters because the compiler can infer the type based on the lambda body, the underlying delegate type, and other factors as described in the C# 3.0 Language Specification. For most of the standard query operators, the first input is the type of the elements in the source sequence. So if you are querying an IEnumerable, then the input variable is inferred to be a Customer object, which means you have access to its methods and properties:

customers.Where(c => c.City == "London");
The general rules for lambdas are as follows:

The lambda must contain the same number of parameters as the delegate type.

Each input parameter in the lambda must be implicitly convertible to its corresponding delegate parameter.

The return value of the lambda (if any) must be implicitly convertible to the delegate's return type.

Note that lambda expressions in themselves do not have a type because the common type system has no intrinsic concept of "lambda expression." However, it is sometimes convenient to speak informally of the "type" of a lambda expression. In these cases the type refers to the delegate type or Expression type to which the lambda expression is converted.

Variable Scope in Lambda Expressions
Lambdas can refer to outer variables that are in scope in the enclosing method or type in which the lambda is defined. Variables that are captured in this manner are stored for use in the lambda expression even if variables would otherwise go out of scope and be garbage collected. An outer variable must be definitely assigned before it can be consumed in a lambda expression. The following example demonstrates these rules:

delegate bool D();
delegate bool D2(int i);

class Test
{
D del;
D2 del2;
public void TestMethod(int input)
{
int j = 0;
// Initialize the delegates with lambda expressions.
// Note access to 2 outer variables.
// del will be invoked within this method.
del = () => { j = 10; return j > input; };

// del2 will be invoked after TestMethod goes out of scope.
del2 = (x) => {return x == j; };

// Demonstrate value of j:
// Output: j = 0
// The delegate has not been invoked yet.
Console.WriteLine("j = {0}", j);

// Invoke the delegate.
bool boolResult = del();

// Output: j = 10 b = True
Console.WriteLine("j = {0}. b = {1}", j, boolResult);
}

static void Main()
{
Test test = new Test();
test.TestMethod(5);

// Prove that del2 still has a copy of
// local variable j from TestMethod.
bool result = test.del2(10);

// Output: True
Console.WriteLine(result);

Console.ReadKey();
}
}

The following rules apply to variable scope in lambda expressions:

A variable that is captured will not be garbage-collected until the delegate that references it goes out of scope.

Variables introduced within a lambda expression are not visible in the outer method.

A lambda expression cannot directly capture a ref or out parameter from an enclosing method.

A return statement in a lambda expression does not cause the enclosing method to return.

A lambda expression cannot contain a goto statement, break statement, or continue statement whose target is outside the body or in the body of a contained anonymous function.