由于上篇文章漏了一些比较重要的知识，在此文中补充。
断点篇
命中次数(Hit Counts)
右击断点，可以设置Hit Counts(命中次数)，会弹出如下的对话框
当条件满足的时候断点会被命中（即即将被执行），这个命中次数是断点被命中的次数。默认是始终break，选项有如下的几种：始终break；当命中次数达到多少次时break；当命中次数是多少的倍数时break；当命中次数大于等于多少的时候break。
于是在上篇中的条件也可以这样实现，设置命中次数等于50的时候break，按F5后，断点被触发，此时i=50。
断点过滤器
我们可以限制断点在特定的处理器和进程中。可以设置机器名、进程id、进程名、线程id、线程名中的某些条件来过滤一些断点。
注意：ThreadId需要特别说明一下，ThreadId并不是托管程序中，.NET 框架中System.Threading.Thread.ManagedThreadId，两者不能等同。简单来说，ManagedThreadId是线程在CLR中的标识符，而ThreadId却是线程在操作系统中的标识符。因此ThreadId需要从调试器中的“Threads”窗口中获取。
断点条件
我们可以设置断点达到的条件，如下图，我们设置表达式为i==5（注意是判相等，而不是赋值的等于），按F5，断点再次被触发，此时i=50。
还有一个选项是已经被改变，则里面条件是具体的变量，如我们的代码如下
- private void ConditionDebug()
- {
- int hitCount = 0;
- for (int i = 0; i < 100; i++)
- {
- if (i==49)
- {
- hitCount = 1;
- }
- }
- Console.Write("Hit Count={0}", hitCount);
- }
我们在代码里如果i==49，就将hitCount的值改变，同时设置断点的条件为
则当断点再次被触发的时候此时i=50。这个通常被用在找变量的时在什么时候发生改变。
断点的位置
可以设置断点的位置，如下图，设置程序到达那个文件的第几行第几个字符时触发断点。
断点触发时…
我们可以设置断点到达时做一些其他的事情，如打印消息，运行一个宏。
自定义调用堆栈
堆栈跟踪时vs一步步执行你的程序是对当前的方法调用继承关系的直观显示。在调试程序时，我们会经过一个又一个方法，包括方法的嵌套调用。堆栈跟踪会对这当中的每一层方法作出记录。选择“调试-->窗口-->调用堆栈”，或者是快捷键Ctrl+Alt+C就可以看到当前的堆栈跟踪状态。这里会将每个方法单独显示为一行，并且带有行号和参数值。每一个新的方法调用被称为堆栈帧。
堆栈跟踪是广为人知的调试工具，它的优点在于你可以双击任意一行跳转到程序中该层调用方法的代码。于是你可以看到程序是如何执行到这一位置的，同时可以看到方法接受的参数值。并且可以使用Ctrl+C将一个或者全部堆栈帧复制到剪贴板，并将这个方法的调用信息发送给工作伙伴。
项目属性中的Debug选项卡
如果你的项目是Console项目（控制台应用程序）或者是WinForm项目，则右击项目解决方案，选择属性，会出来如下的项目属性窗体。 
我们可以设置“启动动作”、“启动选项”和“是否启用调试”。
Start Action有三个选择项：
Start Project：默认选项，设置为启动项目
Start external program：调试的时候启动内部程序
Start browser with URL：调试的时候打开URL地址
使用Trace.axd调试ASP.NET
在以前asp时候，我们为了查看某个变量的值，通常会使用Response.Write方法。可能现在许多ASP.NET程序员也习惯在后台使用Response.Write方法将变量的值写出来，其实微软提供了很好的调试工具，即Trace.axd。它的功能主要是：配置 ASP.NET 代码跟踪服务以控制如何收集、存储和显示跟踪结果。
关键的几个选项：
1、localOnly 默认为false。这个很好理解。如果为true,只在本地输出跟踪信息。
2、enabled 是否启用跟踪。
3、pageOutput 指定在每一页的结尾是否呈现跟踪输出。如果是 false ，则只能通过跟踪实用工具访问跟踪输出。
4、requestLimit 指定在服务器上存储的跟踪请求的数目。最大为10000，默认为10
5、traceMode 指定显示跟踪信息的顺序。SortByCategory或 SortByTime(默认）
关于更多可以参考
http://msdn.microsoft.com/zh-cn/library/6915t83k%28VS.80%29.aspx
下面以一个小Demo来说明怎么使用Trace.axd来调试ASP.NET
1. 建立一个Web项目，取名为WebTraceTest
2. 编辑web.config文件，添加trace节点（在）
内容如下:
- <trace enabled="true" localOnly="true"
- pageOutput="true"
- requestLimit="15"
- mostRecent="true" />
3. 新建一个页面，取名为Test.aspx，在里面增加一个文本框和一个按钮（都是服务器端的控件）
按下F5，开始调试，会发现出现如下界面
5. 在文本框中输入文字，如Alexis，点击按钮，会发现Form Collection中会有详细的信息，如下：
说明：使用Trace.axd我们可以获得以下信息：
Request Details：请求的详细信息
Trace Information：跟踪信息
Control Tree：控件树
Session State：会话状态
Application State：应用程序状态
Request Cookies Collection：请求Cookie集合
Response Cookies Collection：响应Cookie集合
Headers Collection：标头集合
Response Headers Collection：响应标头集合
Form Collection：窗体集合
Querystring Collection：QueryString集合（即Url中？后面的字符串的信息）
Server Variables：服务器变量
将Visual Studio与一个运行中的进程连接
当你按下F5对程序开始调试时，VS.NET会对项目进行生成（如果有必要的话）并以调试模式启动程序。也就是说，只要项目位于debug版本的程序集中，VS.NET就与运行得程序之间建立了连接，以便对断点等与调试相关的方法作出反应。
不过有些时候，我们需要或者想要对正在运行得Visual Studio之外启动的进程进行调试。当进程位于debug版本的程序集中，这是可以做到的。
1.选择“工具—>调试进程”列出所有正在运行得程序，如下图
2.选择自己感兴趣的进程，点击连接，此时Visual Studio自动切换到了调试模式。
3.打开Progress窗口，发现我们刚刚选择的进程在列表中，如下图
这一技巧可以让你对Windows服务进程进行调试。编写Windows服务进程时，你无法按F5启动调试，因为它们必须先通过管理工具安装后启动才能运行。如果你在调试模式下生成并安装服务程序，就可以使用这一技巧进行调试。
而且你可以对SQL存储过程使用同样的方式进行调试。如果你安装了SQL Server调试组件，并且有足够的权限，就可以连接到SQL Server的进程，并在服务器中为存储过程设置断点来一步步执行。
调试Visual Studio中的多个项目
在实际开发中，我们往往分了许多层，有许多的项目集合在一个解决方案下。我们可以右击要调试的项目选择“调试-->运行新实例”来实现调试这个项目。我也可以右击解决方案，选择多项目调试，如下图
我们还可以设置项目的期待顺序。在客户端/服务器（CS结构）程序中，我们可以使用这一方法来确保服务器端程序在客户端程序之前运行。
只在特定类型的异常时中断
一个健壮的程序会在运行时处理所有可能出现的异常。不过开发者在调试复杂的程序时会觉得这样有些麻烦。因为所有的异常都被处理掉了。在出现任何异常时，Visual Studio不会再进行处理，或者中断代码来对用户作出提示。
幸运的是Visual Studio有个选项可以让开发者指定他们关心的异常类型。选择菜单栏à调试à异常，或者使用快捷键Ctrl+Alt+E。如下图
我们可以看到一个树状结构列出所有VS可以监视到的异常。
后面的两个勾选框的意思分别为是否被抛出和用户是否不处理。
参考:
《Visual Studio.NET使用技巧手册》
http://msdn.microsoft.com/
本文转自xshf12345 51CTO博客，原文链接：http://blog.51cto.com/alexis/574537，如需转载请自行联系原作者
