C#调试

[转]C#调试

原文链接：http://www.cnblogs.com/alexis/archive/2010/11/06/1870519.html

   我们在做程序开发时，难免会遇到错误异常。如何快速地找到出错的地方、分析错误的原因以及找到解决问题的方案，是许多初级程序员困扰的问题，这也正是经验的宝贵之处。 下面我将简单介绍在Visual Studio中调试以及一些高级的调试和常见的错误。

 

PS：如无特别说明Visual Studio均指Dev10即Visual Studio 2010。 

 

入门篇

 

假设你是有着.Net平台的程序员，并且使用Visual Studio 做为开发工具。

 

断点：最简单的一种，设置一个断点，程序执行到那一句就自动中断进入调试状态。设置断点，在你觉得有问题的代码行，左侧单击，会出现红色的红点即断点。

 

 

 

启动调式：按F5，或者菜单栏---调式---开始调试，或者工具栏的图标

 

快速监视：快速查看变量或者表达式的值，也可以自定义表达式进行计算

  

 

单步执行

有三种，一种是每次执行一行（F10）；一种是每次执行一行，但遇到函数调用就会跳到被调用的函数里（F11）；一种是直接执行当前函数里剩下的指令，返回上一级函数（Shift+F11）。

还有一种后悔药，设为下一句(Set Next Statement)，即下一句会被执行的语句（右击设置或者快捷键：Ctrl+Shift+F10），但要注意在调试与数据有关的时候，设置下一句有可能会报异常。如在调试向DataTable中添加行的时候，已经存在的行不能重复被添加到DataTable中。

 

监视

调试器可能会自动列出一些相关变量的值，但是你可能还关心其它变量的值，可以添加对这些变量的监视。还可以监视一个表达式的值，比如a+b。但是，这个表达式最好不要修改变量的值，比如监视a++都会导致监视时修改了a的值，影响了程序的运行结果。

 

 

调试技巧篇

 

使用快捷键会大大提升我们的调试效率，常用的调试快捷键:

F5 启动调试

F10 执行下一行代码，但不执行任何函数调用。

F11 在执行进入函数调用后，逐条语句执行代码。

Shift + F11 执行当前执行点所处函数的剩余行。

Shift + F5 停止运行程序中的当前应用程序。可用于“中断”模式和“运行”模式。

 

拖动断点（感谢 圣殿骑士的提醒）

在调试中，我们可以拖动断点，使得程序运行到我们想要运行的地方。通常是用来验证这段代码对程序的运行结果有没有影响的。因为我们拖动代码，则被过滤的代码就不会执行，将它跟原来的相比，可以看出去掉这段代码有什么影响

 

条件中断

假如你写了个for循环，而且循环的次数比较多，如下代码，现在我们知道在i=50的时候会有异常，那我们不可能按50次F5去调试这代码，不然这效率….

private void ConditionDebug()
{
     for (int i = 0; i < 100; i++)
     {
          if (i==50)
          {
                    //some error code here
                    Console.WriteLine("i=50 here");
          }
     }
}

我们可以直接利用vs提供的功能修改变量i的值，一开i=0，即刚进入for循环中，我们设置将i改为49并回车，再调试一次，会发现i=50； 如下图

 

 

 当然我们也可以直接在代码里写代码以达到这个目的，代码如下

private void ConditionDebug()
{
            for (int i = 0; i < 100; i++)
            {
                System.Diagnostics.Debug.Assert(i != 50);
                if (i==50)
                {
                    //some error code here
                    Console.WriteLine("i=50 here");
                }
            }
} 

使用了调试中的Assert（断言），当执行程序后会弹出如下的提示框，点击Ingore（忽略）即可,

会发现此时i已经为50了，有兴趣的朋友可以看看Assert的其他用法。

 

 

 

Immediate Window

Immediate window在调试的时候计算表达式的值、执行语句、打印变量的值等。我们输入命令（注意一定要以“>”开头），会有智能提示，而且命名都是自解释型。

 

如，我们现在想要知道i的值，可以输入命名>Debug.Print i（也可以简单的使用>? i），如下图

 

 

Immediate window还有更强大的用法，计算方法的返回值（如果有的话）

如果有这个的函数

int MethodValue(int a)

 {

            if (a==1)

            {

                return 1;

            }

            else

            {

                return 0;

            }

 }

 

我们可以使用Immediate命令 >? class.Method(args) 去调用这个方法，如下图

 

 其中p是当前类的实例（因为MethodValue是类的方法，注意？和表达式之间要有空格）

 

 

对于一些实时性很高的程序（如socket）使用   Debug.Write()把错误写到日志文件中，.Net可以将Debug信息写到你指定的文件中，记住，写进出的信息不一定是出错的信息，也可以是你的程序的运行的一些重要信息,当你调试过程中发现某个模块出了问题，但是不能决定位置，那你就可以使用这个方法，如果是一天才出一个错误，那你就更要使用这个方法。

 

 

实例篇

 

涉及到WS（WebServices）的调试

在基于WinForm的实际开始开发中，我们往往采用WS用做数据的传递，我们在前台获取收集数据，通过WS将数据传递给后台，后台做相应的业务逻辑处理后，会持久到数据库中。而往往我们又会在WS中写一些相关的代码，如身份验证、日志记录、提示信息等，怎样去调试这些代码呢。

 

涉及到JavaScript的调试

许多程序员为调试JavaScript感到困惑不已，因为没有一款很好的调试工具。一些人喜欢使用FireBug来调试JavaScript，确实是一个不错的选择，Firebug提供了许多的JavaScript信息，是一款不错的调试JavaScript的工具。下面我将会介绍如何使用Visual Studio调试JavaScript，Visual Studio中调试JS跟调试C#差不多，都是设置断点，不同的是我们在查看元素值的时候需要注意点。

 

涉及到Ajax的调试

现在ajax已经十分的流行，但是随之而来的即调试困难，大部分初级程序员不知道如何有效地从前台调试到后台代码，以至出了很多不完善的ajax应用。

下面以一个简单的实例来介绍如何使用Visual Studio调试JavaScript。实例是使用Ajax验证用户登录，如果验证通过，则提示“登录成功”，否则提示“登录失败”。

下面是主要的代码，我们使用jQuery来实现ajax，并且在后台文件中故意出错。

正确的用户名和密码是admin和1

调试方法如下，在后台入口处设置断点，然后在前台js中调用后台的方法处设置断点，然后按F5启动调试，当我们输入用户名、密码后，点击登录后会发现，前台断点被触发了。

 

按F5继续调试，有时候会跳到jQuery的源码中，不管他，继续F5，会发现执行到后台中的断点中，如下图

而后台代码的调试是十分简单的。（PS：有时候无需在前台设置断点也可直接进入后台的调试，如何不行的话，在前台html文件或者aspx文件中认为有可能出错的地方设置断点，一步步调试）

 

 

 

一些调试中出现的常见错误(会陆续更新)：

1． 我们调试到某一句代码的时候，突然莫名奇妙的跳出来了，其实是刚刚执行的这一句话有异常，我们可以使用try…catch进行异常捕获，看看异常原因是什么，然后做相应的处理

2． 在ADO.NET，我们会使用ds.Merge()方法进行合并内存表，如果有异常的话，一般有以下三种情况：

A.其中一张表中有两行一模一样的数据，包括主键

B.这两张表的结构不一致

C.两张表中某个字段的类型不匹配，如字段age在A表中式string，而在B表中确是Decimal

 

 

断点篇

 

 

命中次数(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可以监视到的异常。

后面的两个勾选框的意思分别为是否被抛出和用户是否不处理。

posted @ 2010-11-14 21:17 St.Dlng 阅读(733) 评论(0) 编辑

程序员能力矩阵 你属于哪一层？[转自CSDN]

注意:每个层次的知识都是渐增的，位于层次n，也蕴涵了你需了解所有低于层次n的知识。

计算机科学 Computer Science

软件工程 Software Engineering

程序设计 Programming

 

经验 Experience

学识 Knowledge

【CSDN编者按】

上述图书中，第一级对应的英文为Unleashed series, 21 days series, 24 hour series, dummies series...其实也有很多不错的书，Unleashed即图灵所出揭秘系列，好书不少；即使是21天、24小时、dummies系列，从入门来说也基本上都算好书。大家在选书时，首先对国内原创的大套书要特别持谨慎态度，越大型的丛书越要小心，因为没有人对这样浩大的工程真正负责。而国外的书原著总体上水平都有较好的保证，主要看译者是否负责。

图书第二级中《别让我思考》对应英文为《Don't Make me Think》，中文版名字应该是《点石成金》。

图书第三级中《代码珠玑》，中文版名应为《编程珠玑》（两卷：卷1链接，卷2链接）。

原文出处：

http://www.indiangeek.net/wp-content/uploads/Programmer%20competency%20matrix.htm

译文出处：

http://static.icybear.net/%5BCN%5DProgrammer%20competency%20matrix.htm

posted @ 2010-11-14 14:19 St.Dlng 阅读(70) 评论(0) 编辑

[转载自CSDN]风雨20年：我所积累的20条编程经验

   从11岁时，我就一直在编程，并且一直都很喜欢技术和编程。这些年来，我积累了一些艰难又容易的经验。作为一名程序员，你或许还没这些经验，但我会把它们献给那些想从中学到更多的朋友。

　　我会持续更新这些经验，我可能还会有更多的感想，但就我这20年来看，我想下面这个列表中基本不需要增添额外的东西了。下面就是我至今最难忘的经验。

　　1. 估算解决问题所需要的时间。不要怕，承认吧！我曾见过一些程序员为了解决一个特殊问题而坐在显示器前面8小时。为自己定一个时间限制吧，1小时、30分钟或甚至15分钟。如果在这期间你不能解决问题，那就去寻求帮助，或到网上找答案，而不是尝试去做“超级堆码员”。

　　2. 编程语言是一种语言，只是一种语言。随着时光推移，只要你理解了一种语言的原理，你会发现各种语言之间的相似之处。你所选择的语言，你应该觉得“舒服”，并且能够写出有效（而且简洁）的代码。最重要的，让语言去适应项目，反之亦然。

　　3. 不要过于注重程序的“设计模式”。 有时候，写一个简单的算法，要比引入某种模式更容易。在多数情况下，程序代码应是简单易懂，甚至清洁工也能看懂。

　　4. 经常备份代码。在我年轻时，我就有过因硬盘故障而丢了大量代码的经历，这经历很恐怖的。只要你一次没有备份，就应当像有着严格的期限，客户明天就需要。此时就该源码/版本控制软件大显身手了。

　　5. 承认自己并不是最顶尖的程序员-知不足。我常想，我对编程了解已足够多，但是总有其他人比你优秀。正所谓，“一山总比一山高”。所以，向他们看齐吧！

　　6. 学习再学习。正如第5点所说，我经常会在手里拿一本计算机或编程相关的杂志或书（不信，可以问我的朋友）。诚然，总有很多你不知道的技术，你可以从中学习以保持不落后。如果你有一种灵巧的方式来获取你需要的新技术，那你每天都应该坚持学习。

　　7. 永恒的变化。你对待技术/编程知识，就应像你对待股票一样：多样化。不要在某一特定技术上自我感觉良好。如果那种技术或语言已经没有足够支持，那你还不如现在就开始更新你的简历，并启动培训新计划。我能保持前行的主要原则是什么呢？至少了解两到三种语言，所以，如果某种语言过时了，你在学习新技术的时候还可以依靠另一种语言。

　　8. 提携新人。协助并且培养初级/入门的开发人员学习优秀的编程方法和技巧。也许你还不知道，在帮助他们向更高一层前进时，你自己也在向更高一层提升，你会更加自信。

　　9. 简化算法。代码如恶魔，在你完成编码后，应回头并且优化它。从长远来看，这里或那里一些的改进，会让后来的支持人员更加轻松。

　　10. 编写文档。无论是Web服务的API，还是一个简单的类，你尽量编写相应文档。我曾经引以为豪的代码注释，因过度注释而有人指责。给三行代码加一行注释，只需要你几秒时间。如果那是一个比较难以理解的技术，千万别担心过多注释。如果你能很好的做好自己的工作，大多数架构师、后备程序员、支持组都会感激你。

　　11. 测试、测试再测试。我是一名黑盒测试粉丝。当你完成编码后，你“被认可”的时候就开始了。如果你们公司有QA部门，如果你的代码中有错误，那你得到的评论，会比项目经理还多。如果你不彻底测试自己的代码，那恐怕你开发的就不只是代码，可能还会声名狼藉。

　　12. 庆祝每一次成功。我见过很多程序员在解决编程技术难题后，会和同伴握手、击掌或甚至手舞足蹈。每个人在生命中都会碰到“顿悟”。如果一个程序员高兴地跑来叫你去看他的非凡代码，也许你已经看过这样的代码100遍了，但你也应该为了这个家伙而庆祝第101次。（编者注：《庆祝成功的九种方式》。）

　　13. 经常检查代码。在公司，你的代码要经常检查（包括自查和其他同事检查）。不要把别人的检查，看成是对代码风格的苛求。应该把它们看作是有建设性的批评。对个人来说，经常检查你的代码并且自问，“我怎样才能写得更好呢？”这会让你加速你的成长，让你成为一个更优秀的程序员。

　　14. 回顾你的代码。在看到自己以前的代码时，通常会有两种方式：“难以至信，这代码是我写的”和“难以至信，这代码是我写的”。第一种往往是厌恶的语气，并在想如何改进它。你也许会惊叹，旧代码也能复活成为一种更好的程序，甚至是一个完整的产品。第二种通常带着惊奇和成就感。开发人员应该有一到两个自己完成的项目成果，能让众人不禁而立并注目而观。同样，基于你优越的编程能力，你可以把过去的程序或项目拿出来，把它们更新为更加优秀的产品或想法。

　　15. 幽默是不可缺的。在我20年的开发生涯中，我还没有碰到哪位程序员是没有幽默感的。实际上，干我们这行，幽默是一项必备品。

　　16. 谨防那些无所不知的程序员，不愿分享的程序员，还有经验不足的程序员。当你遇到这几种程序员时，你自己要谦虚。无所不知的程序员，更想当一个英雄而不是团队成员；保守的程序员则是在编写着他们独享的代码；而经验不足的程序员则会每十分钟就来问你一下，当代码完成后，代码已经是你的，而不是他们。

　　17. 任何项目都不会那么简单。朋友、家人和同事曾请求我仓促做一些事情，仓促做一个程序或者网站。对于这样的事，应该从双方做计划，才能做出令两方都会满意的东西。如果某人起初只是需要一个使用MicrosoftAccess的、只有有3个页面的网站，但来就很可能变成一个有15个页面的网站，并使用SQL Server，有一个论坛，还有一个定制的CMS（内容管理系统）。

　　18. 任何时候不要想当然。假如你承接一个简单的项目，你可能会认为某个部分可以轻松完成。千万别这样想！除非你有一个类、组件、或者一段已经写好的代码，并且在现有的项目已经测试通过。不要认为这将是很容易的。

　　19. 没有已经完成的软件。曾经有一位程序员告诉我，没有软件是已经完成的，它只是“暂时完成了”。这是明智的忠告。如果客户还在使用你写的程序，并经受了时间的考验。如果有机会，你仍在更新它，这并不是什么坏事，这让你不断地前行。

20. 耐心是一种美德。当客户、朋友或家庭成员用电脑的时候，他们也许会受挫，进而想砸电脑，或气冲冲地离开。我一直在告诉他们，“是你掌控电脑，不是电脑掌控你。”对于用作编程的电脑，你要有一定的耐心。一旦程序员知道问题所在后，他们就会站在电脑的角度看问题，并且说“哦，这就是为什么它是这样做。