Changes in Architecture

The fundamental architecture of ASP.NET has always been designed for flexibility and extensibility. ASP.NET 2.0 continues this tradition by incorporating a new provider model to support many of the new features. New utilities and API's have been added to improve site maintenance and improve configuration. All of these changes are designed to make developing ASP.NET 2.0 applications a faster and more streamlined process while still providing the flexibility and extensibility that developers were used to with ASP.NET 1.x.

The Provider Model

Many of the new features in ASP.NET 2.0 depend on communication between the Web application and a data store. In order to provide this access in a consistent fashion, ASP.NET 2.0 uses the provider factory model. A provider is both a pattern and a point where developers can extend the ASP.NET 2.0 framework to meet specific data store needs. For example, a developer can create a new provider to support the user identification system, or to store personalization data in an alternate data store.

Most custom providers will interact with database backend systems. However, the programmer is free to implement the required provider methods and classes using any medium or algorithm so long as it meets the models required interface specification.

ASP.NET 2.0 Providers

The provider model defines a set of interfaces and hooks into the data persistence layer that provides storage and retrieval for specified requests. In this way the provider model acts as a programming specification that allows ASP.NET 2.0 to service unique client concerns.

ASP.NET 2.0 uses a wide variety of providers, including:

·                       Membership—The membership provider manages supports user authentication and user management.

·                       Profile—The profile provider supports storage and retrieval of user specific data linked to a profile.

·                       Personalization—The personalization provider supports persistence of Web Part configurations and layouts for each user.

·                       Site Navigation—The site navigation provider maps the physical storage locations of ASP.NET pages with a logical model that can be used for in-site navigation and linked to the various new navigation controls

·                       Data providers—ADO.NET has always used a provider model to facilitate the connection between a database and the ADO.NET API. ASP.NET 2.0 builds upon the data provider by encapsulating many of the ADO.NET data calls in a new object called a data source.

Each type of provider acts independently of the other providers. You can therefore replace the profile provider without causing problems with the membership provider.

In my next articles, you will find specific examples of how providers are used with several of the new ASP.NET 2.0 features.

Swapnil (Swaps)

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

 

Folks,

              Since no we are talking about ASP.NET 2.0 the First step is to Convert the existing Projects developed in 2002 / 2003 to upgraded version 2005. This article will help you out in Step by Step converstion from 2002 / 03 to Visual Studio 2005 Projects. Please check the following link.

 

 

Swapnil (Swaps)

 

ASP.NET 2.0

Computer languages and frameworks evolve as the needs of the development community evolve. ASP.NET is certainly no exception. ASP.NET 2.0 is the first major update to the ASP.NET framework and includes solutions to common problems encountered with ASP.NET 1.x as well as new features that greatly increase the flexibility and functionality of Web development on the .NET platform. If you are still working with ASP or ASP.NET applications, then ASP.NET 2.0 offers even more incentive to upgrade, we will discuss these features in my upcoming articles on ASP.NET 2.0

ASP.NET is a programming framework built on the common language runtime that can be used on a server to build powerful Web applications. The first version of ASP.NET offered several important advantages over previous Web development models. ASP.NET 2.0 improves upon that foundation by adding support for several new and exciting features in the areas of developer productivity, administration and management, extensibility, and performance.

1.           Improve the reliability and usability of Web applications

Currently, many ASP.NET 1.x applications run on Microsoft IIS 5.0. ASP.NET 2.0 leverages new IIS 6.0 features for improved performance and scalability. Specifically, IIS 6.0 provides a new process model which greatly enhances the ability of a server to host multiple applications in a truly independent fashion. Each application runs completely separated from every other application. If one application crashes, it doesn't affect other applications.

In terms of usability, new features such as master pages and themes allow you to develop large Web applications using a consistent structure that is manageable and configurable.

2.           Reduce the number of lines of code you have to write in common scenarios

ASP.NET 2.0 includes wizards and controls that allow you to perform frequent tasks (e.g. data access) without having to write a single line of code.

ASP.NET 2.0 also leverages changes in the .NET Framework. In particular, the partial class concept is particularly useful for ASP.NET developers. A partial class lets you write part of the code and lets the ASP.NET compiler write the rest when necessary.

3.           Offer user features to personalize Web applications

ASP.NET 2.0 includes built-in controls to help you manage user accounts and personalize the content and layout of pages in your application. First, the membership service lets you track users. The new login controls integrate with the membership service to allow you to automate account creation and user login without writing any code. The new Web Parts feature allows you to create Web applications that contain controls that can be edited and personalized by users. Finally, the Profile service provides long-term persistence of user preferences and data through declarative XML configuration.

4.           Provide enhanced design features to generate consistent layouts and design

ASP.NET 2.0 supports master pages, themes and skins to build applications with a consistent page layout and design. These new features are easy to implement and modify, and greatly enhance the manageability and maintainability of large applications.

 

Swapnil (Swaps)

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

 

To overcome this, can use Multi Select Dropdown list box control. It is a user control and can be used directly on pages very easily. It allows the user to select multiple items from the list and the selected items will be displayed in comma separated format in the text area, and it can also persist the selected items.

 

 

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/

Folks,

 

Folks,

              Here are listed some of the existing companion tools for .NET development, access the following site to view more details and download the components http://sharptoolbox.com/categories/asp-net

 

Swapnil (Swaps)

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/

Greetings Folks,

Every one of us have accounts in different web sites: Email, Banks, Forums, etc…

The most annoying part is the need to remember all the user names and passwords.

There are some commercial products that provide a way to save this login information and automatically fill the forms whenever a web site is navigated.

In this article it has been demonstrated how it is possible to create your own application that will do exactly this: Remember all the usernames and passwords for you and do a single sign on .

Base on what is show here, everyone with some .NET knowledge can build a simple WebBrowser dedicated to such sites.

For detailed explanation, Check the link http://www.codeproject.com/useritems/Automatic_Login.asp

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