ASP.NET:
System.Web, System.Web.Extensions

Windows Forms：
System.Windows.Forms

Windows Presentation Foundation：
System.Windows

ADO.NET和 XML：
System.Data
System.Xml
转自：http://www.cnblogs.com/Terrylee/archive/2008/01/17/net-framework-source-code-now-available.html
转自：http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx

　　（1）对象初始化Init事件：页面初始化的标志是Init事件。页面中的控件（包括页面本身）都是在它们最初的Form中被首次初始化的。在成功创建页面的控件树后，对应用程序激发这个事件。当Init事件发生时，在.aspx源文件中静态声明的所有控件都以实例化并取其默认值。应该注意到，这是还没有视图状态信息可供使用。虽然可以重载OnInit方法，但是系统并不保证这些控件实例是按照怎样的顺序被创建的。

　　（2）加载视图：在初始化之后，页面框架立即加载该页面的视图状态（ViewState）。所谓视图状态就是一些名称/值对的集合，例如可以保存TextBox控件的ID和Text属性值。它一般被用于在一个往返行程中存留信息到服务器，即参与HTTP请求与响应。

　　页面视图状态被存储在＜input type=”hidden”＞字段中，做为_VIEWSTAE的值进行记录。该视图状态通过ASP.NE自动维护。通过重写LoadViewState方法组件，开发人员可控制如何还原视图状态以及如何将其内容影射到内部状态。LoadViewState方法就是从ViewState中获取上一次的状态，并按照页面的控件树的结构，用递归来遍历整个树，将对应的状态恢复到每一个控件上。

　　（3）处理回发数据：还原了视图状态，页面树种的各个控件的状态就与浏览器上次呈现该页面时这些控件所处的状态相同。下一步需要更新这些控件的状态以发送给客户端。

　　回发数据处理阶段是各个控件有机会更新其状态，以便准确的反映相应的HTML元素在客户端的状态。例如，一个服务器TextBox控件对应的HTML元素是＜input type=text＞，在回发数据阶段，TextBox控件将检索＜input＞标记的当前值并用它刷新其内部状态。每个控件负责从以发送的数据中提取相应值，并更新其某些属性。TextBox控件将更新Text属性，而CheckBox控件将刷新其Checked属性。服务器控件和HTML元素之间的匹配关系由二者的ID确定。

　　页框架将在每个提交数据的控件上实现IpostBackDataHandler接口，然后激发LoadPostData事件，通过页面解析发现实现了IpostBackDataHandle接口的控件，这样就能正确的回传数据更新控件状态。在识别控件时，ASP.NET通过匹配控件的唯一标示符来更新正确的控件，该标识符具有名称值集和中的名称值对。这也就是在所有特定的页中每个控件都需要一个唯一标识符的原因之一。其他的步骤都由框架来完成，例如确定每个标识符在环境中是否唯一以及控件的基本属性等。

LostPostData方法的原型如下：
Public virtual bool LoadPostData(string postDatakey, NameValueCollection postCollection)

　　PostDataKey是标识控件的关键字，可以理解为控件的ID,postCollection是包含回发数据的集合，可以理解为视图状态值。该方法返回一个bool值，如果是true，则表示控件状态因回发而更改；否则返回false。页框架会更跟踪所有返回true的控件并在这些控件上调用RaisePostDataChangeEvent事件。

　　LoadPostData方法是由System..Web.WebControls.Control定义的，而添加的每一个服务器控件也是从System..Web.WebControls.Control继承的，所以对于数据的回发处理并不需要干预。

　　（4）加载页面Load：在回发数据处理阶段结束时，页面中的所有控件都根据客户端上所输入的更改来更新的状态。此时，对页面激发OnLoad事件。对于这个事件，相信大多数朋友都会比较熟悉，用Visual Studio.Net生成的页面中的Page_Load方法就是响应Load事件的方法，对于每一次请求，Load事件都会触发，Page_Load方法也就会执行。可以利用该方法执行一些页面初始化，例如准备好数据库的连接字符串。在事件引用中，为了提高性能，通常使用Page类的IsPostBack属性判断是不是数据回发。

　　（5）回发更改通知RaisePostDataChanged：如（3）所述，在所有实现了IpostBackDataHandler接口的控件被正确的回传数据更新后，每个控件都有一个布尔值的标识，标识其自上一次提交后改控件的数据是被更改还是保持其值。然后ASP.NET通过搜索页来寻找任何显示控件数据被更改的标识并激发RaisePostDataChanged。RaisePostDataChanged事件直到Load事件发生后，所有控件被更新后才激发。这保证了在控件被回传数据更新前，其他控件的数据在RaisePostDataChanged事件中没有被手动更改过。虽然也可以在Page的基础上自己定义数据更改的事件，但通常这个事件由太大用处。

　　（6）处理回发事件RaisePostBackEvent：当回传更新导致数据改变而引发服务器端事件后，引发回传的对象会在RaisePostBackEvent事件中被处理。这种引发回传的对象往往是一个按钮被单击或者其状态改变而引发回传的控件。例如Button触发乐Onclick事件、客户端修改了某个文本框的文本、同时将AutoPostBack设置为true、触发TextChanged事件等。

　　很多代码都在这个事件中执行，因为这是控制事件驱动逻辑的理想位置。为了保证呈现到浏览器的数据的正确性，在一系列的回传事件后，RaisePostBackEvent事件最终被激发。基于一致性考虑，会传中改变的控件直到这个函数被执行后才被更新。在实际的ASP.NET开发工作中要做的工作就是在此事件发生前处理代码。

　　（7） 预呈现PreRender：在处理回发事件后，页面就准备进行呈现。这一阶段的标志是PreRender事件。各个控件可利用这个很好的时机，以便执行任何需要在保存视图状态和呈现输出结果的前一刻完成得最后一些更新操作。最终请求的处理都会转变为发挥服务器的响应，预呈现这个阶段就是执行在最终呈现之前所做的状态的更改，因为在呈现一个控件之前，必须更具它的属性来产生HTML,比如Style属性。这是典型的例子，这预呈现之前，可以更改一个控件的Style，当执行预呈现时，就可以把Style保存下来，做为呈现阶段显示HTML的样式信息。

　　（8）保存状态SaveViewState：下一个状态为SaveViewState，在这一状态中所有控件以及页面本身可以刷新自己的SaveState集合的内容。所得到的视图状态随后得以序列化、进行哈希运算、进行Base64编码并关联到VI-EMSTATE隐藏自端。

　　（9）呈现视图Render：到这里，实际上页面对请求的处理基本就告一段落了，在Render事件中，也调用对象是它们呈现为HTML，然后也收集HTML发送给客户。客户接收到HTML标记后进行重组，最终显示给客户。当Render事件被重载时，开发者可以为浏览器创建定值的HTML，此时页面创建的任何HTML都还没有生效。Render方法用HtmlTextWriter对象做参数并由它产生HTML送给浏览器。这主要用于自定义控件的开发。

　　（10）处置Disposed：执行销毁控件前的所有最终清理操作。在此阶段必须释放对昂贵资源的引用，如内存的退出、数据库的连接等。

　　（11）卸载Unload：一个页面的最后生存标志就是Unload事件，该事件在页面对象被解除之前发生。在此事件中，可以调用Dispose方法尽可能释放占用的任何关键资源（例如，文件、图形对象以及数据库连接）。

Even though with the .NET framework we don't have to actively worry about memory management and garbage collection (GC), we still have to keep memory management and GC in mind in order to optimize the performance of our applications. Also, having a basic understanding of how memory management works will help explain the behavior of the variables we work with in every program we write.  In this article we'll look into Garbage Collection (GC) and some ways to keep our applications running efficiently by using static class members.

Smaller Feet == More Efficient Allocation.

To get a better understanding of why a smaller footprint will be more efficient will require us to delve a bit deeper into the anatomy of .NET memory allocation and Garbage Collection (GC).

Graphing

Let's look at this from the GC's point of view. If we are responsible for "taking out the trash" we need a plan to do this effectively. Obviously, we need to determine what is garbage and what is not (this might be a bit painful for the pack-rats out there). 

In order to determine what needs to be kept, we'll first make the assumption that everything not being used is trash (those piles of old papers in the corner, the box of junk in the attic, everything in the closets, etc.)  Imagine we live with our two good friends: Joseph Ivan Thomas (JIT) and Cindy Lorraine Richmond (CLR). Joe and Cindy keep track of what they are using and give us a list of things they need to keep. We'll call the initial list our "root" list because we are using it as a starting point.  We'll be keeping a master list to graph where everything is in the house that we want to keep. Anything that is needed to make things on our list work will be added to the graph (if we're keeping the TV we don't throw out the remote control for the TV, so it will be added to the list. If we're keeping the computer the keyboard and monitor will be added to the "keep" list).

This is how the GC determines what to keep as well. It receives a list of "root" object references to keep from just-in-time (JIT) compiler and common language runtime (CLR) (Remember Joe and Claire?) and then recursively searches object references to build a graph of what should be kept. 

Roots consist of:

• Global/Static pointers. One way to make sure our objects are not garbage collected by keeping a reference to them in a static variable.
• Pointers on the stack. We don't want to throw away what our application's threads still need in order to execute.
• CPU register pointers. Anything in the managed heap that is pointed to by a memory address in the CPU should be preserved (don't throw it out).

In the above diagram, objects 1, 3, and 5 in our managed heap are referenced from a root 1 and 5 are directly referenced and 3 is found during the recursive search.  If we go back to our analogy and object 1 is our television, object 3 could be our remote control. After all objects are graphed we are ready to move on to the next step, compacting.

Compacting

Now that we have graphed what objects we will keep, we can just move the "keeper objects" around to pack things up.

Fortunately, in our house we don't need to clean out the space before we put something else there. Since Object 2 is not needed, as the GC we'll move Object 3 down and fix the pointer in Object 1.

Next, as the GC, we'll copy Object 5 down

Now that everything is cleaned up we just need to write a sticky note and put it on the top of our compacted heap to let Claire know where to put new objects.

Knowing the nitty-gritty of CG helps in understanding that moving objects around can be very taxing. As you can see, it makes sense that if we can reduce the size of what we have to move, we'll improve the whole GC process because there will be less to copy.

What about things outside the managed heap?

As the person responsible for garbage collection, one problem we run into in cleaning house is how to handle objects in the car. When cleaning, we need to clean everything up. What if the laptop is in the house and the batteries are in the car?

There are situations where the GC needs to execute code to clean up non-managed resources such as files, database connections, network connections, etc. One possible way to handle this is through a finalizer.

During object creation, all objects with a finalizer are added to a finalization queue. Let's say objects 1, 4, and 5 have finalizers and are on the finalization queue.  Let's look at what happens when objects 2 and 4 are no longer referenced by the application and ready for garbage collection.
 
 

Object 2 is treated in the usual fashion. However, when we get to object 4, the GC sees that it is on the finalization queue and instead of reclaiming the memory object 4 owns, object 4 is moved and it's finalizer is added to a special queue named freachable.
 
 

There is a dedicated thread for executing freachable queue items. Once the finalizer is executed by this thread on Object 4, it is removed from the freachable queue. Then and only then is Objet 4 ready for collection.

So Object 4 lives on until the next round of GC.

Because adding a finalizer to our classes creates additional work for GC it can be very expensive and adversely affect the performance garbage collection and thus our program. Only use finalizers when you are absolutely sure you need them.

A better practice is to be sure to clean up non-managed resources. As you can imagine, it is preferable to explicitly close connections and use the IDisposable interface for cleaning up instead of a finalizer where possible.

IDisposaible

Classes that implement IDisposable perform clean-up in the Dispose() method (which is the only signature of the interface). So if we have a ResouceUser class instead of using a finalizer as follows:

We can use IDisposable as a better way to implement the same functionality:

IDisposable in integrated with the using keyword. At the end of the using block Dispose() is called on the object declared in using(). The object should not be referenced after the using block because it should be essentially considered "gone" and ready to be cleaned up by the GC.

I like putting the declaration for the object in the using block because it makes more sense visabally and rec is no longer available outside of the scope of the using block. Whis this pattern is more in line with the intention of the IDisposible interface, it is not required.

By using using() with classes that implement IDisposible we can perform our cleanup without putting additional overhead on the GC by forcing it to finalize our objects.

Static Methods

Static methods belong to the type, not the instance of our object. This enables us to create items that are shared by all our classes and "trim the fat" so to speak. Only pointers to our static method have to be moved around in memory (8 bytes).  The static method itself will be loaded once, very early in the application lifecycle, instead of being contained in each instance of our class. Of course, the bigger the method the more efficiency we gain by making it static. If our methods are small (under 8 bytes) we will actually get worse performance out of making it static because the pointer would be larger than the method it points to.

Here's the details...

Let's say we have a class with a public method SayHello();

With every instance of our Dude class we take up space in memory for the SayHello() method.

A (possibly) more efficient way is to make the method static so that we only have one "SayHello()" in memory no matter how many Dudes are around. Because static members are not instance members we can't use a reference to "this" and have to pass variables into the method to accomplish the same result. 

Keep in mind what happens on the stack when we pass variables (see part II of this series). We have to decide on a case-by-case basis whether using a static method gives us improved performance. For instance, if a static method requires too many parameters and does not have very much internal logic (a small footprint), it is entirely possible we would loose more efficiency in calling a static method that we would gain.

Static Variables: Watch Out!

There are a couple of things we want to watch out for with static variables. If we have a class with a static method that we want to return a unique number, the following implementation will be buggy:

If two threads call GetNextNumber() at the same time and both are assigned the same value for newNumber before s_Number is incremented they will return the same result!

We need to explicitly lock the read/write memory operations to static variables in the method so only one thread at a time can execute them. Thread management is a very large topic and there are many ways to approach thread synchronization. Using the lock() keyword is one way to ensure only one thread can access a block of code at a time. As a best practice, you should lock as little code as possible because threads have to wait in a queue to execute the code in the lock()  block and it can be inefficient.

Static Variables: Watch Out... Number 2!

The next thing we have to watch out for objects referenced by static variables.  Remember, how anything that is referenced by a "root" is not cleaned up. Here's one of the ugliest examples I can come up with:

Because the Runner Collection is static for the Olympics class, not only will objects in the collection will not be released for garbage collection (they are all indirectly referenced through a root), but as you probably noticed, every time we  run GetStats() the stream is opened to the file. Because it is not closed and never released by GC this code is effectively a disaster waiting to happen. Imagine we have 100,000 runners trying out for the Olympics.  We would end up with that many non-collectable objects each with an open resource.  Ouch! Talk about poor performance!

Singleton

One trick to keep things light is to keep only one instance of a class in memory at all times. To do this we can use the GOF Singleton Pattern.

We have a private constructor so only Earth can execute it's constructor and make an Earth. We have a static instance of Earth and a static method to get the instance. This particular implementation is thread safe because the CLR ensures thread safe creation of static variables. This is the most elegant way I have found to implement the singleton pattern in C#.

The 2.0 Static Class

In the .NET 2.0 Framework we can have a static class which is a class in which all the members must be static. This is useful for utility classes and will definitely save us memory space because this class will only exist in one place in memory and it can not be instantiated no matter what.

In Conclusion...

So to wrap up, some things we can do to improve GC performance are:

1. Clean up. Don't leave resources open!  Be sure to close all connections that are opened and clean up all non-managed objects as soon as possible. As a general rule when using non-managed objects, instantiate as late as possible and clean up as soon as possible.
2. Don't overdo references.  Be reasonable when using references objects.  Remember, if our object is alive, all of it's referenced objects will not be collected (and so on, and so on). When we are done with something referenced by class, we can remove it by either setting the reference to null.  One trick I like to do is setting unused references to a custom light weight NullObject to avoid getting null reference exceptions. The fewer references laying about when the GC kicks off, the less pressure the mapping process will be. 
3. Easy does it with finalizers. Finalizers are expensive during GC we should ONLY use them if we can justify it. If we can use IDisposible instead of a finalizer, it will be more efficient because our object can be cleaned up in one GC pass instead of two.
4. Keep objects and their children together. It is easier on the GC to copy large chunks of memory together instead of having to essentially de-fragment the heap at each pass, so when we declare a object composed of many other objects, we should instantiate them as closely together as possible.
5. And finally... keep objects lighter by making the methods static where appropriate.

Next time we'll look even more closely at the GC process and look into ways to check under the hood as your program executes to discover problems that may need to be cleaned up.

Even though with the .NET framework we don't have to actively worry about memory management and garbage collection (GC), we still have to keep memory management and GC in mind in order to optimize the performance of our applications. Also, having a basic understanding of how memory management works will help explain the behavior of the variables we work with in every program we write. In this article we'll cover an issue that arises from having reference variables in the heap and how to fix it using ICloneable.

A Copy Is Not A Copy.

To clearly define the problem, let's examine what happens when there is a value type on the heap versus having a reference type on the heap. First we'll look at the value type. Take the following class and struct. We have a Dude class which contains a Name element and two Shoe(s). We have a CopyDude() method to make it easier to make new Dudes.

           public struct Shoe{

               public string Color;

           }

           public class Dude

           {

               public string Name;

                public Shoe RightShoe;

                public Shoe LeftShoe;

                public Dude CopyDude()

                {

                    Dude newPerson = new Dude();

                     newPerson.Name = Name;

                     newPerson.LeftShoe = LeftShoe;

                     newPerson.RightShoe = RightShoe;

                     return newPerson;

                }

                public override string ToString()

                {

                     return (Name + " : Dude!, I have a " + RightShoe.Color +

                         " shoe on my right foot, and a " +

                          LeftShoe.Color + " on my left foot.");

                }

           }

Our Dude class is a variable type and because the Shoe struct is a member element of the class they both end up on the heap.

When we run the following method:

           public static void Main()

           {

               Class1 pgm = new Class1();

                  Dude Bill = new Dude();

                  Bill.Name = "Bill";

                  Bill.LeftShoe = new Shoe();

                  Bill.RightShoe = new Shoe();

                  Bill.LeftShoe.Color = Bill.RightShoe.Color = "Blue";

                  Dude Ted = Bill.CopyDude();

                  Ted.Name = "Ted";

                  Ted.LeftShoe.Color = Ted.RightShoe.Color = "Red";

                  Console.WriteLine(Bill.ToString());

                  Console.WriteLine(Ted.ToString());            

           }

We get the expected output:

Bill : Dude!, I have a Blue shoe on my right foot, and a Blue on my left foot.
Ted : Dude!, I have a Red shoe on my right foot, and a Red on my left foot.

What happens if we make the Shoe a reference type?  Herein lies the problem. If we change the Shoe to a reference type as follows:

           public class Shoe{

               public string Color;

           }

and run the exact same code in Main(), look how our input changes:

Bill : Dude!, I have a Red shoe on my right foot, and a Red on my left foot
Ted : Dude!, I have a Red shoe on my right foot, and a Red on my left foot

The Red shoe is on the other foot. This is clearly an error. Do you see why it's happening? Here's what we end up with in the heap.

Because we now are using Shoe as a reference type instead of a value type and when the contents of a reference type are copied only the pointer is copied (not the actual object being pointed to), we have to do some extra work to make our Shoe reference type behave more like a value type.

Luckily, we have an interface that will help us out: ICloneable. This interface is basically a contract that all Dudes will agree to and defines how a reference type is duplicated in order to avoid our "shoe sharing" error. All of our classes that need to be "cloned" should use the ICloneable interface, including the Shoe class.

ICloneable consists of one method: Clone()

                  public object Clone()

                  {

                  }

Here's how we'll implement it in the Shoe class:

           public class Shoe : ICloneable

             {

                  public string Color;

                  #region ICloneable Members

                  public object Clone()

                  {

                      Shoe newShoe = new Shoe();

                      newShoe.Color = Color.Clone() as string;

                      return newShoe;

                  }

                  #endregion

             }

Inside the Cone() method, we just make a new Shoe, clone all the reference types and copy all the value types and return the new object. You probably noticed that the string class already implements ICloneable so we can call Color.Clone(). Because Clone() returns a reference to an object, we have to "retype" the reference before we can set the Color of the shoe.

Next, in our CopyDude() method we need to clone the shoes instead of copying them

                public Dude CopyDude()

                {