In .NET, there are currently three main asynchronous programming models: Asynchronous Programming Model (APM), Event-based Asynchronous Pattern (EAP) and Task-based Asynchronous Pattern (TAP). The TAP is the latest technology that is based on the Task and Task<T> types (available since .NET 4.0) in the System.Threading.Tasks namespace. Programmers can also use async/await keywords to improve the code readability since C# 5.0. There is a MSDN article explaining on the interop of the TAP model with previous asynchronous models. When programming in an asynchronous way, programmers need to be very careful of the deadlock. In this post, a common deadlock issue in TAP is explained and solutions are provided to avoid it in both production code and unit tests.

Problem

Here is the code-behind of a form. There is a button named button1 and a text box named textbox1 on the form. When the button is clicked, it runs a long time job that is sleeping for 2 seconds and shows a message in the text box then.

public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();
    }

    private void button1_Click(object sender, EventArgs e)
    {
        InvokeTask();
    }

    public void InvokeTask()
    {
        textBox1.Text = $"Start task at {DateTime.Now.ToString("T")} and wait";

        var task = DoLongTimeJob();
        task.Wait();

        textBox1.Text = $"Task finished at {DateTime.Now.ToString("T")}";
    }

    public static async Task DoLongTimeJob()
    {
        await Task.Delay(TimeSpan.FromSeconds(2));
    }
}

Investigation

As we all know, Windows applications is based on a single-threaded model. A message pump runs on the main thread which listens and dispatches messages to the different listeners. The above code run into a deadlock because of this. How does it happen?

On line 18, the main UI thread waits for the task to complete here. On line 25, the code were put on a different thread to run which just sleep for 2 seconds. After that, it tries to return back to the main UI thread. The reason is that the default behaviour of the ‘await‘  keyword will let the code after it to run in the original synchronization context. You can think of the synchronization context as a thread. If you click the button, the deadlock happens because the main UI thread is waiting for the task to complete and the awaiter (line 25) is waiting for the main UI thread to be available for running the remaining code. Although there is no ‘visible’ code after ‘await‘, the awaiter still needs to let the function finish.

Resolve in Production Code

You may have not noticed this deadlock in the past because it is quite common to use the ‘async void’ event handler instead of a normal event handler when using TAP in WinForm applications. The code usually look like the following. Note the usage of async/await in both ‘button1_Click’ and ‘InvokeTask’ method.

public partial class Form1 : Form
{
    public Form1()
    {
        InitializeComponent();
    }

    private async void button1_Click(object sender, EventArgs e)
    {
        await InvokeTask();
    }

    public async Task InvokeTask()
    {
        textBox1.Text = $"Start task at {DateTime.Now.ToString("T")} and wait";

        await DoLongTimeJob();

        textBox1.Text = $"Task finished at {DateTime.Now.ToString("T")}";
    }

    public static async Task DoLongTimeJob()
    {
        await Task.Delay(TimeSpan.FromSeconds(2));
    }
}

The magic here is the ‘async void’ event handler. It is called differently by the runtime because it returns (not completed yet) immediately when it reaches the first ‘await’ in its function body [SO answer]. So, in production code, you should try to use async/await all the way ‘up’ to the event handlers or controllers’ actions if in a ASP.NET application.

Problem In Unit Tests

What about unit testing the DoLongTimeJob method? In NUnit, the following methods code could be used to this method.

[Test]
public void TestWithWait()
{
    // Act
    var task = Form1.DoLongTimeJob();
    task.Wait();

    // Assert
    Assert.That(task.IsCompleted, Is.True);
}

[Test]
public async Task TestWithAwait()
{
    // Act
    await Form1.DoLongTimeJob();

    // Can assert on the return value if the task has results.
}

This two tests runs absolutely fine if they run solely but, both of them can’t finish when they run with the following test together. (Note the following test runs before above ones).

[Test]
public void TestRunFirst()
{
    var newTitle = "form title";
    using (var form = new Form1())
    {
        form.Text = newTitle;

        Assert.That(form.Text, Is.EqualTo(newTitle));
    }
}

Why does this happen? If we put a break point  at the beginning of the TestWithWait method (line 3 of Code Sample 3), run the test solely and run the test with TestRunFirst. Have a look at the SynchronizationContext.Current and here are the difference. When it runs solely, the SynchronizationContext.Current is null.

However, when it runs with TestRunFirst, the value of SynchronizationContext.Current is an instance of the WindowsFormsSynchronizationContext.

As you could remember, the test is running in the same way as in the normal event handler (not the ‘async void’ event handler).

Why does the SynchronizationContext.Current change? In WinForm applications, whenever a UI control is created, the current synchronization context will be changed to an instance of the WindowsFormssynchronizationContext. This can be simply validated by putting a break point in the Program.cs just before the form is created. You can see the synchronization context changed from null to WindowsFormssynchronizationContext.

Resove in Unit Tests

There are several ways to avoid the deadlock as long as you know the reason. The first method is to run the task on a different thread other than the current thread. (Please note that I have changed to use thread instead of synchronization context for the sake of simplicity.) This can be done by calling Task.Run method which will run the task on a thread from the thread pool.

[Test]
public void When_DoLongTimeJob_Called_Then_Task_Can_Be_Completed()
{
    // Act
    var task = Task.Run(async () => await Form1.DoLongTimeJob());

    // Assert
    Assert.That(task.IsCompleted, Is.True);
}

The second method is to change the behaviour of the DoLongTimeJob method. Let it run the subsequent code on a different thread instead of entering to the original thread. The Task.ConfigureAwait(bool) method allows you to do this. The method will be looked like the following.

public static async Task DoLongTimeJob()
{
    await Task.Delay(TimeSpan.FromSeconds(2)).ConfigureAwait(false);
}

Passing a false to the ConfigureAwait method. It tells the awaiter to not capture the original context and continue the execution on a different thread. It is recommended to be a good practice to always call ConfigureAwait(false) on every ‘await’ EXCEPT the remaining code after ‘await’ must be run on the original thread. For example in the InvokeTask method as shown in Code Sample 1, line 20 needs to access the UI control, so it must be run on the original thread which is the main UI thread. Note that every async methods are independent. Configuring the awaiter only affects the current ‘async’ method.

NOTE! If you want to use this method to solve the second test in Code Sample 3, you must append ConfigureAwait(false) at the end of  await Form1.DoLongTimeJob() , otherwise the test still gets blocked because the execution tries to go back to the original thread which is created in WindowsFormsSynchronizationContext as well.

The last method is to explicitly clear the SynchronizationContext when running your tests. This can be done in the SetUp method before every tests are run. The current synchronization context is cleared so that it does affect the current test.

[SetUp]
public void Setup()
{
    SynchronizationContext.SetSynchronizationContext(null);
}

Conclusion

Any of the above methods can help you avoiding the deadlock in unit tests. Personally, I prefer to apply ConfigureAwait as much as possible because, when you create an async method, you are delegating work on a different thread and have less interests on the state of the current thread. In the unit tests, either the first method or the third method works. The third method is preferable as it does not slow the tests because of the resource allocations for additional tasks.

The post How to resolve deadlock in asynchronization code with async/await appeared first on Xiaoming Tu - Blog.

• 第0代（Generation 0）：这一代是最年轻的，其中包含一些短生存期的对象，比如方法中的局部变量等。这一代的对象会被回收的比较频繁，在新建对象的时候，一般会创建在这一代中。
• 第1代（Generation 1）：这一代中的对象也是短生存期的，但只是作为一个过渡。一些较大的对象，在创建的时候也会在这一代。
• 第2代（Generation 2）：这一代中的对象都是长生存期的，比如静态类、静态成员等。他们被回收的概率会很低，所以在编写程序的时候应该尽量避免使用静态成员。

在每一代中的执行（通过显式调用GC.Collect方法）一次内存回收时，如果有对象无法被回收，它们将被移到下一代中。比如第1代中定义了一个对象，它在一次回收操作中无法被回收，那它就会被移到第1代中去。这样的好处就是移动之后的对象下次不会再被频繁的尝试去回收。因为越是后代中的对象，被回收的频率就越低。

下面通过一个非常简单的程序来演示内存回收，它主要的功能是通过一个循环不断地创建一个数组，我们主要研究这些数组所占用的内存在何时会被回收。代码中的Sleep语句主要是为了让结果显示的明显一些，否则因为时间间隔太小，而看不清楚内存的变化。接下去的测试都是基于下面的代码：

using System;

namespace ConsoleApplication3
{
    class Program
    {
        static void Main(string[] args)
        {
            int N = 10;
            float[] x = null;

            for (int i = 0; i < N; i++)
            {
                Console.WriteLine(i.ToString());

                x = new float[1000000];
                //Thread.Sleep(1000);
                //GC.Collect();
            }

            x = null;
        }
    }
}

第一次尝试，数组大小为1000，未开启Collect：

上图纵坐标为程序占用的内存数（字节）；横坐标是执行时间（秒）（下同）。可以看到内存一直在增加，并没有降低过。

第二次尝试，数组大小为1000，开启Collect：

我们可以看到，每隔一秒钟（就是我们Sleep的时间），内存就会下降一块。

第三次尝试，数组大小为1000000，未开启Collect：

结果与第二次尝试类似，因为每次创建的数组大小非常大，已经达到垃圾回收器内置的阈值，所以会自动执行回收。

垃圾回收器的工作机制比较复杂，已经不在本文的讨论范围内了，有兴趣的同学可以参考MSDN中的相关文章。推荐下面一片文章，介绍了GC的基本知识以及一些性能提升点：

http://msdn.microsoft.com/en-us/library/ms973837.aspx

The post .NET中的垃圾回收机制 appeared first on Xiaoming Tu - Blog.

下载地址：32位 64位

双击运行，在Install Options中选择“Common Utilities”下的“Debugging Tools For Windows”：

（我这里已经安装过了，所以显示是灰色的。）

安装完成之后，可以在“开始”-“所有程序”-“ Debugging Tools for Windows (x86)”中找到。

将WinDbg安装目录（ “C:\Program Files\Debugging Tools for Windows (x86)”）添加到“Path”环境变量中。

场景设计

比如有一个多文档应用程序，在代码中设计了一个管理类用于管理打开的各个文档窗口，为了便于各个模块通过访问这个类获取打开的文档清单，因此将类中的List定义为静态变量。但是由于程序员的疏忽，在文档关闭的时候List中对应的引用并没有删除，导致内存泄漏。

场景创建

Visual Studio中创建一个WindowsApplication，新建一个MDIParent窗口：

修改Program.cs中的启动窗口为此MDIParent。添加一个名为“DocumentEditorManager”的类，用下面的代码替换里面的内容：

using System;
using System.Collections.Generic;
using System.Text;
using System.Windows.Forms;

namespace WindowsFormsApplication3
{
    class DocumentEditorManager
    {
        internal static List<Form> DocumentEditors = new List<Form>();
    }
}

在MDIParent.cs文件中查找到ShowNewForm方法，修改为如下代码：

private void ShowNewForm(object sender, EventArgs e)
{
    Form1 childForm = new Form1();
    DocumentEditorManager.DocumentEditors.Add(childForm);
    childForm.MdiParent = this;
    childForm.Text = "Document " + childFormNumber++;
    childForm.Show();
}

按F5运行程序之后，打开任务管理器，多次点击工具栏中的“New”按钮，发现内存一直在上涨，即使把打开的窗口关闭了，内存依旧未释放。

发现问题原因

关闭程序，在工程下找到生成的EXE文件并运行（不要直接在VS中运行程序）。打开WinDbg，在菜单中选择“Attach to a Process”：

在打开的窗口中找到对应的程序，点击OK：

这时候，程序已经不能交互了，因为已经进入调试模式，类似于VS中命中断点时的情景。在WinDbg中能看到程序所加载的所有文件：

WinDbg支持扩展DLL来提供更加丰富的调试功能，调试.NET程序需要用到的是“SOS.DLL”模块（SOS.DLL所支持的所有命令可以在这里找到。），它包含在每个版本的.NET Framework中（比如2.0版本的路径为C:\Windows\Microsoft.NET\Framework\v2.0.50727\SOS.dll），安装完WinDbg之后已经有一份在WinDbg的安装目录下了，输入下面的命令加载“SOS.DLL”：

.load sos.dll

在WinDbg中按F5继续运行程序，使其跳出调试模式，切换到程序中，按10次“New”按钮创建10个窗口，然后关闭这10个窗口（这个过程相当于程序运行了一段时间回到最初的状态，但是内存没有减少），我们需要通过WinDbg找到是什么类出现了问题。切换到WinDbg，在菜单“Debug”中找到“Break”点击中断程序：

输入“!dumpheap –type WindowsFormsApplication3”罗列出我们程序的所有类实例：

MT与类型的概念差不多，只要类型一样，这个MT地址就一样，红色的方框中可以看到有两种，一种是1个，另外一种是10个，与Statistics中的内容一致。

理论上来说，所有的Form1都已经关闭了，应该不存在这样的对象，有些人可能觉得是垃圾回收器还没来得及回收的缘故，我们可以做一个实验，修改程序，在工具栏中加一个按钮“Clear Memory”，并在Click事件中编写如下的代码：

private void toolStripButton1_Click(object sender, EventArgs e)
{
  GC.Collect();
}

当关闭10个窗口之后点击此按钮，再在WinDbg中用dumpheap命令查看对象清单，发现它们依旧存在。

这说明垃圾回收器并没有回收它们，.NET中的垃圾回收器只会回收没有被使用的对象，所以这些Form1对象依旧被使用，那是谁在使用它们呢，我们可以通过查看其中一个对象实例的引用列表来找到源头：

比如看其中一个地址为“01f78160”的对象引用，使用下面的命令：

!gcroot 01f78160

（注意每台机器上地址不同）下面长的方框中是某一个引用的路径，箭头最终指向是Form1。后面绿色和粉色的根是一个Weak引用，这个对垃圾回收器没有影响。而红色方框的根为“HANDLE(Pinned)”，这表示一个正在使用的对象，后面看到类型是System.Object[]，可能是个数组，也可能是静态变量，因为.NET运行时中所有静态变量都是用Object[]存储的，它的第二级是一个List<Form>类型的，从这里就能找到问题的原因了。

解决问题

我们修改Form1的代码，添加窗口的Closing事件处理函数，修改为以下的代码：

private void Form1_FormClosing(object sender, FormClosingEventArgs e)
{
 DocumentEditorManager.DocumentEditors.Remove(this);
}

这样在Form1关闭的时候就会从List中移除，这时候再重复上面的步骤，可以看到在使用dumpheap命令的时候已经与前面的情况不同了：

从图中，我们可以看到，Form1还有一个对象存在，这是.NET内部机制引起的，每个MDI的窗口都有一个PropertyStore，用于优化性能，只有最后一个关闭的子对话框会被引用，所以它不会导致内存一直增长，这问题本来在.NET 2.0的时候没有的，但是.NET 2.0 SP1的时候为了修复另外一个问题导致这个问题出现了，详细的解释可以见这里。

总结

SOS.DLL是一个强大的扩展，还有非常多的功能。各个命令也支持很多参数。也可以在VS的调试器中使用SOS.DLL，VS中进入调试模式之后，可以使用相同的命令.load sos.dll来加载SOS.DLL，但是个人感觉用起来不太顺，还是WinDbg中用起来比较顺畅。

The post 使用WinDbg查找内存泄漏问题 appeared first on Xiaoming Tu - Blog.

1. Snippet Compiler
Snippet Compiler 是一个基于 Windows 的应用程序，可以通过它来编写、编译和运行代码。如果具有较小的代码段，并且不希望为其创建完整的Visual Studio .NET项目（及伴随该项目的所有文件），该工具将很有用。

2. Microsoft Source Analysis for C#（StyleCop）
微软内部的静态代码检查和代码强制格式美化工具StyleCop的4.2版本Microsoft Source Analysis for C# 。 SourceAnalysis 不是代码格式化工具，而是代码规范检查工具，它不仅检查代码格式，而是编码规范。

3. GhostDoc
GhostDoc是Visual Studio的免费插件，可以编写XML格式的注释文档。C#中XML格式的文档注释好处：Visual Studio会显示这些注释内容，还有比如NDoc或微软的文档工具也可以用这些注释生成有良好外观的帮助文件。

4. Sandcastle
Sandcastle。这是一个管理类库的文档编译器。它还可通过反射处理汇编源代码，并在代码中使用XML注释生成MSDN形式的文档，这种文档比难以解读的XML更易于理解。

5. Nunit
NUnit是一个.NET上的单元测试框架。NUnit 1.x主要是移植JUnit 3.8。从2.0版本开始，NUnit进行了重写和重新设计，使用Attributes代替特定的方法和相应的基类。

6. MyGeneration
MyGeneration是一个功能很强大的代码生成工具。通过编写各种类型脚本（C#,VB.Net,JScript,VBScript）的模板，通过数据库的表内容，生成你需要的各种代码。可以用它来生成ORM的实体类，存储过程，SQL语句等。

7. Reflector for .NET
Reflector for .NET是一个面向 Microsoft .NET Framework 的免费类浏览器、分析器和DLL反编译器。

8. The Regulator
the regulator是很有特色的工具，能使生成和测试正则表达式变得容易。它们在.NET 框架中受到支持。

9. LINQPad
LINQ是Language Integrated Query的简称，是集成在.NET编程语言的特性,是编程语言的一个组成部分。

10. NAnt
NAnt是基于.NET的生成工具，与版本Visual Studio.NET 不同，它使得你的项目创建生成过程变得容易。

这里就不给出下载地址了，Google一下一般第一条就是。

The post .Net 十大必备工具 appeared first on Xiaoming Tu - Blog.

The post 基于SharePoint Server 2007开发工作流-开发环境搭建 appeared first on Xiaoming Tu - Blog.

最近在做一个反应速度测试软件，是用C#写的，刚开始是觉得是个小工具，随便做做就可以了，结果是越做越复杂，本来打算一到两个星期就可以做完的，结果是做了两个月，当然这期间还有其他事情在做的。

问题出现

在软件中需要一个功能，就是随机生成一个长度为120的数字序列，要求是：

1.          每个数字都是1、2、3、4这四个数中的一个；

2.          前后两个数不能重复；

3.          每个数（1、2、3、4）各30个，一共120个。

我自己写了个算法，具体思路是这样的：循环120次，每次随机产生个数，然后判断这个数已经生成了多少次了，如果超过了30个或者跟前个数字重复，就重新随机产生。

进入调试之后，每次到循环这里，貌似都是循环到80次左右的时候就会出现ContextSwitchDeadlock异常，然而有时候又不会的。

郁闷一个星期…

问题解决

我差了很多资料，网上很多关于这个异常的都是说怎么会关闭掉，只要在VS里面，“调试”“异常”“Managed Debugging Assistant”下，将这个异常的勾去掉就不会再出现了。

出现是不出现了，但问题是程序到这里下不去了，屏蔽掉也没有用。

在MSDN里面，对这个异常的解释是：

如果在试图进行 COM 上下文转换期间检测到一个死锁，则将激活 ContextSwitchDeadlock 托管调试助手 (MDA)。

症状

最常见的症状是：从托管代码对非托管 COM 组件的调用未返回任何结果。另一个症状是内存使用量与时俱增。

原因

原因很可能是单线程单元 (STA) 线程不发送消息。STA 线程或者等待而且不发送消息，或者执行一个长时间的操作而且不允许发送消息队列。

内存使用与时俱增的原因是：终结器线程试图对非托管 COM 组件调用 release 而该组件未返回任何结果。这会阻止终结器回收其他对象。

解决办法

遵循有关 STA 消息发送的 COM 规则。

对运行库的影响

此 MDA 对 CLR 无任何影响。它只报告有关 COM 上下文的数据。

输出

一条描述当前上下文和目标上下文的消息。

还查了些其他的资料，得出的结论是.NET下强制转换需要很大的性能（因为才我的程序里面，得到的数字序列还要转换为枚举类型），所以造成溢出呀什么的，以为没的救了，就放弃了，跟“客户”商量了一下，用别的办法了。但是后来又要求这个一定要实现了，就请教了一位老师，他看完我的算法后知道了是我的算法问题，具体描述一下：当我生成了119个数字之后，比如1、2、3都已经30个，这样最后一个数字只能是4了，然而如果倒数第二个数字正好也是4的话，这里就会出现死循环了。后来经过调试，发现果然是这个原因，原来不是死锁，而是死循环。哎…！惨败啊！

所以，这里得出的另一个结论是，造成ContextSwitchDeadlock异常的又一原因是死循环。简简单单的原因，MSDN解释的这么复杂（对我而言），不过也有可能是MS没有把这个写出来，也就是MSDN的解释和死循环根本没关系。

总之，希望这个对大家有所帮助吧，下面也贴一下老师帮我写另一个算法。仅供参考。

          private static int[] Randomlist()

          …{

             Random ro = new Random();

             int[] Resultlist = new int[120];

             int[] KeyNumber = new int[4];

             int i,j,r,s,flg;

             for(i=0;i<120;i++)

              …{

                 Resultlist[i]=0;

             }

             for (i = 0; i < 4; i++)

              …{

                 KeyNumber[i] = 0;

             }

             for (i = 0; i < 30; i++)

              …{

                 for (j = 0; j < 4; )

                  …{

                     r = (int)ro.Next(4);

                     flg = 1;

                     if (j > 0)

                      …{

                         for (s = j–1; s >= 0; s—)

                          …{

                             if (r== (KeyNumber[s]–1))

                                 flg = 0;

                         }

                     }

                     if (flg == 1)

                      …{

                         KeyNumber[j] = r + 1;

                         Resultlist[i * 4 + j] = KeyNumber[j];

                         j++;

                     }

                 }

             }

             for ( i=1;i<120;i++)

              …{

                 if (Resultlist[i – 1] == Resultlist[i])

                  …{

                     for(j=i+1;j<120;j++)

                         if (Resultlist[j] != Resultlist[i]) break;

                     if(j<120)

                      …{

                         r = Resultlist[i];

                         Resultlist[i] = Resultlist[j];

                         Resultlist[j] = r;

                     }

                 }

             }

             for ( i = 119; i > 1; i—)

              …{

                 if (Resultlist[i] == Resultlist[i – 1])

                  …{

                     for ( j = i – 2; j >= 0; j—)

                         if (Resultlist[j] != Resultlist[i – 1]) break;

                     if (j >= 0)

                      …{

                         r = Resultlist[i – 1];

                         Resultlist[i – 1] = Resultlist[j];

                         Resultlist[j] = r;

                     }

                 }

             }

             return Resultlist;

         }

The post 关于.NET里面ContextSwitchDeadlock异常 appeared first on Xiaoming Tu - Blog.