The ASP.NET Page Life Cycle

When a page request is sent to the Web server, whether through a submission or location change, the page is run through a series of events during its creation and disposal. So let's examine in detail the eight events of an ASP.NET page, from creation to disposal. So these are the eight events that will be executed sequentially.

page_init
Loadviewstate
page_load
LoadPostData
RaisePostBackEvent
prerender
saveviewstate
Unload/Dispose


PAGE_INIT

The Page_Init event is the first to occur when an ASP.NET page is executed. This is where you should perform any initialization steps that you need to set up or create instances of server controls. You don't want to try to access controls in this event because there is no guarantee that they have been created yet. It is during this event that they are created, and you can control whether your attempt to use these objects will be thwarted by the server processing your request before the object has been created.Note that the Page_Init event fires only the first time the page is loaded. When you use a web form and post back to this page again, the Page_Init event doesn't fire. But the Page_Load event fires each time the page loads.

Load View state

After the Init event, controls can be referenced using their IDs only (no DOM is established yet for relative references). At LoadViewState event, the initialized controls receive their first properties: view state information that was persisted back to the server on the last submission. The page view state is managed by ASP.NET and is used to persist information over a page roundtrip to the server. View state information is saved as a string of name/value pairs and contains information such as control text or value. The view state is held in the value property of a hidden control that is passed from page request to page request. This event can be overridden using the LoadViewState method and is commonly used to customize the data received by the control at the time it is populated

PAGE_LOAD

This is the page event where you will be doing most of your work. This event occurs only when all the objects on the page have been created and are available for use.

Load Postback data

During this phase of the page creation, form data that was posted to the server (termed postback data in ASP.NET) is processed against each control that requires it. When a page submits a form, the framework will implement the IPostBackDataHandler interface on each control that submitted data. The page then fires the LoadPostData event and parses through the page to find each control that implements this interface and updates the control state with the correct postback data. ASP.NET updates the correct control by matching the control's unique ID with the name/value pair in the NameValueCollection. This is one reason that ASP.NET requires unique IDs for each control on any given page. Extra steps are taken by the framework to ensure each ID is unique in situations, such as several custom user controls existing on a single page. After the LoadPostData event triggers, the RaisePostDataChanged event is free to execute (see below).

Raise PostBack Change Events

As stated earlier, this occurs after all controls that implement the IPostBackDataHandler interface have been updated with the correct postback data. During this operation, each control is flagged with a Boolean on whether its data was actually changed or remains the same since the previous submit. ASP.NET then sweeps through the page looking for flags indicating that any object's data has been updated and fires RaisePostDataChanged. The RaisePostDataChanged event does not fire until all controls are updated and after the Load event has occurred. This ensures data in another control is not manually altered during the RaisePostDataChanged event before it is updated with postback data.

Prerender

The point at which the objects are prerendered is the last time changes to the objects can be saved or persisted to view state. This makes the PreRender step a good place to make final modifications, such as changing properties of controls or changing Control Tree structure, without having to worry about ASP.NET making changes to objects based off of database calls or view state updates. After the PreRender phase those changes to objects are locked in and can no longer be saved to the page view state. The PreRender step can be overridden using OnPreRender

ViewState Saved

The Viewstate is saved after all changes to the page objects have occurred. Object state data is persisted in the hidden object and this is also where object state data is prepared to be rendered to HTML. At the SaveViewState event, values can be saved to the ViewState object, but changes to page controls are not. You can override this step by using SaveViewState.

Page_Unload

Page_Unload is the counterpart to Page_Init. Just as Page_Init is an event that happens before anything else happens, Page_Unload happens after everything else happens. It is available for you to perform any operation you need to after you are completely finished with the page. For instance, imagine that you temporarily needed to create a file on the server during the page's processing. You wouldn't want to leave it there for eternity, especially if the file was unique to each visitor of the web site. You could have loads and loads of files building on your server without any way to get rid of them. But if you were a good boy or girl, you could destroy the file during the page's Page_Unload event and make the server administrator a happy camper.

How to improve garbage collection performance

DotNet developers can free themselves from tedious memory management for their application as Microsoft Framework and CLR do it automatically.CLR provides a mechanism called as Garbage Collection which manages your applications memory. In this session we will discuss how garbage collector works and how it affects the performance of your Applications.

When you create an object using new () operator, the object’s memory is obtained from the managed heap. When the garbage collector decides that sufficient garbage has accumulated, it performs a collection to free some memory. This process is fully automatic, but there are a number of factors that you need to be aware of that can make the process more or less efficient.
Garbage Collection Algorithm
Each application has a set of roots. Roots identify storage location which refers to object on the managed heap or the objects that are set to be null. For example all the global and static object pointers are considered as application roots. In addition any local variable/parameter object pointers on a thread stack are considered as a part of application roots. The list of application roots are maintained by JIT and CLR, and are made available at the time of garbage collection. When Garbage collector starts running it assumes all the objects in the heap as garbage. Now the garbage collector 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 some how reachable form application root. Any objects that are not in the graph are not accessible by the application and considered as garbage. 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.
Generations
One feature of the garbage collector that exists purely to improve performance is called generations. A generational garbage collector takes into account two facts that have been empirically observed in most programs in a variety of languages. One newly created objects tend to have short lives and second one the older an object is, the longer it will survive.
Generational collectors group objects by age and collect younger objects more often than older objects. When initialized, the managed heap contains no objects. All new objects added to the heap can be said to be in generation 0, until the heap gets filled up which invokes garbage collection. As most objects are short-lived, only a small percentage of young objects are likely to survive their first collection. Once an object survives the first garbage collection, it gets promoted to generation 1.Newer objects after GC can then be said to be in generation 0.The garbage collector gets invoked next only when the sub-heap of generation 0 gets filled up. All objects in generation 1 that survive get compacted and promoted to generation 2. All survivors in generation 0 also get compacted and promoted to generation 1. Generation 0 then contains no objects, but all newer objects after GC go into generation 0.Thus, dividing the heap into generations of objects and collecting and compacting younger generation objects improves the efficiency of the basic underlying garbage collection algorithm by reclaiming a significant amount of space from the heap and also being faster than if the collector had examined the objects in all generations.
Garbage Collection Class (System.GC)
As the garbage collection by the CLR is Nondeterministic and developer has no control on it Microsoft provided System.GC object class using which you can force a garbage collection in your application. Different methods of System.GC class are as follows.
System.GC.Collect: This method forces a garbage collection. You should generally avoid this and let the runtime determine the appropriate time to perform a collection. The main reason that you might be tempted to call this method is that you cannot see memory being freed that you expect to see freed. However, the main reason that this occurs is because you are inadvertently holding on to one or more objects that are no longer needed. In this case, forcing a collection does not help.
System.GC.WaitForPendingFinalizers: This suspends the current thread until the finalization thread has emptied the finalization queue. Generally, this method is called immediately after System.GC.Collect to ensure that the current thread waits until finalizers for all objects are called. However, because you should not call GC.Collect, you should not need to call GC.WaitForPendingFinalizers.
System.GC.KeepAlive: This is used to prevent an object from being prematurely collected by holding a reference to the object. A common scenario is when there are no references to an object in managed code but the object is still in use in unmanaged code.
System.GC.SuppressFinalize This prevents the finalizer being called for a specified
object. Use this method when you implement the dispose pattern. If you have explicitly released resources because the client has called your objects Dispose method.Dispose should call SuppressFinalize because finalization is no longer required.
Finalization
The garbage collector offers an additional, optional service called finalization. Use
Finalization for objects that need to perform cleanup processing during the collection
Process and just before the object’s memory is reclaimed. Finalization is most often
Used to release unmanaged resources maintained by an object; any other use should
Be closely examined. Examples of unmanaged resources include file handles, Database connections and COM object references an object’s Finalize method is called before the objects managed memory is reclaimed. This allows you to release any unmanaged resources that are maintained by the object. If you implement Finalize, you cannot control when this method should be called because this is left to the garbage collector. The finalization process requires a minimum of two collection cycles to fully release the object’s memory. 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. 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.
Dispose
CLR provided a method named Dispose for types that contain references to external resources that need to be explicitly freed by the calling code. You can avoid finalization by implementing the IDisposable interface and by allowing your class’s consumers to call Dispose. The reason you want to avoid finalization is because it is performed asynchronously and unmanaged resources might not be freed in a timely fashion. This is especially important for large and expensive unmanaged resources such as bitmaps or database connections. In these cases, the classic style of explicitly releasing your resources is preferred (using the IDisposable interface and providing a Dispose method). With this approach, resources are reclaimed as soon as the consumer calls dispose and the object need not be queued for finalization. Statistically, what you want to see is that
almost all of your finalizable objects are being disposed and not finalized. The finalizer should only be your backup. With this approach, you release unmanaged resources in the IDisposable.Dispose method. This method can be called explicitly by your class’s consumers or implicitly by using the C# using statement. To prevent the garbage collector from requesting finalization, your Dispose implementation should call GC.SuppressFinalization. Common disposable resources include the following:
Database-related classes: SqlConnection, SqlDataReader, and SqlTransaction.
File-based classes: FileStream and BinaryWriter.
Stream-based classes: StreamReader, TextReader, TextWriter, BinaryReader and TextWriter.
Network-based classes: Socket, UdpClient, and TcpClient

How to Implement Dispose method for a class

● Create a class that derives from IDisposable.
● Add a private member variable to track whether IDisposable.Dispose has already
been called. Clients should be allowed to call the method multiple times without generating an exception. If another method on the class is called after a call to Dispose, you should throw an ObjectDisposedException.
● Implement a protected virtual void override of the Dispose method that accepts a single bool parameter. This method contains common cleanup code that is called either when the client explicitly calls IDisposable.Dispose or when the finalizer runs. The bool parameter is used to indicate whether the cleanup is being performed as a result of a client call to IDisposable.Dispose or as a result of finalization.
● Implement the IDisposable.Dispose method that accepts no parameters. This method is called by clients to explicitly force the release of resources. Check whether Dispose has been called before; if it has not been called, call Dispose (true) and then prevent finalization by calling GC.SuppressFinalize (this).Finalization is no longer needed because the client has explicitly forced a release of resources.
● Create a finalizer, by using destructor syntax. In the finalizer, call Dispose (false).
Example (In VB.NET)
Public Class My Dispose Implements IDisposable

Public Overloads Sub Dispose () Implements IDisposable.Dispose
Dispose(True)
GC.SuppressFinalize (Me) ' No need call finalizer
End Sub

Protected Overridable Overloads Sub Dispose (ByVal disposing As Boolean)

If disposing then
‘Free managed resources
End If
‘Free unmanaged resources

End Sub

Protected Overrides Sub Finalize ()
Dispose (False)
End Sub

End Class
Garbage Collection Guidelines:
1. Avoid Calling GC.Collect: The default GC.Collect method causes a full collection of all generations. Full collections are expensive because literally every live object in the system must be visited to ensure complete collection. Needless to say, exhaustively visiting all live objects could, and usually does, take a significant amount of time. The garbage collector’s algorithm is tuned so that it does full collections only when it is likely to be worth the expense of doing so. As a result, do not call GC.Collect directly — let
the garbage collector determine when it needs to run. The garbage collector is designed to be self-tuning and it adjusts its operation to meet the needs of your application based on memory pressure. Programmatically forcing collection can hinder tuning and operation of the garbage collector. If you have a particular niche scenario where you have to call GC.Collect, consider the following:
● Call GC.WaitForPendingFinalizers after you call GC.Collect. This ensures that
the current thread waits until finalizers for all objects are called.
● After the finalizers run, there are more dead objects (those that were just finalized)
that needs to be collected. One more call to GC.Collect collects the remaining dead
2. Call Close or Dispose on Classes that Support It: If the managed class you use implements Close or Dispose, call one of these methods as soon as you are finished with the object. Do not simply let the resource fall out of scope. If an object implements Close or Dispose, it does so because it holds an expensive, shared, native resource that should be released as soon as possible.
3. Call System.Runtime.InteropServices.Marshal.ReleaseComObject if you are using COM components: In server scenarios where you create and destroy COM objects on a per-request basis, you may need to call system.interopServices. Marshal. Release ComObject.The Runtime Callable Wrapper (RCW) has a reference count that is incremented every time a COM interface pointer is mapped to it. The ReleaseComObject method decrements the reference counts of the RCW. When the reference count reaches zero, the runtime releases all its references on the unmanaged COM object.
4. Set Unneeded Member Variables to Null before Making Long-Running Calls: Before you block on a long-running call, you should explicitly set any unneeded member variables to null before making the call so they can be collected. This advice applies to any objects which are still statically or lexically reachable but are actually not needed Do not set local variables to null (C#) or Nothing (Visual Basic .NET) because the JIT compiler can statically determine that the variable is no longer referenced and there is no need to explicitly set it to null.
5. Prevent the Promotion of Short-Lived Objects: Objects that are allocated and collected before leaving Gen 0 are referred as short-lived objects. The following principles help ensure that your short-lived objects are not promoted:
● Do not reference short-lived objects from long-lived objects. A common example where this occurs is when you assign a local object to a class level object reference.
● Avoid implementing a Finalize method. The garbage collector must promote finalizable objects to older generations to facilitate finalization, which makes them long-lived objects.
● Avoid having finalizable objects refer to anything. This can cause the referenced object(s) to become long-lived.
6. Minimize Hidden Allocations: Memory allocation is extremely quick because it involves only a pointer relocation to create space for the new object. However, the memory has to be garbage collected at some point and that can hurt performance, so be aware of apparently simple lines of code that actually result in many allocations. For example, String.Split uses a delimiter to create an array of strings from a source string. In doing so, String.Split allocates a new string object for each string that it has split out, plus one object for the array. As a result, using String.Split in a heavy duty context (such as a sorting routine) can be expensive.Use stringbuilder class in place of string class
7. Use the using Statement in C# and Try/Finally Blocks in Visual Basic .NET to Ensure Dispose Is Called: If you r using C# use using statement as it will automatically generates a try and finally block at compile time that calls Dispose on the object allocated inside the using block.
8. Do Not Implement Finalize Unless Required: Implementing a finalizer on classes that do not require it adds load to the finalizer thread and the garbage collector. Avoid implementing a finalizer or destructor unless finalization is required. Classes with finalizers require a minimum of two garbage collection cycles to be reclaimed. This prolongs the use of memory and can contribute to memory pressure. When the garbage collector encounters an unused object that requires finalization, it moves it to the “ready-to-be-finalized” list. Cleanup of the object’s memory is deferred until after the single specialized finalizer thread can execute the registered finalizer method on the object. After the finalizer runs, the object is removed from the queue and literally dies a second death. At that point, it is collected along with any other objects. If your class does not require finalization, do not implement a Finalize method. Use a finalizer only on objects that hold unmanaged resources across client calls. You should implement IDisposable if you implement a finalizer. In this way, the calling code has an explicit way to free resources by calling the Dispose method.
9. Call Dispose On Base Classes and On IDisposable Members: If your class inherits from a disposable class, then make sure that it calls the base class’s Dispose. Also, if you have any member variables that implement IDisposable, call Dispose on them, too.

Native Image Generator (Ngen.exe)

Using the Native Image Generator (Ngen.exe) tool, an assembly can be converted into its Native Code or image. This means that calls to the Native Image will load faster since the nend for JIT compilation has been eliminated.When you run the NGen .NET Framework command line utility on an assembly, the Native Image will be generated and installed in the Native Image Cache and subsequent calls to methods of that assembly will be handled by the Native Image of the assembly. E.g. entering Ngen C:/post.dll at the command prompt where post.dll represents a managed assembly will create the Native Image of the assembly.A native image is a file containing compiled processor-specific machine code. Note that the native image that Ngen.exe generates cannot be shared across Application Domains. Therefore, you cannot use Ngen.exe in application scenarios, such as ASP.NET, that require assemblies to be shared across application domains.If Ngen.exe encounters any methods in an assembly that it cannot generate, it excludes them from the native image. When the runtime executes this assembly, it will revert to JIT compilation for the methods that were not included in the native image.

Examples:

The following command generates a native image for drnotes.exe, located in the current directory. If a configuration file exists for the application, Ngen.exe will use it. The tool will not generate native images for any DLLs that drnotes.exe references.

ngen drnotes.exe

If drnotes.exe directly references two DLLs, drnotes1.dll and drnotes2.dll, you must supply Ngen.exe with the fully specified assembly names for these DLLs to generate native images for them. Run Ildasm.exe over drnotes.exe to determine the fully specified assembly names of the referenced DLLs. For the purpose of this example, the fully specified assembly names of drnotes1.dll and drnotes2.dll are "drnotes1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0038abc9deabfle5" and "drnotes2, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0038abc9deabfle5". Using this information, the following command generates native images for drnotes.exe, drnotes1.dll, and drnotes2.dll.

ngen drnotes.exe "drnotes1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0038abc9deabfle5", "drnotes2, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0039def8abcbste7", "drnotes3, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0038abc9deabfle5"

The following command generates a native image for drnotes.exe with the specified path.

ngen c:\myfiles\myAssembly.exe

The following command generates a native image for myLibrary.dll, with the specified path.

ngen c:\myfiles\myLibrary.dll

Ngen.exe looks in the native image cache to delete an assembly specified with a partial assembly name. The following command deletes all native images with the name myAssembly.

ngen /delete myAssembly

The following command deletes the native image myAssembly with the fully specified assembly name.

ngen /delete "myAssembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=0038abc9deabfle5"

The following command displays all native images in the native image cache.

ngen /show

The following command displays all native images in the native image cache with the name myAssembly.

ngen /show myAssembly

The following command displays all native images in the native image cache with the name myAssembly and the version 1.0.

ngen /show "myAssembly, version=1.0.0.0"

A Tool to Convert VS.NET 2003 Project Files

A Tool to convert vs.net 2003 projects to vs.net 2002 and vice versa is available in the following path

http://www.codeproject.com/macro/vsconvert.asp

New Features in Visual Studio 2003

Microsoft Visual Studio .NET 2003 (VS 2003, doesn't introduce as much new functionality as the original Visual Studio .NET, also known as VS 2002. Microsoft's latest integrated development environment (IDE) brings lots of cool new features to the developer's table

VS 2003 includes plenty of new features. The following sections describe what I think are the best ones.

Better Database Support
The .NET Framework Data Provider for ODBC is now available with the .NET Framework under the namespace System.Data.Odbc.The .NET Framework Data Provider for Oracle now ships with the .NET Framework under the namespace System.Data.OracleClient. Developers using the .NET Framework version 1.0 can download the .NET Framework Data Provider for Oracle from http://msdn.microsoft.com/downloads.
In addition, ADO.NET now includes the following features:
• The DataReader object now exposes a HasRows property to determine if rows were returned without having to call Read.
• The Connection object now has an EnlistDistributedTransaction method to enable manual enlistment in distributed transactions.

Side-by-Side Execution:
The .NET Framework version 1.1 supports side-by-side execution. Side-by-side execution is the ability to store and execute multiple versions of an application or component on the same computer. This means that you can have multiple versions of the runtime, and multiple versions of applications and components that use a version of the runtime, on the same computer at the same time. In addition, subsequent installations of other versions of the .NET Framework or of a component will not affect the applications already installed. Side-by-side execution does not imply that a managed application is compatible with other versions of the runtime or of a component. Rather, it means that a managed application can choose the runtime and the components it executes with, and that multiple versions of the runtime, applications, and components can coexist on the same computer. It is up to you to decide which versions of the runtime and which components a particular application will use.

Java Support
VS 2003 brings first-time integration with Visual J#, a tool for Java developers who want to use Microsoft's .NET framework to build applications and XML Web services. Outside of Visual J#, VS 2003 also supports Visual Basic (VB), Visual C++, and Visual C# developers. The new IDE is available in Standard, Professional, Enterprise Developer, and Enterprise Architect editions.

Code Obfuscation
Also new in VS 2003 is a built-in utility for source code obfuscation. In addition, VS developers can now download Microsoft's Enterprise Implementation Framework (EIF), a tool that the company promises lets you quickly add runtime monitoring to your applications. The source code obfuscation tool, Preemptive Dotfuscator Community Edition, is the "little" version of a product from Preemptive Solutions, a Microsoft ISV partner based in Cleveland. Microsoft says it included the tool to protect the intellectual property of programmers who distribute VS 2003 code, as well as to help developers reduce the size and improve the performance of mobile and other .NET applications. The tool is designed to render Microsoft Intermediate Language (MSIL), which is said to be very difficult, if not impossible, to reverse-engineer into comprehensible source code.

ASP.NET Mobile Controls - (formerly the Microsoft Mobile Internet Toolkit)
ASP.NET Mobile Controls (formerly the Microsoft Mobile Internet Toolkit) extends the .NET Framework and Visual Studio .NET by providing support for mobile (wireless) devices such as cell phones and personal data assistants (PDAs). The .NET Framework version 1.1 release incorporates the mobile controls into the .NET Framework and Visual Studio .NET distributions. Because mobile controls are now a part of the .NET Framework, the terminology has changed to match the conventions used in .NET documentation, and the mobile controls documentation has merged into the larger .NET Framework documentation set. The name Mobile Internet Toolkit is replaced by ASP.NET Mobile Controls.ASP.NET Mobile Controls extend ASP.NET server controls such that they adapt to the mobile device on which the Web application is rendering. Through browser detection, the mobile controls conform to the capabilities of individual devices ranging from full-featured PDA browsers to small, 5-line × 20-character cell phone displays. This adaptive rendering feature handles many of the tedious device-specific rendering decisions and frees you to focus on your Web application logic.

Changes in .NET Framework Security:
In version 1.0 and 1.1, applications that receive less than full trust from the runtime code access security system cannot call shared managed libraries unless the library writer specifically allows them to through the use of the AllowPartiallyTrustedCallersAttribute attribute. If you plan on using libraries from partially trusted code, you need to be aware that some libraries will not be available to your code. In version 1.1, System.Web.dll, System.Web.Mobile.dll, and System.Web.RegularExpressions.dll are included in the list of assemblies that have the AllowPartiallyTrustedCallersAttribute and can be called from partially trusted code. Default security policy has been changed so that applications executing from the Internet zone and assigned to the Internet Zone code group now receive permissions associated with the Internet permission set. As a result, applications from the Internet now receive sufficient permission to execute. In the .NET Framework 1.0 Service Pack 1 and Service Pack 2, such applications received the permissions associated with the Nothing permission set and could not execute.


ASP.NET Security:
ASP.NET now supports partial trust in Web-based applications, offering greater security for multiple applications that are hosted on a single Web server. Although the operating system account under which an application runs imposes security restrictions on the application, the code access security system of the common language runtime can enforce additional restrictions on selected application resources based on policy that you specify. You can use this feature in a shared server environment to isolate separate applications and with standalone servers where you want applications to run with the minimum necessary privileges.ASP.NET provides a configuration directive that enables you to configure code access security levels for your applications. If your partially trusted ASP.NET applications call shared managed libraries, those libraries must contain an AllowPartiallyTrustedCallersAttribute attribute that allows calls from partially trusted code. For more information, see Using Libraries from Partially Trusted Code.

IPv6 Support in the .NET Framework:
The .NET Framework version 1.1 supports the emerging update to the Internet Protocol, commonly referred to as IP version 6, or simply IPv6. This protocol is designed to significantly increase the address space used to identify communication endpoints in the Internet to accommodate its ongoing growth. IPv6 is supported in the System.Net namespace, ASP.NET, and XML Web services.

Solutions Explorer - Track Active Item:
A new option in visual studio 2003, Track Active Item in Solution Explorer, has been added to the Projects and Solutions, Environment, Options Dialog Box. When this option is selected, Solution Explorer automatically opens the folder for the active item, scrolls to its node, and selects its name. The selected item changes as you work with different files within a project or solution, or different components within an Integrated Development Environment (IDE) designer. When this option is cleared, the selection in Solution Explorer does not change automatically. This option is enabled by default, but it is cleared when you choose the "Visual C++ Developer" or "Visual C# Developer" profile on the My Profile tab of the Visual Studio Start Page.

New icons:
• checked out Exclusive - Item is checked out from a source control database to one developer only. Other developers cannot access this file.
• checked out Shared - Item is checked out from a source control database for shared use by a development team. Different versions of the item will be merged upon checkin.

Options and Settings: (Copy Options and Settings from Previous version)
You can copy certain Options dialog box settings from a previous version of Visual Studio .NET to a more recent version visual studio 2003. If you have two different versions of the program installed on the same machine, the first time you launch the newer version of the Visual Studio .NET, a dialog box appears giving you the choice to migrate your existing setting. If you dismiss this dialog, you can display it later by executing the following command from the Windows command line: devenv /migrate settings .After you migrate your previous Options settings into the new version of Visual Studio .NET, select Options from the Tools menu to display the Options dialog box and review your settings. Most option settings should appear as you last set them.

Build: (Only build startup projects and dependencies on Run)
A new option in visual studio 2003, Only build startup projects and dependencies on Run, has been added to the Projects and Solutions, Environment, Options Dialog Box, under Build and Run Options. When this option is selected, pressing F5 or choosing the Start or Build command from the Debug or Run menu only builds the startup project and its dependencies. When this option is cleared, pressing F5 builds all projects, dependencies, and solution files. This option is cleared by default, but it is enabled when you choose the "Visual C++ Developer" and the “Visual C# Developer" profile on the My Profile tab of the Visual Studio Start Page.For Visual C++ projects only, three new commands have been placed on a new Project Only submenu of the Build menu:
• Build Only
• Rebuild Only
• Clean Only
These commands build, rebuild, or clean only the C++ project currently selected in Solution Explorer, without building or cleaning any project dependencies or solution files.
Debug: (Debugger Enhancements)
The Visual Studio .NET 2003 debugger has been enhanced by the addition of several new features:
• Security enhancements, including a new restriction that limits Just-In-Time Debugging to the local machine.
• Remote debugging using pipes, a new, more secure alternative to TCP/IP debugging.
• SOS, a powerful tool for debugging from the Command window.• Support for automatically downloading of debug symbols from a symbol server.• Improved error messages, especially for errors that occur while debugging web applications.

Installation: Side-by-Side Installations of Visual Studio .NET
Visual Studio supports installation of versions 2002 and 2003 on the same machine; however you should be aware of certain issues.• Visual Studio .NET 2002 shipped with the Microsoft .NET Framework SDK version 1.0. Visual Studio .NET 2003 ships with .NET Framework SDK version 1.1. If you developed applications that reference .NET Framework version 1.0 and attempt to open the solution in Visual Studio .NET 2003, the references to .NET Framework are changed to reference .NET Framework 1.1. You should review the latest .NET Framework documentation for information on changes that might affect your application
• If you open and then save solutions created in Visual Studio .NET 2002 in Visual Studio .NET 2003, you can no longer open the solution created in version 2002 in Visual Studio .NET 2002.

How to get Connection String

During Programming With ADO.NET we use to forget the connection string.
we can use following web site to find connection string for all types of datasource .

http://www.connectionstrings.com/

Things vb.net can do that C# can't

Because of the past differences between Microsoft® Visual Basic, Microsoft Visual C, and Microsoft® Visual C++, many developers have the impression that Microsoft Visual C# .NET is a more powerful language than Microsoft Visual Basic .NET. Some developers assume that many things that are possible in Visual C# .NET are impossible in Visual Basic .NET. Visual Basic.NET can do some thing more that C# can do.
1. One key VB.NET feature is that it eliminates an entire class of runtime error you get in case sensitive languages - where a method parameter and property in the same class have the same name but for case. These problems can only be found through runtime testing, not by the compiler. This is a stupid thing that is solved in VB.NET by avoiding the archaic concept of case sensitivity.

2. Vb.NET supports some operators like \ (Integer Division) and ^ (Exponentiation)
Which C# doesn’t supports?

3. Handle multiple events in single method (superior separation of interface and implementation).

4. With Events is a huge difference in general, since it dramatically simplifies (or even enables) several code generation scenarios.

5. In VB you can actually tell the difference between inheriting from a base class and implementing an interface. In C# the syntax for both is identical, even though the semantic meaning is very different.

6. Implement multiple interface items in a single method (superior separation of interface and implementation).

7. Also, independent naming/scoping of methods that implement an interface method - C# interface implementation is comparable to the sucky way VB6 did it... (superior separation of interface and implementation).

8. Multiple indexed properties (C# only allows a single indexed property).

9. Optional parameters (important for Office integration, and general code cleanliness).

10. Late binding (C# requires manual use of reflection).

11. There are several COM interop features in VB that require much more work in C#. VB has the ComClass attribute and the CreateObject method for instance.

12. The Cxxx () methods (such as CDate, CInt, CStr, etc) offer some serious benefits over Convert.xxx. Sometimes performance, but more often increased functionality that takes several lines of C# to achieve.

13. The VB RTL also includes a bunch of complex financial functions for dealing with interest, etc. In C# you either write them by hand or buy a third-party library (because self-respecting C# devs won't use the VB RTL even if they have to pay for an alternative).

14. The InputBox method is a simple way to get a string from the user without having to build a custom form.

RSS : An Excellent Way to syndicate information

RSS (Really Simple Syndication) provides a convienent way to syndicate information from a variety of sources, including news stories, updates to a web site or even source code check-ins for a development project. Regardless of the purpose for which the RSS file is being used, by watching this XML file, you can quickly and easily see whenever an update has occurred. Of course, viewing the RSS feed in Internet Explorer and hitting F5 every few minutes is not the most efficient use of your time, so most people take advantage of some form of client software to read and monitor RSS feeds.

There are many different RSS clients available, but here are a selected few that we tested our feeds with and that you may find useful:

Sharpreader
http://www.sharpreader.net/
FeedReader
http://feedreader.com/
RssBendit
http://www.rssbandit.org/

To know more about RSS visit

http://www.dotnetforce.com/(jwxkc0vcsowlfzri2kgn0i3w)/PrintPreview.aspx?n=204