Side-by-Side Execution of .NET Framework 1.0 and 1.1

Side-by-side execution is the ability to install multiple versions of code so that an application can choose which version of the common language runtime or of a component it uses. Subsequent installations of other versions of the runtime, an application, or a component will not affect applications already installed.

In ASP.NET, applications are said to be running side by side when they are installed on the same computer, but use different versions of the .NET Framework. The following topic describes how to configure ASP.NET applications for side-by-side execution and provides detailed steps to:

• Maintain your Web application�s mapping to .NET Framework version 1.0 during installation
• Map a Web application to a specific version of the .NET Framework
• Find the version of the .NET Framework that a Web site is using

Traditionally, when a component or application is updated on a computer, the older version is removed and replaced with the newer version. If the new version is not compatible with the previous version, this usually breaks other applications that use the component or application. The .NET Framework provides support for side-by-side execution, which allows multiple versions of an assembly or application to be installed on the same computer at the same time. Because multiple versions can be installed simultaneously, managed applications can select which version to use without affecting applications that use a different version.

Reference: http://www.asp.net/learn/whitepapers/side-by-side-with-1.0/

CLR

The .NET Framework provides a runtime environment called the Common Language Runtime or CLR (similar to the Java Virtual Machine or JVM in Java), which handles the execution of code and provides useful services for the implementation of the program.

The Common Language Runtime is the underpinning of the .NET Framework. CLR takes care of code management at program execution and provides various beneficial services such as memory management, thread management, security management, code verification, compilation, and other system services. The managed code that targets CLR benefits from useful features such as cross-language integration, cross-language exception handling, versioning, enhanced security, deployment support, and debugging.

Common Type System (CTS) describes how types are declared, used and managed in the runtime and facilitates cross-language integration, type safety, and high performance code execution.

The Common Language Specification (CLS) is an agreement among language designers and class library designers to use a common subset of basic language features that all languages have to follow.

Reference: http://www.arunmicrosystems.netfirms.com/clr.html

Profile VS. Session

I would like to point out some of the similarities/differences bewteen both Session and Profile objects:

Profile:

1- Profile object is scoped to a particular user:
Each user of a web application automatically has his own profile.

2- Profile object is persistant:
When you modify the stat os the profile object, the modifications are saved between visits to the website

3- Profile object uses the provider model to store information:
By default, the contents of a user profile are automatically saved to a Microsoft SQL Server Express database
located in App_Data of your web application.

4- Profile object is strongly typed:
Using strongly typed properties has several advantages. For example, you get full Microsoft IntelliSense when
using the Profile object in VS.NET 2005 or Visual Web Developer

---

Session:

1- Session object is scoped to a particular user:
Each user of a web application automatically has his own Session state.

2- Session object is non-persistant:
When you add an item to the Session object, the items disappear after you leave the Web site.

3- Session object uses three different ways to be stored:
3.1: In Process - default
3.2: State Server (Out of Process)
3.3: SQL Server

4- Session object is not strongly typed:
Sessopn object is simply a collection of items.

Framework Differences

Framework 2.0

C# 2.0

• generics
• Partial Classes
• Anonymous methods
• Nullable type
• Iterating over collections
• Static Classes
• Property accessor accessibility-Diiferent Accesors for Get and Set
• System.IO.Ports ->Supply the SerialPort class to implement serial port operation.
• System.IO.Compression -> Implement compression and decompression operation on files.
• System.Net.NetworkInformation -> Gather information about network events, changes, statistics, and properties.
• System.Security.AccessControl -> Provide programming elements used to control access to and audit security-related actions on securable objects.

General 2.0

• 64-bit support
• Click once deployement
• Runtime debug and modify.

ASP.Net 2.0

• ASP.NET WebParts
• Richer ASP.NET controls which leads to quicker development cycles.
• Master Pages
• Themes and Skins
• Introduction of new controls like GridView FormView DetailsView4.
• dynamic menu
• Navigation Controls.
• classes in app_data folder that makes the classes define in it to be as a Compiled dll.
• Compilation model: With 1.1, all code was compiled into one assembly placed in the bin directory. With 2.0, the assembly is separated into multiple assemblies. These multiple assemblies may be created on-the-fly or precompiled. Examples of multiple assemblies are one assembly for each ASP.NET directory like App_Code and App_Data as well as individual assemblies for Web Forms, User Controls, and so forth. This is a major shift in the application structure; it offers more deployment options in how the application is delivered to the users.
• Built in Security engine and Profile Object (user profile persisted between sessions)

1. Microsoft ASP.NET 2.0 supports a new object called the Profile object. We can store any type of information within a user profile including both simple data types such as strings and integers and complex types such as custom objects.
2. The Profile object is similar to the Session object, but better. Like the Session object, In other words, each user of a Web application automatically has their own profile.
3. However, unlike the Session object, the Profile object is persistent. When you add an item to the Session object, the item disappears after you leave the Web site. When you modify the state of the Profile object, in contrast, the modifications are saved between visits to the Web site

Framework 3.0

• system.speech namespace, which contains Windows Desktop Speech technology types for implementing speech recognition.
• Debugger Edit and Continue (enables a user who is debugging anapplication in Visual Studio to make changes to source code while executing in Break mode. After source code edits are applied, the user can resume code execution and observe the effect. ) With the release of 3.0 the .net framework 1.1 won't be patched
• Windows Communication Foundation (WCF), formerly called Indigo; a service-oriented messaging system which allows programs to interoperate locally or remotely similar to web services.
• Windows Presentation Foundation (WPF), formerly called Avalon; a new user interface subsystem and API based on XML and vector graphics, which uses 3D computer graphics hardware and Direct3D technologies.
• Windows Workflow Foundation (WF) allows for building of task automation and integrated transactions using workflows.

Framework 3.5

It implement Linq evolution in language. So we have the following evolution in class:

• Linq for SQL, XML, Dataset, Object
• Automatic Properties, Object Initializer and Collection Initializers
• Extension Methods
• Lambda Expressions
• Anonymous Types
  
• Active directory
• ASP.NET Ajax
  
• Paging support for ADO.NET
• ADO.NET synchronization API to synchronize local caches and server side datastores
• Asynchronous network I/O API
• Support for HTTP pipelining and syndication feeds

Onmouseover Changing header background color of accordian control

ASPX page code
<ajax:Accordion ID="MyAccordion" runat="server" SelectedIndex="0" HeaderCssClass="accordionHeader"
ContentCssClass="accordionContent" FadeTransitions="false" FramesPerSecond="40"
TransitionDuration="250" RequireOpenedPane="true" Width="100%" SuppressHeaderPostbacks="true">
<Panes>
<ajax:AccordionPane ID="AccordionPane1" runat="server">
<Header>
Login
</Header>
<Content>
Content 1 goes here
</Content>
</ajax:AccordionPane>
<ajax:AccordionPane ID="AccordionPane2" runat="server">
<Header>
Change password
</Header>
<Content>
Content 2 goes here
</Content>
</ajax:AccordionPane>
</Panes>
</ajax:Accordion>

Add the following script
here 'ctl00_ContentPlaceHolder1_MyAccordion_AccordionExtender' is used to access the accordian control.general way of accessing accordian control through jquery is as follows
$find('your accordian controls client id_AccordionExtender');
AccordionExtender is coomon so only change the client id while accessing your accordian control.

<script type="text/javascript">
function pageLoad()
{
//alert('in');
AddMouseOverToAccordion();
}


function AddMouseOverToAccordion()
{
var acc = $find('ctl00_ContentPlaceHolder1_MyAccordion_AccordionExtender');
//alert(acc.get_Count());
for(paneIdx = 0; paneIdx < acc.get_Count(); paneIdx++)
{
var k = null;
var j = null;
j= acc.get_Pane(paneIdx).header;
k = Function.createDelegate(this, this._onTitleHover);
$addHandler(j, "mouseover", k);

k = Function.createDelegate(this, this._onTitleHoverOut);
$addHandler(j, "mouseout", k);
}
}
function _onTitleHoverOut(e) {
e.target.style.background = "#2E4d7B";
e.target.style.color = "white";
}

function _onTitleHover(e) {
e.target.style.background = "#FFF8DC";
e.target.style.color = " #4B0082";
}

</script>

Dispose and Finalize in C#

When the .NET framework instantiates an object, it allocates memory for that object on the managed heap. The object remains on the heap until it's no longer referenced by any active code, at which point the memory it's using is "garbage," ready for memory deallocation by the .NET Garbage Collector (GC). Before the GC deallocates the memory, the framework calls the object's Finalize() method, but developers are responsible for calling the Dispose() method.

The two methods are not equivalent. Even though both methods perform object cleanup

The .NET garbage collector manages the memory of managed objects (native .NET objects) but it does not manage, nor is it directly able to clean up unmanaged resources. Managed resources are those that are cleaned up implicitly by the garbage collector. You do not have to write code to release such resources explicitly. In contrast, you must clean up unmanaged resources (file handles, database collections, etc.) explicitly in your code.

There are situations when you might need to allocate memory for unmanaged resources from managed code. As an example, suppose you have to open a database connection from within a class. The database connection instance is an unmanaged resource encapsulated within this class and should be released as soon as you are done with it. In such cases, you'll need to free the memory occupied by the unmanaged resources explicitly, because the GC doesn't free them implicitly.

Briefly, the GC works as shown below:

* It searches for managed objects that are referenced in managed code.
* It then attempts to finalize those objects that are not referenced in the code.
* Lastly, it frees the unreferenced objects and reclaims the memory occupied by them.

The GC maintains lists of managed objects arranged in "generations." A generation is a measure of the relative lifetime of the objects in memory. The generation number indicates to which generation an object belongs. Recently created objects are stored in lower generations compared to those created earlier in the application's life cycle. Longer-lived objects get promoted to higher generations. Because applications tend to create many short-lived objects compared to relatively few long-lived objects, the GC runs much more frequently to clean up objects in the lower generations than in the higher ones.

Finalizers—Implicit Resource Cleanup
Finalization is the process by which the GC allows objects to clean up any unmanaged resources that they're holding, before the actually destroying the instance. An implementation of the Finalize method is called a "finalizer." Finalizers should free only external resources held directly by the object itself. The GC attempts to call finalizers on objects when it finds that the object is no longer in use—when no other object is holding a valid reference to it. In other words, finalizers are methods that the GC calls on "seemingly dead objects" before it reclaims memory for that object.

Note that you cannot call or override the Finalize method. It is generated implicitly if you have a destructor for the class. This is shown in the following piece of C# code:—

   class Test
 {

  // Some Code

  ~Test
  {
     //Necessary cleanup code
  }
 }


The Dispose Method—Explicit Resource Cleanup
Unlike Finalize, developers should call Dispose explicitly to free unmanaged r
esources. In fact, you should call the Dispose method explicitly on any object
that implements it to free any unmanaged resources for which the object may be
 holding references. The Dispose method generally doesn't free managed
memory—typically, it's used for early reclamation of only the unmanaged
resources to which a class is holding references. In other words,
this method can release the unmanaged resources in a deterministic fashion.

However, Dispose doesn't remove the object
itself from memory. The object will be removed when the garbage
collector finds it convenient. It should be noted that the developer
implementing the Dispose method must call GC.SuppressFinalize(this)
to prevent the finalizer from running.

The following code illustrates how to implement the Dispose method on
a class that implements the IDisposable interface:


   class Test : IDisposable
 {
   private bool isDisposed = false;

   ~Test()
   {
     Dispose(false);
   }

   protected void Dispose(bool disposing)
   {
     if (disposing)
     {
       // Code to dispose the managed resources of the class
     }
     // Code to dispose the un-managed resources of the class

     isDisposed = true;
   }

   public void Dispose()
   {
     Dispose(true);
     GC.SuppressFinalize(this);
   }
 }


The Dispose/Finalize Pattern
Microsoft recommends that you implement both Dispose and Finalize when working
with unmanaged resources. The correct sequence then would be for a
developer to call Dispose. The Finalize implementation would run and the
resources would still be released when the object is garbage collected
 even if a developer neglected to call the Dispose method explicitly.

Simply put, cleanup the unmanaged resources in the Finalize method and the
managed ones in the Dispose method, when the Dispose/Finalize pattern has been
used in your code.

As an example, consider a class that holds a database connection instance.
A developer can call Dispose on an instance of this class to release the
memory resource held by the database connection object. After it is freed,
the Finalize method can be called when the class instance needs to be
released from the memory.

Reference: http://www.devx.com/dotnet/Article/33167

using Statement

Defines a scope, outside of which an object or objects will be disposed.

using (Font font1 = new Font("Arial", 10.0f))
{
}

C#, through the .NET Framework common language runtime (CLR), automatically releases the memory used to store objects that are no longer required. The release of memory is non-deterministic; memory is released whenever the CLR decides to perform garbage collection. However, it is usually best to release limited resources such as file handles and network connections as quickly as possible.

The using statement allows the programmer to specify when objects that use resources should release them. The object provided to the using statement must implement the IDisposable interface. This interface provides the Dispose method, which should release the object's resources.

A using statement can be exited either when the end of the using statement is reached or if an exception is thrown and control leaves the statement block before the end of the statement.

Multiple objects can be used in with a using statement, but they must be declared inside the using statement, like this:

using (Font font3 = new Font("Arial", 10.0f), font4 = new Font("Arial", 10.0f))
{
// Use font3 and font4.
}


Example:
The following sample shows how a user-defined class can implement its own Dispose behavior. Note that your type must inherit from IDisposable.

using System;

class C : IDisposable
{
public void UseLimitedResource()
{
Console.WriteLine("Using limited resource...");
}

void IDisposable.Dispose()
{
Console.WriteLine("Disposing limited resource.");
}
}

class Program
{
static void Main()
{
using (C c = new C())
{
c.UseLimitedResource();
}
Console.WriteLine("Now outside using statement.");
Console.ReadLine();
}
}


The new code would looking something like this:

using (SqlConnection cn = new SqlConnection(connectionString))
{
using (SqlCommand cm = new SqlCommand(commandString, cn))
{
cn.Open();
cm.ExecuteNonQuery();
}
}

This is essentially equivalent to the following, although my guess is that C# will internally generate two try / finally blocks (one for the SqlConnection and one for the SqlCommand), but you get the idea:

SqlConnection cn = null;
SqlCommand cm = null;

try
{
cn = new SqlConnection(connectionString);
cm = new SqlCommand(commandString, cn);
cn.Open();
cm.ExecuteNonQuery();
}
finally
{
if (null != cm);
cm.Dispose();
if (null != cn)
cn.Dispose();
}


Reference :http://msdn.microsoft.com/en-us/library/yh598w02(VS.80).aspx