:: Microsoft Intermediate Language ::

Microsoft Intermediate Language (MSIL)

Introduction

MSIL stands for Microsoft Intermediate Language, similar to that of Java Byte code that is formed when you compile a Source Code. The main purpose of this Intermediate code formation is to have a platform independent code. That is once MSIL/Java Byte Code is available you can run on any platform provided appropriate run time environments are installed on the specific platform you wish to run. JVM in case of Java and CLR in case of .NET

The ILDasm (Intermediate Language Disassembler) program that ships with the .NET Framework SDK (You can find it in C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin\ildasm.exe) allows the user to see MSIL code in human-readable format. By using this utility, we can open any .NET executable file (EXE or DLL) and see MSIL code.

Just go to the path and click on "ildasm.exe" file and you will see a window which is shown below

Then you can open the .NET executable file by going to "File menu and click on Open link". In the open wizard select the dll that you want to view. Here i opened PringString.exe file and then the above window will look like as shown below.



Then you can manifest of the file by clicking on the MANIFEST and which is shown in below image.



You can view function by clicking on function name and is shown in the below image.



The ILAsm program (Intermediate Language Assembler) generates an executable file from the MSIL language. We can find this program in the WINNT\Microsoft.NET\Framework\vn.nn.nn directory.

Learning MSIL

Learning MSIL gives a user the chance to understand some things that are hidden from a programmer working with C# or VB.NET. Knowing MSIL gives more power to a .NET programmer. We never need to write programs in MSIL directly, but in some difficult cases it is very useful to open the MSIL code in ILDasm and see how things are done.

All operations in MSIL are executed on the stack. When a function is called, its parameters and local variables are allocated on the stack. Function code starting from this stack state may push some values onto the stack, make operations with these values, and pop values from the stack.
Execution of both MSIL commands and functions is done in three steps:

1. Push command operands or function parameters onto the stack.
2. Execute the MSIL command or call function. The command or function pops their operands (parameters) from the stack and pushes onto the stack result (return value).
3. Read result from the stack.

Steps 1 and 3 are optional. For example, the void function doesn't push a return value to the stack.

The stack contains objects of value types and references to objects of reference type. Reference type objects are kept in the heap.

MSIL commands used to push values onto the stack are called ld... (load). Commands used to pop values from the stack are called st... (store), because values are stored in variables. Therefore, we will call the push operation loading and the pop operation storing.

Sample Program

.assembly PrintString {}

/* Console.WriteLine("Hello, World)"*/

.method static public void main() il managed

{ .entrypoint // this function is application entry point
.maxstack 8

// *****************************************************

// Console.WriteLine("Hello, World)";

// *****************************************************

ldstr "Hello, World" // load string onto stack

// Call static System.Console.Writeline function

// (function pops string from the stack)

call void [mscorlib]System.Console::WriteLine(class System.String)

// *****************************************************************

ldstr "Press Enter to continue"

call void [mscorlib]System.Console::WriteLine(class System.String)

// Call the System.Console.Read function

call int32 [mscorlib]System.Console::Read()

// The pop instruction removes the top element from the stack.

// (remove number returned by Read() function)

pop

// *****************************************************************
ret

}

Save this file as PrintString.il on your desktop. "il" is the extension of the intermediate language file.

Then go to VS command prompt from "Start/Programs/Visual Studio .Net 2003/Visual Studio .Net tool/Visual Studio .Net 2003 Command Prompt". Then point to your desktop from the command prompt and execute your PrintString.il file by typing the following command.

-- ilasm printstring.il

Then a PrintString.exe file is created on the desktop. Clicking on the .exe file we can see the output of the program that we have written. The same .exe i opened with the ILDASM for viewing the code in the begining.

Even we can view the IL code of the .Net compatible file by tying following command in the command prompt of Visual Studio.

-- ildasm printstring.exe

By pressing the enter key on keyboard will will see the window shown in the second image above. So this way is very easy than the above one.

-:: Garbage Collection In .Net ::-

Garbage Collection In .NET

Garbage Collection is a technique introduced in Microsoft .NET that manages memory automatically. This article discusses the concepts of Garbage Collection and the strategies adopted by Microsoft .NET for handling managed memory efficiently. It also discusses the methods and properties of the System. GC class, the class that is responsible for controlling the garbage collector in the .NET environment.

What is Garbage Collection?

The Common Language Runtime (CLR) requires that you create objects in the managed heap, but you do not have to bother with cleaning up the memory once the object goes out of the scope or is no longer needed. This is unlike the strategies adopted in programming languages like C and C++ where you needed to cleanup the heap memory explicitly using a free function of C and delete operator of C++. Garbage collection refers to the strategy adapted by Microsoft .NET to free unused objects or objects that go out of the scope automatically.

A "garbage" object is one that is no longer needed, is unreachable from the root or goes out of the scope in which it is created. Microsoft .NET uses the information in the metadata to trace the object graph and detect the objects that need to be garbage collected. Objects that are not reachable from the root are referred to as garbage objects and are marked for garbage collection. It is to be noted here that there is a time gap between the time when an object is identified as garbage and the time when the object is actually collected. It is also to be noted that objects in the managed heap are stored in sequential memory locations. This is unlike C and C++ and makes allocation and de-allocation of objects faster.

About Garbage Collection:

Every program uses the resources like - memory buffers, network connections, database resources and so on. To use these resources memory must be allocated to represent the type.

Steps required to access the resource:

1. Allocate the memory for the type the represents the resource.
2. Initialize the memory to set initial state of the resource for making the resource available to use.
3. Now use the resource by the instance of the resource.
4. Tear down the state of the resource for clean up.
5. Free the memory by some mechanism.

The Garbage Collector of .Net will do the above steps automatically. So the developer need not to write any code or concentration on allocating memory to the resources and when to free the memory. .Net CLR has to allocate all the resource from mamaged heap. You never free the objects from managed heap and they will be automatically freed from the heap when those objects are not needed by the application.

Memory is not infinate. The GC must perform the task of freeing the memory and Garbage Collectors Optimized Engine will determines the best time for collection based on the allocation being made.

When GC performs the collection, It checks the heap for the objects which are not needed by the application and performs necessary actions to reclaim the memory.

However for automatic memory management, the garbage collector has to know the location of the roots i.e. it should know when an object is no longer in use by the application. This knowledge is made available to the GC in .NET by the inclusion of a concept know as metadata. Every data type used in .NET software includes metadata that describes it. With the help of metadata, the CLR knows the layout of each of the objects in memory, which helps the Garbage Collector in the compaction phase of Garbage collection. Without this knowledge the Garbage Collector wouldn't know where one object instance ends and the next begins.

Garbage Collection Algorithm:

Application Roots:

Every application has a set of roots. Roots identify storage locations, which refer to objects on the managed heap or to objects that are set to null.
For example:

• All the global and static object pointers in an application.
• Any local variable/parameter object pointers on a thread's stack.
• Any CPU registers containing pointers to objects in the managed heap.
• Pointers to the objects from Freachable queue
• The list of active roots is maintained by the just-in-time (JIT) compiler and common language runtime, and is made accessible to the garbage collector's algorithm.

Implementation:

The most commonly used strategy involves the mark and compact algorithm. This occurs in two phases, Mark and Compact.

Mark:

When the garbage collector starts running, it makes the assumption that all objects in the heap are garbage. In other words, it assumes that none of the application's roots refer to any objects in the heap.
The following steps are included in Phase I:

• The GC identifies live object references or application roots.
• It starts walking the roots and building a graph of all objects reachable from the roots.
• If the GC attempts to add an object already present in the graph, then it stops walking down that path. This serves two purposes. First, it helps performance significantly since it doesn't walk through a set of objects more than once. Second, it prevents infinite loops should you have any circular linked lists of objects. Thus cycles are handles properly.

Once all the roots have been checked, the garbage collector's graph contains the set of all objects that are somehow reachable from the application's roots and any objects that are not in the graph are not accessible by the application, and are therefore considered garbage.

Compact:

Move all the live objects to the bottom of the heap, leaving free space at the top.
Phase II includes the following steps:

• The garbage collector now walks through the heap linearly, looking for contiguous blocks of garbage objects (now considered free space).
• The garbage collector then shifts the non-garbage objects down in memory, removing all of the gaps in the heap.
• Moving the objects in memory invalidates all pointers to the objects. So the garbage collector modifies the application's roots so that the pointers point to the objects' new locations. In addition, if any object contains a pointer to another object, the garbage collector is responsible for correcting these pointers as well.

After all the garbage has been identified, all the non-garbage has been compacted, and all the non-garbage pointers have been fixed-up, a pointer is positioned just after the last non-garbage object to indicate the position where the next object can be added.

Finalization:

.NET Framework's garbage collection implicitly keeps track of the lifetime of the objects that an application creates, but fails when it comes to the unmanaged resources (i.e. a file, a window or a network connection) that objects encapsulate.

The unmanaged resources must be explicitly released once the application has finished using them. .NET Framework provides the Object.Finalize method: a method that the garbage collector must run on the object to clean up its unmanaged resources, prior to reclaiming the memory used up by the object. Since Finalize method does nothing, by default, this method must be overridden if explicit cleanup is required.

It would not be surprising if you will consider Finalize just another name for destructors in C++. Though, both have been assigned the responsibility of freeing the resources used by the objects, they have very different semantics. In C++, destructors are executed immediately when the object goes out of scope whereas a finalize method is called once when Garbage collection gets around to cleaning up an object.

The potential existence of finalizers complicates the job of garbage collection in .NET by adding some extra steps before freeing an object.

Whenever a new object, having a Finalize method, is allocated on the heap a pointer to the object is placed in an internal data structure called Finalization queue. When an object is not reachable, the garbage collector considers the object garbage. The garbage collector scans the finalization queue looking for pointers to these objects. When a pointer is found, the pointer is removed from the finalization queue and appended to another internal data structure called Freachable queue, making the object no longer a part of the garbage. At this point, the garbage collector has finished identifying garbage. The garbage collector compacts the reclaimable memory and the special runtime thread empties the freachable queue, executing each object's Finalize method.

The next time the garbage collector is invoked, it sees that the finalized objects are truly garbage and the memory for those objects is then, simply freed.

Thus when an object requires finalization, it dies, then lives (resurrects) and finally dies again. It is recommended to avoid using Finalize method, unless required. Finalize methods increase memory pressure by not letting the memory and the resources used by that object to be released, until two garbage collections. Since you do not have control on the order in which the finalize methods are executed, it may lead to unpredictable results.

Limits of the Garbage Collection:

Unused objects that are still referenced:

The biggest limitation of the garbage collector in .NET is a subtle one: while it is said as being able to detect and remove unused objects, it actually finds unreferenced objects. This is an important distinction: an object might never be referred to by a program ever again; but, while there is some path from it leading to an object that might still be used, it will never be released from memory. This leads to memory leaks; in .NET these occur when an object that will not be used again remains referenced.

Fragmentation of the heap:

A less widely known limitation in .NET is that of the large object heap. Objects that become part of this heap are never moved by the runtime, and this can lead to a program running out of memory prematurely. When some objects live longer than others, this causes the heap to form holes where objects used to be - this is known as fragmentation. The problem occurs when the program asks for a large block of memory but the heap has become so fragmented that there is no single region of memory big enough to accommodate it. A memory profiler can estimate the largest object that can be allocated by a program: if this is declining then this is likely to be the cause. An OutOfMemoryException caused by fragmentation will typically happen when the program apparently has a lot of free memory - on a 32-bit system, processes should be able to use at least 1.5Gb, but failures due to fragmentation will often start to occur before it is using that much memory.

The System.GC class

The System.GC class represents the garbage collector and contains many of methods and properties that are described in this section.

GC.Collect Method

This method is used to force a garbage collection of all the generations. It can also force a garbage collection of a particular generation passed to it as a parameter. The signatures of the overloaded Collect methods are:

public static void Collect();
public static void Collect(Integer int);

GC.GetTotalMemory Method

This method returns the total number of bytes that is allocated in the managed memory. This method accepts a boolean parameter. If the parameter is true, it indicates that it should wait for the garbage collector to finish.

GC.KeepAlive Method

This method extends the life time of an object passed to it as a parameter. The signature of this method is as follows:
public static void KeepAlive(object objToKeepAlive);

GC.ReRegisterForFinalize Method

This method re-registers an object for finalization, i.e., makes an object eligible for finalization. The method signature is as follows:
public static void ReRegisterForFinalize(objectobjToRegister);

GC.SupressFinalize Method

This method suppresses the finalization on an object. The prototype of this method is:
public static void SupressFinalize(object obj);

GC.GetGeneration Method

This method returns the current generation of an object or the same of the target of the weak reference. The signature of this overloaded method is:

System.GC.GetGeneration(object obj);
System.GC.GetGeneration(WeakReferenceweakReference);

GC.MaxGeneration Property

This property returns the maximum number of generations available.

GC.WaitForPendingFinalizers Method

This method blocks the current thread till the execution of all the pending finalizers is over. The signature of this method is:
public static void WaitForPendingFinalizers();

Microsoft Enterprise Library

Microsoft Enterprise Library

The Microsoft Enterprise Library is a collection of reusable software components (application blocks) designed to assist software developers with common enterprise development cross-cutting concerns (such as logging, validation, data access, exception handling, and many others). Application blocks are a type of guidance; they are provided as source code, test cases, and documentation that can be used "as is," extended, or modified by developers to use on complex, enterprise-level line-of-business development projects.

Goals for Enterprise Library

Enterprise Library is a collection of application blocks intended for use by developers who build complex, enterprise-level applications.

Enterprise Library is used when building applications that are typically to be deployed widely and to interoperate with other applications and systems. In addition, they generally have strict security, reliability, and performance requirements.

The goals of Enterprise Library are the following:

1. Consistency. All Enterprise Library application blocks feature consistent design patterns and implementation approaches.
2. Extensibility. All application blocks include defined extensibility points that allow developers to customize the behavior of the application blocks by adding their own code.
3. Ease of use. Enterprise Library offers numerous usability improvements, including a graphical configuration tool, a simpler installation procedure, and clearer and more complete documentation and samples.
4. Integration. Enterprise Library application blocks are designed to work well together or individually.

Community

The Enterprise Library has a thriving online community.
On this community site, you can post questions, provide feedback, or connect with other users for sharing ideas. Community members can also help Microsoft plan future releases of the Enterprise Library and/or related guidance, and download additional content such as extensions and training material.

Benefits

• Improved Productivity: Each of the Application Blocks provides several interfaces meant to satisfy common application concerns.
• Configuration Driven Design: Many technical decisions about the application behaviour can be delayed until configuration time of the application. For instance, if an application does not properly handle an exception, instead of adding another exception handler to the code, an administrator can configure an additional exception handling policy.
• Improved Testability: Many application areas can be reconfigured to improve testing of the application in isolation.

Application Blocks

The Application Blocks in Enterprise Library are designed to be as agnostic as possible to the application architecture, for example the Logging Application Block may be used equally in a web, smart client or service-oriented application. The patterns and practices team also produces more specialized Application Blocks that are not included in Enterprise Library, such as the User Interface Process Application Block, Aggregator Application Block, Updater Application Block and the Composite UI Application Block.
The patterns and practices team produces a number of other deliverables that leverage Enterprise Library Application Blocks. These include the Web Service Software Factory and Smart Client Software Factory.

Utilities

In addition to the Application Blocks, the standard Microsoft distribution of the Enterprise library includes:

• Configuration Console: to visually add an Application Block to an application's configuration.
• Security Database Console: to add roles, profiles and authorization rules to support the Security Application Block.

History

There have been several versions of the Microsoft Enterprise Library:

• Enterprise Library 1.0 (January 2005) - Deprecated
• Enterprise Library 1.1 (June 2005) - Deprecated
• Enterprise Library 2.0 (January 2006) - Active/Retired
• Enterprise Library 3.0 (April 2007) - Deprecated \
• Enterprise Library 3.1 (May 2007) - Active
• Enterprise Library 4.0 (May 2008) - Active
• Enterprise Library 4.1 (October 2008) - Current Enterprise Library 5.0 (early 2010) - Next in Development

Version 1.1

Two releases of Enterprise Library were released for .NET Framework 1.1. The first was released in January 2005, followed by a minor maintenance release in June 2005. The .NET 1.1 releases of Enterprise Library contained the following Application Blocks:

• Caching
• Configuration
• Cryptography
• Data Access
• Exception Handling
• Logging and Instrumentation Security

Version 2.0

In January 2006, a new version of Enterprise Library was released that targeted .NET Framework 2.0. The most significant change in this release was that the Configuration Application Block was removed, and the blocks were updated to use .NET's improved System.Configuration capabilities. This release also included significant improvements to the Logging Application Block, and much of the Security Application Block was removed due to similar capabilities provided in .NET Framework 2.0. The .NET 2.0 release of Enterprise Library contained the following Application Blocks:

• Caching
• Data Access
• Cryptography
• Exception Handling
• Logging Security

Version 3.0

In April 2007, Enterprise Library 3.0 was released. It contains new Application Blocks, a new Application Block Software factory designed to simplify the development of new Application Blocks and extensions, and new features providing better integration with .NET Framework 3.0. The 3.0 release of Enterprise Library contains the following Application Blocks:

• Caching
• Data Access
• Cryptography
• Exception Handling
• Logging
• Policy Injection
• Security
• Validation

Version 3.1

In May 2007, Enterprise Library 3.1 was released with minor enhancements to the Validation and Policy Injection Application Blocks.

Version 4.0

This release of Enterprise Library includes the following:

• Integration with the Unity Application Block
• Windows Management Instrumentation (WMI) 2.0 support and improved instrumentation
• Performance improvements (particularly, in the Logging Application Block)
• Pluggable Cache Managers
• Visual Studio 2008 support
• Bug fixes

Version 4.1

This release of Enterprise Library is a service release that includes the following:

• Unity interception mechanism and integration of the Policy Injection Application Block with the Unity Application Block
• Added support for generics in the Unity Application Block
• Added support for arrays in the Unity Application Block
• Performance improvements
• Usability improvements to the configuration tool
• Visual Studio 2008 Service Pack 1 support
• Bug fixes
  

Note: Existing public APIs (v3.1) are still supported.
The Application Block Software Factory and the Strong Naming Guidance Package are not included in this release but are available as a separate download. Thus, there is no longer a dependency on Guidance Automation Extensions (GAX).
For the detailed list of all changes, see About This Release of Enterprise Library.

Version 5.0

This is the next release that the patterns & practices team is planning now. See tentative backlog posted by Grigori Melnik, EntLib Product Owner.

Download:

You can download the libraries from the below link

http://msdn.microsoft.com/en-us/library/cc467894.aspx

.NET Assemblies

Introduction

You must have heard the word assembly many times in .NET documentation. In this article I will share some thing about .NET assemblies.

What is an assembly?

• An Assembly is a logical unit of code
• Assembly physically exist as DLLs or EXEs
• One assembly can contain one or more files
• The constituent files can include any file types like image files, text files etc. along with DLLs or EXEs
• When you compile your source code by default the exe/dll generated is actually an assembly
• Unless your code is bundled as assembly it can not be used in any other application
• When you talk about version of a component you are actually talking about version of the assembly to which the component belongs.
• Every assembly file contains information about itself. This information is called as Assembly Manifest.

What is assembly manifest?

• Assembly manifest is a data structure which stores information about an assembly
• This information is stored within the assembly file (DLL/EXE) itself
• The information includes version information, list of constituent files etc.

What is private and shared assembly?

The assembly which is used only by a single application is called as private assembly. Suppose you created a DLL which encapsulates your business logic. This DLL will be used by your client application only and not by any other application. In order to run the application properly your DLL must reside in the same folder in which the client application is installed. Thus the assembly is private to your application.

Suppose that you are creating a general purpose DLL which provides functionality which will be used by variety of applications. Now, instead of each client application having its own copy of DLL you can place the DLL in 'global assembly cache'. Such assemblies are called as shared assemblies.

What is Global Assembly Cache?

Global assembly cache is nothing but a special disk folder where all the shared assemblies will be kept. It is located under :\WinNT\Assembly folder.

How assemblies avoid DLL Hell?

As stated earlier most of the assemblies are private. Hence each client application refers assemblies from its own installation folder. So, even though there are multiple versions of same assembly they will not conflict with each other. Consider following example :

• You created assembly Assembly1
• You also created a client application which uses Assembly1 say Client1
• You installed the client in C:\MyApp1 and also placed Assembly1 in this folder
• After some days you changed Assembly1
• You now created another application Client2 which uses this changed Assembly1
• You installed Client2 in C:\MyApp2 and also placed changed Assembly1 in this folder
• Since both the clients are referring to their own versions of Assembly1 everything goes on smoothly

Now consider the case when you develop assembly that is shared one. In this case it is important to know how assemblies are versioned. All assemblies has a version number in the form:

major.minor.build.revision

If you change the original assembly the changed version will be considered compatible with existing one if the major and minor versions of both the assemblies match.

When the client application requests assembly the requested version number is matched against available versions and the version matching major and minor version numbers and having most latest build and revision number are supplied.

How do I create shared assemblies?

Following steps are involved in creating shared assemblies :

• Create your DLL/EXE source code
• Generate unique assembly name using SN utility
• Sign your DLL/EXE with the private key by modifying AssemblyInfo file
• Compile your DLL/EXE
• Place the resultant DLL/EXE in global assembly cache using AL utility

How do I create unique assembly name?

Microsoft now uses a public-private key pair to uniquely identify an assembly. These keys are generated using a utility called SN.exe (SN stands for shared name). The most common syntax of is :

sn -k mykeyfile.key

Where k represents that we want to generate a key and the file name followed is the file in which the keys will be stored.

How do I sign my DLL/EXE?

Before placing the assembly into shared cache you need to sign it using the keys we just generated. You mention the signing information in a special file called AssemblyInfo. Open the file from VS.NET solution explorer and change it to include following lines :

[assembly:AssemblyKeyFile("file_path")]

Now recompile the project and the assembly will be signed for you.

Note : You can also supply the key file information during command line compilation via /a.keyfile switch.

How do I place the assembly in shared cache?

Microsoft has provided a utility called AL.exe to actually place your assembly in shared cache.

AL /i:my_dll.dll

Now your dll will be placed at proper location by the utility.

Hands On...

Now, that we have understood the basics of assemblies let us apply our knowledge by developing a simple shared assembly.

In this example we will create a VB.NET component called SampleGAC ( GAC stands for Global Assembly Cache). We will also create a key file named sample.key. We will sign our component with this key file and place it in Global Assembly Cache.

• Step 1 : Creating our sample component

Here is the code for the component. It just includes one method which returns a string.

imports system

namespace BAJComponents
 public class Sample
  public function GetData() as string
   return "hello world"
  end function
 end class
end namespace 

• Step 2 : Generate a key file

To generate the key file issue following command at command prompt.

sn -k sample.key

This will generate the key file in the same folder

• Step 3 : Sign your component with the key

Now, wee will sign the assembly with the key file we just created.

vbc sampleGAC.vb /t:library /a.keyfile:sample.key

• Step 4 : Host the signed assembly in Global Assembly Cache

We will use AL utility to place the assembly in Global Assembly Cache.

AL /i:sampleGAC.dll

After hosting the assembly just go to WINNT\Assembly folder and you will find your assembly listed there. Note how the assembly folder is treated differently that normal folders.

Click here to view the screen shot

• Step 5 : Test that our assembly works

Now, we will create a sample client application which uses our shared assembly. Just create a sample code as listed below :

imports system
imports BAJComponents
public class SampleTest
 shared sub main()
  dim x as new sample
  dim s as string=x.getdata()
  console.writeline(s)
 end sub
end class 

Compile above code using :

vbc sampletest.vb /t:exe /r:

Now, copy the resulting EXE in any other folder and run it. It will display "Hello World" indicating that it is using our shared assembly.

What are the Good Qualities of a Developer??

A developer doesn’t becomes a good developer simply by using a particular programming language.The rapid development environments made this industry evolve faster then anything other I know today. This has positive and negative outcomes. Today’s developers can choose from a rich variety of programming languages, development tools and platforms, but it’s a lot harder to set up a secure, scalable environment. Hardware and software are getting more complex every day, it’s much harder to learn about new technologies today then it was yesterday.Here are some qualities…

Languages and Tools: The first skill any developer needs to have is ability to work with programming languages and the main tools that are used with them. These could include build tools, IDEs, web frameworks, messaging APIs.

Programming Paradigm: Having a good understanding of object orientation which is vital for writing maintainable code with imperative languages. An understanding of ways to approach different problems you might encounter in enterprise development by knowing different patterns and when to apply them is also useful.

Domain Specific Knowledge: Specific knowledge about the domain is vital for writing a system which is closely linked to the problems it is trying to solve.Although a lot of this knowledge is acquired by the Business Analyst on the project if Developers can gain it too then conversations with users will be much easier to deal with as amongst other things the terminology they use will make sense.

People Skills: One of the most important skills in software development is the ability to work effectively with other people - fellow developers, Quality/Business Analysts, clients, users, the list is endless. If you can do this effectively then you go a long way to ensuring your success.

Problem Solving: The ability to solve problems that don't have an obvious solution is key in software. Coding wise it could be debugging a class-path issue when deploying your application to JBoss or finding a tricky bug that a test reveals.

Good Communication skills: In the software world, people usually define good communication skills as fluency in a spoken language. That's not really what it is. It is how effectively you are able to communicate with others. As a 'good' developer, you should be able to express yourself well, listen well, as well as manage the communication process well.

Read Books: Read plenty of them to get a good idea of different technologies. Reading books gives you quick and handy insight into a technology. You should choose books that are usually written by known professionals who recommend best practices and different methods of solving a business problem using the technology. During the course of time, you will learn to develop your own methods. Who knows you may one day write a book!!
Practice, Practice and Practice: A lot of developers having good amount of theoretical knowledge. They read a lot of books and technical material. However when it comes to applying that knowledge, they take a back foot. That is because they do not practice. Efficiency and effectiveness in your work can only be attained if you practice code. The only way you can make a good developer of yourself is to practice, and then practice some more.
Follow Patterns and Best Practices : Patterns & practices reflect technical guidance, technical problem domain and engineering practices based on real-world experiences. The process to learn it is gradual, but once done; it can save you a lot of time and efforts and enable you to work smartly. Follow a Code Design Guideline. Always use a code analysis tools that will evaluate and analyze your code.

Discussion/Newsgroup: Participating in communities develops the quality of leadership and contribution, both ingredients of success. Having participated in a good technical discussion on the community leaves you with a feeling of self-satisfaction. It also increases your knowledge, as you find smart people who can validate your solutions, as you validate theirs. It also teaches you to appreciate suggestions. Do not forget to 'pat someone on the back' if he/her has made a positive contribution. Believe me it makes all the difference.

Knowledge of Networking and Databases: People may contradict this point, but a good developer should know the basics of networking and databases. Almost all the solutions that we create, involve interactions with networks and databases. Having knowledge of these two, helps you write better code and saves you on a lot of time too.

Blog/ Write Articles: How many of us can remember everything? I cannot. So I document them. It helps me to reference stuff when I need them. Over and above, it also helps me get some good feedback from readers and shows me multiple approaches to do the same stuff. I have received a lot of feedback about my work, some good and some not so good. However, I do validate them and learn from this process. It develops the developer in you.

KISS: Hey its not about that KISS ur thinking its a Keep Implementations/Approaches Short and Simple. Do not over complicate things by using jargons, which people find it hard to understand. The key is to simplify your designs and avoid over-engineering things.

Think as a Tester: Developers and Testers; two sets of people from different camps, ready to take on each other. I have observed that the intersection of the two produces good results. It does not harm taking off the developer's hat for some time and putting on the tester's hat. In fact, in the long run it helps you reduce bugs/defects in your code. You develop a mindset of about breaking your code, when you are creating one.

Consistency is the name of the game: Do you hop jobs too often or are bitten by the 'salary' bug? If yes, then it’s time for you to sit down, relax and plan. Invest time in thinking and let your decisions not be spontaneous. To move ahead, you need a solid foundation and that comes with consistency.

Attend technology seminars and events: If there is one hosted in your city, make sure you take out time to attend one. Most of them are free and provide a valuable source of information about new technologies.

Jack of all or Master of One?: Well that's a difficult one to answer. In today's scenario, you have to master more than one technology. Practically it is quite difficult to do so, but the good ones do it. However the key is adaptability over here. If you are good at any one technology and confident in it, given an opportunity, it would be easier for to relate to a new technology in a short period of time. Try it out as it enables you to compare technologies and make decisions, once you have worked with them.

Stop complaining : Did the software fail or are the testers giving you a tough time by finding a lot of bugs? A natural tendency for a lot of developers is to react and then overreact in such situations. While the reaction is natural, it may not be desirable. Analyze why the software failed or why was the bug reported. It is going to be a learning experience and will help you in your future projects.
At the end, just remember that you are not going to remain a programmer for ever. So once you are satisfied and get a feeling that you have proven yourself as a good programmer, it’s time to re-program yourself. Expand your interests. Development is just a part of the process. Understanding the users and business is in itself an art, one should aim for and should master over a period of time.

Most Dangerous Programming Errors

Insufficient Input Validation: "Software coding flaws emerge mainly from a lack of developers understanding one basic principle: Malicious users will not do what you expect them to do,". Failure to validate input "is the No. 1 issue affecting Web-based applications and gives rise to attacks such as SQL injection."

Improper Encoding or Escaping of Output: This is a leading issue behind cross-site scripting (XSS) attacks. Web apps often lose track of user-supplied data, failing to properly encode the output to HTML when returned to the user. "This allows attackers to send malicious JavaScript to other users that will execute within their browsers," .

Error Message Information Leakage: Web apps "give out way too much information when they encounter errors," allowing attackers to piece together a view of the overall system. In the worst case, "They can even use the error pages as the conduit to extract out customer data from databases."

System.Data.DataSetExtensions Config Error in Visual Studio 2008

Below error is shown when we build application developed in VS 2008

ASP.NET runtime error: Could not load file or assembly ‘System.Data.DataSetExtensions, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089′ or one of its dependencies. The system cannot find the file specified



The above error is caused when we already have VS 2005 and installing VS 2008 causes this error.

What happened in this case is VS 2008 is still pointing to Version 2.0.
So to solve this

1. Right click the application in Solution Explorer
2. Select Property Page
3. References Item
4. Select Version 2.0 DLL and select Remove button.
5. Now building this application will close this issue
6. 
   

Happy Coding........ :)


Thanks,
Kash [Surya Prakash]