Folks,

            There is a Usniversal Web Service Consuming tool Available which will help you in consuming the Web Services. Using this tool you can call the webservice by giving WSDL address and access to web methods and its response by giving appropriate parameters. This will also helps users in testing the Webservices request and response.

 

Click on below link to download the tool.

 

Swapnil (Swaps)

 

Folks

 

 

Earlier this month at TechEd Microsoft announced the official name of Visual Studio "Orcas" - which will be called Visual Studio 2008.  Microsoft also announced that the official name for the .NET Framework "Orcas" release will be called .NET Framework 3.5 (it includes the new LINQ support, integrated ASP.NET AJAX support, new ASP.NET data controls, and more).

VS 2008 and .NET 3.5 Beta 2 will ship later this summer, and the Beta 2 release will support a go-live license for those who want to put applications into production using the new features immediately.

http://weblogs.asp.net/scottgu/archive/2007/06/20/vs-2008-multi-targeting-support.aspx

Swapnil (swaps)

http://swapsnet.spaces.live.com/

 

 

 

Deploying Web-based applications in debug mode is a very common mistake. Virtually all Web-based applications require some debugging. Visual Studio 2005 will even automatically modify the Web.config file to allow debugging when you start to debug your application. And, since deploying ASP.NET applications is as simple as copying the files from the development folder into the deployment folder, it's easy to see how development configuration settings can accidentally make it into production, compromising application security.

Vulnerable configuration:

<configuration>

<system.web>

<compilation debug="true">

Secure configuration:

<configuration>

<system.web>

<compilation debug="false">

Like the first two application security vulnerabilities described in this list, leaving debugging enabled is dangerous because you are providing inside information to end users who shouldn't have access to it, and who may use it to attack your Web-based applications. For example, if you have enabled debugging and disabled custom errors in your application, then any error message displayed to an end user of your Web-based applications will include not only the server information, a detailed exception message, and a stack trace, but also the actual source code of the page where the error occurred.

Unfortunately, this configuration setting isn't the only way that source code might be displayed to the user. Here's a story that illustrates why developers shouldn't concentrate solely on one type of configuration setting to improve application security. In early versions of Microsoft's ASP.NET AJAX framework, some controls would return a stack trace with source code to the client browser whenever exceptions occurred. This behavior happened whenever debugging was enabled, regardless of the custom error setting in the configuration. So, even if you properly configured your Web-based applications to display non-descriptive messages when errors occurred, you could still have unexpectedly revealed your source code to your end users if you forgot to disable debugging.

To disable debugging, set the value of the "debug" attribute of the <compilation> element to "false."

Swapnil (Swaps)

http://swapsnet.spaces.live.com/

Source = http://www.codeproject.com/useritems/web-based-applications.asp

 

Assemblies in .NET Framework

Assemblies are a fundamental part of programming with the .NET Framework. An assembly performs the following functions:

·                       It contains code that the common language runtime executes. Microsoft intermediate language (MSIL) code in a portable executable (PE) file will not be executed if it does not have an associated assembly manifest. Note that each assembly can have only one entry point (that is, DllMain, WinMain, or Main).

·                       It forms a security boundary. An assembly is the unit at which permissions are requested and granted. For more information about security boundaries as they apply to assemblies, see Assembly Security Considerations.

·                       It forms a type boundary. Every type's identity includes the name of the assembly in which it resides. A type called MyType loaded in the scope of one assembly is not the same as a type called MyType loaded in the scope of another assembly.

·                       It forms a reference scope boundary. The assembly's manifest contains assembly metadata that is used for resolving types and satisfying resource requests. It specifies the types and resources that are exposed outside the assembly. The manifest also enumerates other assemblies on which it depends.

·                       It forms a version boundary. The assembly is the smallest versionable unit in the common language runtime; all types and resources in the same assembly are versioned as a unit. The assembly's manifest describes the version dependencies you specify for any dependent assemblies. For more information about versioning, see Assembly Versioning.

·                       It forms a deployment unit. When an application starts, only the assemblies that the application initially calls must be present. Other assemblies, such as localization resources or assemblies containing utility classes, can be retrieved on demand. This allows applications to be kept simple and thin when first downloaded. For more information about deploying assemblies, see Deploying Applications.

·                       It is the unit at which side-by-side execution is supported. For more information about running multiple versions of an assembly, see Assemblies and Side-by-Side Execution.

Assemblies can be static or dynamic. Static assemblies can include .NET Framework types (interfaces and classes), as well as resources for the assembly (bitmaps, JPEG files, resource files, and so on). Static assemblies are stored on disk in portable executable (PE) files. You can also use the .NET Framework to create dynamic assemblies, which are run directly from memory and are not saved to disk before execution. You can save dynamic assemblies to disk after they have executed.

There are several ways to create assemblies. You can use development tools, such as Visual Studio 2005, that you have used in the past to create .dll or .exe files. You can use tools provided in the .NET Framework SDK to create assemblies with modules created in other development environments. You can also use common language runtime APIs, such as Reflection.Emit, to create dynamic assemblies.

Swapnil (Swaps)

http://swapsnet.spaces.live.com/

Cross - Language Interoperability

Language interoperability is the ability of code to interact with code that is written using a different programming language. Language interoperability can help maximize code reuse and, therefore, improve the efficiency of the development process.

Because developers use a wide variety of tools and technologies, each of which might support different features and types, it has historically been difficult to ensure language interoperability. However, language compilers and tools that target the common language runtime benefit from the runtime's built-in support for language interoperability.

The common language runtime provides the necessary foundation for language interoperability by specifying and enforcing a common type system and by providing metadata. Because all languages targeting the runtime follow the common type system rules for defining and using types, the usage of types is consistent across languages. Metadata enables language interoperability by defining a uniform mechanism for storing and retrieving information about types. Compilers store type information as metadata, and the common language runtime uses this information to provide services during execution; the runtime can manage the execution of Multilanguage applications because all type information is stored and retrieved in the same way, regardless of the language the code was written in.

Managed code benefits from the runtime's support for language interoperability in the following ways:

·                       Types can inherit implementation from other types, pass objects to another type's methods, and call methods defined on other types, regardless of the language the types are implemented in.

·                       Debuggers, profilers, or other tools are required to understand only one environment—the Microsoft intermediate language (MSIL) and metadata for the common language runtime—and they can support any programming language that targets the runtime.

·                       Exception handling is consistent across languages. Your code can throw an exception in one language and that exception can be caught and understood by an object written in another language.

·                       To ensure that your managed code is accessible to developers using any programming language, the .NET Framework provides the Common Language Specification (CLS), which describes a fundamental set of language features and defines rules for how those features are used. For more information about CLS compliance in components and tools, see Writing CLS-Compliant Code.

 

Swapnil (Swaps)

http://Swapsnet.spaces.live.com/

 

Metadata Overview 

Metadata is binary information describing your program that is stored either in a common language runtime portable executable (PE) file or in memory. When you compile your code into a PE file, metadata is inserted into one portion of the file, while your code is converted to Microsoft intermediate language (MSIL) and inserted into another portion of the file. Every type and member defined and referenced in a module or assembly is described within metadata. When code is executed, the runtime loads metadata into memory and references it to discover information about your code's classes, members, inheritance, and so on.

Metadata describes every type and member defined in your code in a language-neutral manner. Metadata stores the following information:

·                       Description of the assembly.

o                                              Identity (name, version, culture, public key).

o                                              The types that are exported.

o                                              Other assemblies that this assembly depends on.

o                                              Security permissions needed to run.

·                       Description of types.

o                                              Name, visibility, base class, and interfaces implemented.

o                                              Members (methods, fields, properties, events, nested types).

·                       Attributes.

o                                              Additional descriptive elements that modify types and members.

Benefits of Metadata

Metadata is the key to a simpler programming model, eliminating the need for Interface Definition Language (IDL) files, header files, or any external method of component reference. Metadata allows .NET languages to describe themselves automatically in a language-neutral manner, unseen by both the developer and the user. Additionally, metadata is extensible through the use of attributes. Metadata provides the following major benefits:

·                       Self-describing files.

Common language runtime modules and assemblies are self-describing. A module's metadata contains everything needed to interact with another module. Metadata automatically provides the functionality of IDL in COM, allowing you to use one file for both definition and implementation. Runtime modules and assemblies do not even require registration with the operating system. As a result, the descriptions used by the runtime always reflect the actual code in your compiled file, which increases application reliability.

·                       Language interoperability and easier component-based design.

Metadata provides all the information required about compiled code for you to inherit a class from a PE file written in a different language. You can create an instance of any class written in any managed language (any language that targets the common language runtime) without worrying about explicit marshaling or using custom interoperability code.

·                       Attributes.

The .NET Framework allows you to declare specific kinds of metadata, called attributes, in your compiled file. Attributes can be found throughout the .NET Framework and are used to control in more detail how your program behaves at run time. Additionally, you can emit your own custom metadata into .NET Framework files through user-defined custom attributes.

 

Common Type System 

The common type system defines how types are declared, used, and managed in the runtime, and is also an important part of the runtime's support for cross-language integration. The common type system performs the following functions:

·                       Establishes a framework that helps enable cross-language integration, type safety, and high performance code execution.

·                       Provides an object-oriented model that supports the complete implementation of many programming languages.

·                       Defines rules that languages must follow, which helps ensure that objects written in different languages can interact with each other.

Classification of Types

The common type system supports two general categories of types, each of which is further divided into subcategories:

·                       Value types

Value types directly contain their data, and instances of value types are either allocated on the stack or allocated inline in a structure. Value types can be built-in (implemented by the runtime), user-defined, or enumerations. Value types cannot be null and must always contain data. That's why for each value type there is always a default value. Value types are always passed by value – that is, in our functions, we always deal with the copy of the value, leaving the original value unchanged. Most of the value types are not more than 12 to 16 bytes in size – as they are located in the stack, they should not consume much memory. 

·                       Reference types

Reference types store a reference to the value's memory address, and are allocated on the heap. Reference types can be self-describing types, pointer types, or interface types. The type of a reference type can be determined from values of self-describing types. Self-describing types are further split into arrays and class types. The class types are user-defined classes, boxed value types, and delegates.

Variables that are value types each have their own copy of the data, and therefore operations on one variable do not affect other variables. Variables that are reference types can refer to the same object; therefore, operations on one variable can affect the same object referred to by another variable.

All types derive from the System.Object base type.

Swapnil (Swaps)

http://swapsnet.spaces.live.com/

Garbage Collector - Generations and Performance

To optimize the performance of the garbage collector, the managed heap is divided into three generations: 0, 1, and 2. The runtime's garbage collection algorithm is based on several generalizations that the computer software industry has discovered to be true by experimenting with garbage collection schemes. First, it is faster to compact the memory for a portion of the managed heap than for the entire managed heap. Secondly, newer objects will have shorter lifetimes and older objects will have longer lifetimes. Lastly, newer objects tend to be related to each other and accessed by the application around the same time.

The runtime's garbage collector stores new objects in generation 0. Objects created early in the application's lifetime that survive collections are promoted and stored in generations 1 and 2. The process of object promotion is described later in this topic. Because it is faster to compact a portion of the managed heap than the entire heap, this scheme allows the garbage collector to release the memory in a specific generation rather than release the memory for the entire managed heap each time it performs a collection.

In reality, the garbage collector performs a collection when generation 0 is full. If an application attempts to create a new object when generation 0 is full, the garbage collector discovers that there is no address space remaining in generation 0 to allocate for the object. The garbage collector performs a collection in an attempt to free address space in generation 0 for the object. The garbage collector starts by examining the objects in generation 0 rather than all objects in the managed heap. This is the most efficient approach, because new objects tend to have short lifetimes, and it is expected that many of the objects in generation 0 will no longer be in use by the application when a collection is performed. In addition, a collection of generation 0 alone often reclaims enough memory to allow the application to continue creating new objects.

After the garbage collector performs a collection of generation 0, it compacts the memory for the reachable objects as explained in Releasing Memory earlier in this topic. The garbage collector then promotes these objects and considers this portion of the managed heap generation 1. Because objects that survive collections tend to have longer lifetimes, it makes sense to promote them to a higher generation. As a result, the garbage collector does not have to reexamine the objects in generations 1 and 2 each time it performs a collection of generation 0.

After the garbage collector performs its first collection of generation 0 and promotes the reachable objects to generation 1, it considers the remainder of the managed heap generation 0. It continues to allocate memory for new objects in generation 0 until generation 0 is full and it is necessary to perform another collection. At this point, the garbage collector's optimizing engine determines whether it is necessary to examine the objects in older generations. For example, if a collection of generation 0 does not reclaim enough memory for the application to successfully complete its attempt to create a new object, the garbage collector can perform a collection of generation 1, then generation 0. If this does not reclaim enough memory, the garbage collector can perform a collection of generations 2, 1, and 0. After each collection, the garbage collector compacts the reachable objects in generation 0 and promotes them to generation 1. Objects in generation 1 that survive collections are promoted to generation 2. Because the garbage collector supports only three generations, objects in generation 2 that survive a collection remain in generation 2 until they are determined to be unreachable in a future collection.

Swapnil (Swaps)

http://swapsnet.spaces.live.com/

Garbage Collector 

Automatic memory management is one of the services that the common language runtime provides during Managed Execution. The common language runtime's garbage collector manages the allocation and release of memory for an application. For developers, this means that you do not have to write code to perform memory management tasks when you develop managed applications. Automatic memory management can eliminate common problems, such as forgetting to free an object and causing a memory leak, or attempting to access memory for an object that has already been freed. This section describes how the garbage collector allocates and releases memory.

Allocating Memory

When you initialize a new process, the runtime reserves a contiguous region of address space for the process. This reserved address space is called the managed heap. The managed heap maintains a pointer to the address where the next object in the heap will be allocated. Initially, this pointer is set to the managed heap's base address. All reference types are allocated on the managed heap. When an application creates the first reference type, memory is allocated for the type at the base address of the managed heap. When the application creates the next object, the garbage collector allocates memory for it in the address space immediately following the first object. As long as address space is available, the garbage collector continues to allocate space for new objects in this manner.

Allocating memory from the managed heap is faster than unmanaged memory allocation. Because the runtime allocates memory for an object by adding a value to a pointer, it is almost as fast as allocating memory from the stack. In addition, because new objects that are allocated consecutively are stored contiguously in the managed heap, an application can access the objects very quickly.

Releasing Memory

The garbage collector's optimizing engine determines the best time to perform a collection based on the allocations being made. When the garbage collector performs a collection, it releases the memory for objects that are no longer being used by the application. It determines which objects are no longer being used by examining the application's roots. Every application has a set of roots. Each root either refers to an object on the managed heap or is set to null. An application's roots include global and static object pointers, local variables and reference object parameters on a thread's stack, and CPU registers. The garbage collector has access to the list of active roots that the just-in-time (JIT) compiler and the runtime maintain. Using this list, it examines an application's roots, and in the process creates a graph that contains all the objects that are reachable from the roots.

Objects that are not in the graph are unreachable from the application's roots. The garbage collector considers unreachable objects garbage and will release the memory allocated for them. During a collection, the garbage collector examines the managed heap, looking for the blocks of address space occupied by unreachable objects. As it discovers each unreachable object, it uses a memory-copying function to compact the reachable objects in memory, freeing up the blocks of address spaces allocated to unreachable objects. Once the memory for the reachable objects has been compacted, the garbage collector makes the necessary pointer corrections so that the application's roots point to the objects in their new locations. It also positions the managed heap's pointer after the last reachable object. Note that memory is compacted only if a collection discovers a significant number of unreachable objects. If all the objects in the managed heap survive a collection, then there is no need for memory compaction.

To improve performance, the runtime allocates memory for large objects in a separate heap. The garbage collector automatically releases the memory for large objects. However, to avoid moving large objects in memory, this memory is not compacted.

Swapnil (Swaps)

http://swapsnet.spaces.live.com/

Just In Time Compiler - Native Code 

Before you can run Microsoft intermediate language (MSIL), it must be converted by a .NET Framework just-in-time (JIT) compiler to native code, which is CPU-specific code that runs on the same computer architecture as the JIT compiler. Because the common language runtime supplies a JIT compiler for each supported CPU architecture, developers can write a set of MSIL that can be JIT-compiled and run on computers with different architectures. However, your managed code will run only on a specific operating system if it calls platform-specific native APIs, or a platform-specific class library.

JIT compilation takes into account the fact that some code might never get called during execution. Rather than using time and memory to convert all the MSIL in a portable executable (PE) file to native code, it converts the MSIL as needed during execution and stores the resulting native code so that it is accessible for subsequent calls. The loader creates and attaches a stub to each of a type's methods when the type is loaded. On the initial call to the method, the stub passes control to the JIT compiler, which converts the MSIL for that method into native code and modifies the stub to direct execution to the location of the native code. Subsequent calls of the JIT-compiled method proceed directly to the native code that was previously generated, reducing the time it takes to JIT-compile and run the code.

As part of compiling MSIL to native code, code must pass a verification process unless an administrator has established a security policy that allows code to bypass verification. Verification examines MSIL and metadata to find out whether the code is type safe, which means that it only accesses the memory locations it is authorized to access. Type safety helps isolate objects from each other and therefore helps protect them from inadvertent or malicious corruption. It also provides assurance that security restrictions on code can be reliably enforced.

The runtime relies on the fact that the following statements are true for code that is verifiably type safe:

·                       A reference to a type is strictly compatible with the type being referenced.

·                       Only appropriately defined operations are invoked on an object.

·                       Identities are what they claim to be.

 

Swapnil (Swaps)

http://swapsnet.spaces.live.com

MSIL Microsoft Intermediate Language

When compiling to managed code, the compiler translates your source code into Microsoft intermediate language (MSIL), which is a CPU-independent set of instructions that can be efficiently converted to native code. MSIL includes instructions for loading, storing, initializing, and calling methods on objects, as well as instructions for arithmetic and logical operations, control flow, direct memory access, exception handling, and other operations. Before code can be run, MSIL must be converted to CPU-specific code, usually by a Just In Time Compiler. Because the common language runtime supplies one or more JIT compilers for each computer architecture it supports, the same set of MSIL can be JIT-compiled and run on any supported architecture.

When a compiler produces MSIL, it also produces metadata. Metadata describes the types in your code, including the definition of each type, the signatures of each type's members, the members that your code references, and other data that the runtime uses at execution time. The MSIL and metadata are contained in a portable executable (PE) file that is based on and extends the published Microsoft PE and common object file format (COFF) used historically for executable content. This file format, which accommodates MSIL or native code as well as metadata, enables the operating system to recognize common language runtime images. The presence of metadata in the file along with the MSIL enables your code to describe itself, which means that there is no need for type libraries or Interface Definition Language (IDL). The runtime locates and extracts the metadata from the file as needed during execution.

Swapnil (Swaps)

http://swapsnet.spaces.live.com

.NET Framework Class Library

The .NET Framework class library is a collection of reusable types that tightly integrate with the common language runtime. The class library is object oriented, providing types from which your own managed code can derive functionality. This not only makes the .NET Framework types easy to use, but also reduces the time associated with learning new features of the .NET Framework. In addition, third-party components can integrate seamlessly with classes in the .NET Framework.

For example, the .NET Framework collection classes implement a set of interfaces that you can use to develop your own collection classes. Your collection classes will blend seamlessly with the classes in the .NET Framework.

As you would expect from an object-oriented class library, the .NET Framework types enable you to accomplish a range of common programming tasks, including tasks such as string management, data collection, database connectivity, and file access. In addition to these common tasks, the class library includes types that support a variety of specialized development scenarios. For example, you can use the .NET Framework to develop the following types of applications and services:

·                       Console applications.

·                       Windows GUI applications (Windows Forms).

·                       ASP.NET applications.

·                       XML Web services.

·                       Windows services.

For example, the Windows Forms classes are a comprehensive set of reusable types that vastly simplify Windows GUI development. If you write an ASP.NET Web Form application, you can use the Web Forms classes.

Features Of Common Language Runtime

The common language runtime manages memory, thread execution, code execution, code safety verification, compilation, and other system services. These features are intrinsic to the managed code that runs on the common language runtime.

With regards to security, managed components are awarded varying degrees of trust, depending on a number of factors that include their origin (such as the Internet, enterprise network, or local computer). This means that a managed component might or might not be able to perform file-access operations, registry-access operations, or other sensitive functions, even if it is being used in the same active application.

The runtime enforces code access security. For example, users can trust that an executable embedded in a Web page can play an animation on screen or sing a song, but cannot access their personal data, file system, or network. The security features of the runtime thus enable legitimate Internet-deployed software to be exceptionally feature rich.

The runtime also enforces code robustness by implementing a strict type-and-code-verification infrastructure called the common type system (CTS). The CTS ensures that all managed code is self-describing. The various Microsoft and third-party language compilers generate managed code that conforms to the CTS. This means that managed code can consume other managed types and instances, while strictly enforcing type fidelity and type safety.

In addition, the managed environment of the runtime eliminates many common software issues. For example, the runtime automatically handles object layout and manages references to objects, releasing them when they are no longer being used. This automatic memory management resolves the two most common application errors, memory leaks and invalid memory references.

The runtime also accelerates developer productivity. For example, programmers can write applications in their development language of choice, yet take full advantage of the runtime, the class library, and components written in other languages by other developers. Any compiler vendor who chooses to target the runtime can do so. Language compilers that target the .NET Framework make the features of the .NET Framework available to existing code written in that language, greatly easing the migration process for existing applications.

While the runtime is designed for the software of the future, it also supports software of today and yesterday. Interoperability between managed and unmanaged code enables developers to continue to use necessary COM components and DLLs.

The runtime is designed to enhance performance. Although the common language runtime provides many standard runtime services, managed code is never interpreted. A feature called just-in-time (JIT) compiling enables all managed code to run in the native machine language of the system on which it is executing. Meanwhile, the memory manager removes the possibilities of fragmented memory and increases memory locality-of-reference to further increase performance.

Finally, the runtime can be hosted by high-performance, server-side applications, such as Microsoft® SQL Server™ and Internet Information Services (IIS). This infrastructure enables you to use managed code to write your business logic, while still enjoying the superior performance of the industry's best enterprise servers that support runtime hosting.

What should I user VB.NEt or C#? Which is the best ?

 

This is the question which all of us have in our minds. I happen to read through a white paper and thought should share this information with all of u.

 

Because of the previous differences between Visual Basic and C/C++, many developers assume incorrectly about the capabilities of Visual Basic .NET. Many Visual Basic developers think that Visual C# is a more powerful language than Visual Basic. In other words, Visual Basic developers assume that you can do many things in Visual C# that you cannot do in Visual Basic .NET, just as there are many things that you can do in C/C++ but cannot do in Microsoft Visual Basic 6.0 or earlier. This assumption is incorrect.

 

Although there are differences between Visual Basic .NET and Visual C# .NET, both are first-class programming languages that are based on the Microsoft NET Framework, and they are equally powerful. Visual Basic .NET is a true object-oriented programming language that includes new and improved features such as inheritance, polymorphism, interfaces, and overloading. Both Visual Basic .NET and Visual C# .NET use the common language runtime. There are almost no performance issues between Visual Basic NET and Visual C# .NET. Visual C# .NET may have a few more "power" features such as handling unmanaged code, and Visual Basic .NET may be skewed a little toward ease of use by providing features such as late binding. However, the differences between Visual Basic .NET and Visual C# .NET are very small compared to what they were in earlier versions.

 

The "Differences Between Microsoft Visual Basic .NET and Microsoft Visual C# NET" white paper describes some of the differences between Visual Basic NET and Visual C# .NET. However, remember that the .NET Framework is intended to be language independent. When you must select between Visual Basic .NET and Visual C# .NET, decide primarily based on what you already know and what you are comfortable with. It is easier for Visual Basic 6.0 developers to use Visual Basic .NET and for C++/Java programmers to use Visual C# .NET. The existing experience of a programmer far outweighs the small differences between the two languages.

 

No matter which language you select based on your personal preference and past experience, both languages are powerful developer tools and first-class programming languages that share the common language runtime in the .NET Framework.

 

P.S. This is an extract from the "Differences Between Microsoft Visual Basic NET and Microsoft Visual C# .NET" white paper. You can download the whitepaper from the this link  http://download.microsoft.com/download/6/3/5/6354bf47-c597-4029-89e9-2495e7539ab9/vbcsharpwp.exe

.NET Framework Conceptual Overview.

 

The .NET Framework is the component which helps you in developing and executing Web Applications (ASP.NET) , Windows Application (VB.NET) and XML Web Services. .NET Framework consists of 2 main components

 

1) Common Language Runtime.

2) .NET Base Class Libraries.

 

Common Language Runtime

 

Common Language Runtime is the Execution Engine of the .Net Framework. This helps in the execution of the Applications and also provides services such as Memory Management, Thread Management, Remoting , Code Access Security and also enforces Type Safety.

 

Class Library

 

Class Library is another Base component of .NET Framework which Provides with the reusable collection of Object Oriented classes, which helps in developing applications ranging from Command Line to Robust Web Applications using ASP.NET and Windows Applications using VB.NET.

 

Various features of .NET framework are as follows

 

·          To provide consistent Object Orient Programming environment for developing Web Application (ASP.NET), Windows Application (VB.NET) and XML Web services.

 

·          To avoid versioning conflicts by providing code-execution environment like Common Language Runtime (CLR)

 

·          The .NET Framework can be hosted by unmanaged components that load the common language runtime into their processes and initiate the execution of managed code, thereby creating a software environment that can exploit both managed and unmanaged features.

 

Will talk more about CLR and Class Libraries in my Next articles

Hi All,

                      We will discuss some of the common mistakes which is made while using Data Grid.

 

 

Creating Tabular Data by Not Using the Datagrid When You Could Be

I know you're out there, the old-fashioned people in the ASP.NET world who still have code like this:

Response.Write("<table>")

While MyDataReader.Read()

Response.Write("<tr>")

Response.Write("<td>")

Response.Write(MyDataReader(0))

Response.Write("</td>")

Response.Write("</tr>")

Loop

Response.Write("</table>")

The above code could be simplified to merely:

<asp:datagrid runat="server" datasource="MyDataReader"/> along with a call to the .DataBind() method. Even if you need specialized control over the HTML output, use one of the data web controls when your user interface repeats based on a set of records.

 

Forgetting to Check for IsPostBack in the Page_Load Event

One of the most common mistakes around is forgetting to check the page's IsPostBack condition before databinding. For example, when the Datagrid is in Edit mode, omitting this check will cause the edited values to be overwritten with the original values from the data source.

The following is a typical Page_Load event which includes the IsPostBack checking. BindGrid() is a routine that populates and sets the Datagrid's data source, and calls the DataBind() method.

Sub Page_Load

  If Not IsPostBack Then

    BindGrid()

  End If

End Sub

        

 

Sticking with Auto-Generated Columns When Your Circumstances Require More Flexibility

If your Datagrid situation requires any kind of special formatting or the use of any other web controls inside your Datagrid, then you need to turn off AutoGenerateColumns. Leaving this property set to True (the default) is only useful in the simplest of Datagrid scenarios, but for nearly any real-world application, you need to set AutoGenerateColumns to False, and specify the columns explicitly in the <columns></columns> section of the Datagrid declaration. Users can use the Property Builder to create these columns graphically.

Note   If you leave AutoGenerateColumns set to true and specify the columns in your Datagrid's <columns> section, you will end up with a duplicate set of columns. The specifically declared columns will appear first, followed by all of the auto-generated columns.

 

 

Trying to Refer to a Control Inside a Datagrid Item by its ID Alone

Many people don't realize that if you have a control inside a the ItemTemplate of a TemplateColumn in your Datagrid—let's say it's a TextBox control with an ID of "MyTextBox"—that you can't refer to that control directly in your codebehind or <script> section of your ASPX page with code like this:

Dim MyValue As String = MyTextBox.Text

That code will give the dreaded "Name 'MyTextBox' is not declared." error.

Since the Datagrid is composed of multiple rows (items), there is actually a separate "MyTextBox" instance for each row in your data source. ASP.NET prefixes each control's ID with the IDs of each naming container in its hierarchy so that the TextBox will have an ID that is unique from all other controls on the page. For example, if MyTextBox is found inside DataGrid1, a generated ID would be DataGrid1:_ctl2:MyTextBox. "_ctl2" represents the current row containing MyTextBox. Other MyTextBox instances on your page might have IDs such as DataGrid1:_ctl3:MyTextBox, DataGrid1:_ctl4:MyTextBox, and so on. To retrieve the value of the "MyTextBox" that you're looking for, you need to call the FindControl method on the appropriate DataGridItem. That DataGridItem serves as the parent naming container for the TextBox.

HTML:

<asp:Datagrid runat="server" id="Datagrid1">

<Columns>

<asp:TemplateColumn>

<ItemTemplate>

<asp:TextBox runat="server" id="MyTextBox"/>

</ItemTemplate>

</asp:TemplateColumn>

</Columns>

Code:

Sub DataGrid1_UpdateCommand(sender As Object, _

    e As DataGridCommandEventArgs)

  Dim MyValue As String = _

    CType(e.Item.FindControl("MyTextBox"), TextBox).Text

  'Do something with MyValue

End Sub

Calling CType on the results of the FindControl call casts the return value from type Object to type TextBox, giving access to the .Text property.

 

 

Not Using Paging when You Could (or Should!)

Your users may not necessarily want to scroll through thousands of records on a single page. Make sure your application is appropriately designed to handle scenarios that could return a multitude of records. See the Paging in DataGrid QuickStart Tutorial for information on how to implement paging in your Datagrid. Additional information can be found in Scott Mitchell's article, Creating a Pageable, Sortable DataGrid.

 

 

Forgetting to Perform a .DataBind() Call on each Datagrid Event that Causes a Postback

A common question reads something like this: "When I click the Edit link in one of my Datagrid rows, the page posts back and now contains no data. What went wrong?" The problem is that the data is only bound to the grid the first time the page is called. In each of the Datagrid's events (Edit, Update, Cancel, Page, Sort), make sure that you set the Datagrid's Datasource property (unless it is already set declaratively in the <asp:Datagrid> declaration), and call the DataBind() method on the Datagrid.

 

 

Dynamically Creating Datagrid Controls or Columns within a Datagrid at Runtime when it isn't Necessary

There are business and technical scenarios where creating an ASP.NET control at runtime is a necessity and is completely appropriate. Perhaps the user interface is only determined at runtime, after some other page options have been selected. Or maybe you're creating a composite server control, where each of the child controls needs to be created dynamically because there is no declarative means in which to create the controls. If you do find yourself in one of these scenarios, be aware that your dynamic controls do not preserve themselves when the page is submitted. You must recreate your dynamic controls on each postback, early in the page lifecycle, such as during the Page_Init event. Motto: Create controls early, create controls often. For more on how to dynamically create controls, see the Microsoft Knowledge Base article, HOW TO: Dynamically Create Controls in ASP.NET with Visual Basic .NET.

However, if your Datagrid application doesn't fall into a scenario where dynamic creation is absolutely necessary, avoid this technique for the sake of preserving your own sanity. Dynamic Datagrids which fire events, while possible to construct, are a known source of headaches. In other words, don't create controls dynamically just to keep all of the control creation from cluttering up your ASPX file.

 

 

Enduring an Over-sized ViewState

The Datagrid control is notorious for adding to the amount of ViewState on a page, which can lead to a dramatic increase in the overall page size rendered to the user. The simplest way to eliminate this added page size is to disable ViewState, either for the entire page or for the specific controls individually. If your page never posts back, for instance, you are safe in disabling ViewState for the entire page. Otherwise, disable ViewState for individual controls where state information does not change between postbacks or for controls that do not require hidden fields to keep track of their state.

When disabling ViewState for a Datagrid control, or for a page containing a Datagrid, there are some special steps required if your Datagrid initiates postback events. First, you must rebind the Datagrid in Page_Load on every postback. This goes against conventional wisdom (and what was stated in #2 above), but this step is required when ViewState is disabled in order for the other Datagrid events to fire properly after Page_Load. You will also need to store a few Datagrid properties manually into the ViewState if you are working with any (or all) of the Datagrid events below. For instance, when editing with a ViewState-disabled Datagrid, it is sufficient to store the EditItemIndex into ViewState when the Datagrid is placed into edit mode as long as it is restored prior to the first binding of the Datagrid during Page_Load (see example code).

Listing 1. Sample code for a Datagrid with Editing, Sorting, and Paging turned on, but with ViewState disabled.

Sub Page_Load

If Not ViewState("EditItemIndex") Is Nothing Then

    Datagrid1.EditItemIndex = ViewState("EditItemIndex")

  End If

  If Not ViewState("CurrentPageIndex") Is Nothing Then

    Datagrid1.CurrentPageIndex = ViewState("CurrentPageIndex")

  End If

  BindGrid()

End Sub

 

Sub BindGrid()

  Dim DV As DataView

  DV = GetDataSource()

  DV.Sort = ViewState("SortExpression")

  Datagrid1.DataSource = DV

  Datagrid1.DataBind()

End Sub

 

Sub Datagrid1_SortCommand(s As Object, _

    e As DataGridSortCommandEventArgs)

  ViewState("SortExpression") = e.SortExpression

  BindGrid()

End Sub

 

Sub Datagrid1_EditCommand(s As Object, _

    e As DatagridCommandEventArgs)

  Datagrid1.EditItemIndex = e.Item.ItemIndex

  ViewState("EditItemIndex") = e.Item.ItemIndex

  BindGrid()

End Sub

 

Sub Datagrid1_PageIndexChanged(s as Object, _

    e As DataGridPageChangedEventArgs)

  Datagrid1.CurrentPageIndex = e.NewPageIndex

  ViewState("CurrentPageIndex") = e.NewPageIndex

  BindGrid()

End Sub

 

 

When Using the ItemDataBound or ItemCreated Events, Forgetting to Check for the Appropriate ListItemType

The Datagrid control has two events which fire for each row of data. The ItemCreated event takes place as each row is initially added to the Datagrid, and the ItemDataBound event occurs as the data is bound to each row. These events are useful for manipulating the appearance or contents of each cell as it is added to the table output of the Datagrid. One example would be to modify the background color of a cell based on a range of numeric values. The key however is to remember that these events fire for all Datagrid item types, including Header, Footer, and Pager items. If you do not expressly check the item types before referring to the item's data during the ItemDataBound event, an error will occur on the first item, which is typically the header row. That first item could instead be a pager item if paging is turned on for the Datagrid and is set to display at the top. The following example shows proper ListItemType checking before referring to item data. Don't forget about AlternatingItem!

Sub DataGrid1_ItemDataBound(source As Object, _

    e As DataGridItemEventArgs)

      If (e.Item.ItemType = ListItemType.Item Or _

    e.Item.ItemType = ListItemType.AlternatingItem) Then

        If e.Item.DataItem("ForumDate") < DateTime.Today Then

          e.Item.Cells(1).BackColor =

          System.Drawing.Color.FromName("#ffccff")

     End If

      End If

End Sub

 

Overusing the Datagrid, when You Need More Control Over the Resulting HTML, a Repeater may be a Better Choice

If the Datagrid control is a favorite of lazy programmers since so much of the work is done for you, the Repeater control must be a favorite of control freaks. If you need or want complete control over all the created HTML, the Repeater control gives you that power. The Repeater also gives a small advantage in performance, as it does not have the overhead of all of the built-in features of the Datagrid. As a compromise, also consider the DataList control, which includes editing and sorting capabilities, and has the advantage of being able to repeat records in a horizontal fashion.