.NET 2.0应用程序调试
基本信息
编辑推荐
资深调试专家John Robbins倾力打造.
全面介绍Visual Studio 2005在调试方面新特性
助您掌握强大的调试技术..
技术凝聚实力 专业创新出版
获取核心调试技术的实用指导——来自一位顶尖专家的建议...
推荐阅读
内容简介回到顶部↑
本书是资深调试专家john robbins关于调试技术方面的第4本著作。在本书上一个版本——《microsoft .net和windows应用程序调试》的基础上,作者对大部分内容进行了全面的更新。本书删掉了上一版本中的“本机代码的强大工具和技术”部分,剩下了前面的3大部分:“调试概述”、“强大的调试技术”和“强大的工具”。
在第1部分中,作者首先介绍了bug的来源以及调试的基础知识,并在该部分的结尾处,对以往读者提出的一些具有代表性的问题做了一一解答。而后,在第2部分中,作者介绍了visual studio 2005在调试方面的新特性,以及如何使用visual studio 2005、windbg、sos、adplus等进行应用程序调试。最后,在第3部分,作者介绍了如何对visual studio的ide进行扩展,以及如何编写你自己的代码分析规则。
本书的最佳读者对象是拥有一定开发经验的中高级开发人员和调试人员。
在第1部分中,作者首先介绍了bug的来源以及调试的基础知识,并在该部分的结尾处,对以往读者提出的一些具有代表性的问题做了一一解答。而后,在第2部分中,作者介绍了visual studio 2005在调试方面的新特性,以及如何使用visual studio 2005、windbg、sos、adplus等进行应用程序调试。最后,在第3部分,作者介绍了如何对visual studio的ide进行扩展,以及如何编写你自己的代码分析规则。
本书的最佳读者对象是拥有一定开发经验的中高级开发人员和调试人员。
作译者回到顶部↑
本书提供作译者介绍
John Robbins,是Wintellect(www.wintellect.com)的创始人之一,主要负责该公司的调试、咨询服务,以及调试课程的创设与教授。作为一名公认的调试专家,John热衷于寻找和修正别人程序(这也包括一流公司的应用程序)中很难发现的Bug。他是本书前两个版本的作者,也是“Bugslayer”(MSDN Magazine上广受欢迎的专栏)的特约编辑。
.. << 查看详细
.. << 查看详细
目录回到顶部↑
第1部分 调试概述
第1章 bug的来源与解决的办法
1.1 bug与调试
什么是bug
bug的处理和解决方案
制定调试计划
1.2 调试的必备条件
技能组合
学习技能
1.3 调试过程
步骤1:重现bug
步骤2:描述bug
步骤3:总是假设bug是因你而起的
步骤4:分而治之
步骤5:创造性地思考
步骤6:利用工具
步骤7:开始重度调试
步骤8:验证bug是否己被修正
步骤9:学习与分享
调试过程中的最后秘密
第1章 bug的来源与解决的办法
1.1 bug与调试
什么是bug
bug的处理和解决方案
制定调试计划
1.2 调试的必备条件
技能组合
学习技能
1.3 调试过程
步骤1:重现bug
步骤2:描述bug
步骤3:总是假设bug是因你而起的
步骤4:分而治之
步骤5:创造性地思考
步骤6:利用工具
步骤7:开始重度调试
步骤8:验证bug是否己被修正
步骤9:学习与分享
调试过程中的最后秘密
译者序回到顶部↑
俗话说,人无完人。在计算机程序设计领域中,这一点得到了非常好的印证。如果有哪个程序员某日站出来宣称自己从未创造过任何Bug,那他的名字准会在第二天出现在全世界的IT门户网站上。从某种意义上说,软件的规模和Bug的出现概率成正比。即软件的规模越大,其包含Bug的可能性就越大。例如,编写一个100%没有Bug的Hello World程序非常简单,但要编写一个100%没有Bug的操作系统则几乎是永远不可能实现的。因此,就目前而言,没有Bug的世界只存在于人们的想象之中。.
作为一个凡人,我们虽然不能靠念几句咒语就让Bug变成南瓜车,但却可以尽己之力减少Bug的产生。而这也正是John Robbins在本书中要告诉我们的重要内容之一。对于剩下的顽固Bug,John告诉我们:拿起武器,斗争到底。那这武器是什么?武器就是调试工具。
在程序员中,知晓调试者十之八九,但真正深谙调试之道者却有如凤毛麟角。为什么?正如John所说的那样,在大学的计算机专业课设置中根本没有专门的软件调试课程,即便偶尔有涉及调试内容的课程,也都是语焉不详,一带而过。同时,在校园之外也鲜有此类书籍的身影。可以说,除却本书及本书的前两个版本,能在书店发现一本介绍软件调试的专业书籍,就好似中了500万元的彩票一般。所以,对于很多新手来说,按下F5,然后祈祷世界和平,是他们唯一能做的事情。
作为Wintellect公司的资深专家和MSDN Magazine杂志“Bugslayer”专栏的资深作家,John Robbins用他宝贵的经验为我们照亮了调试征途上原本充满雾霭的漫漫长路。感谢John Robbins,是他让我们拥有了一个可以站立的巨人肩膀。..
本书的翻译过程有些曲折,但在邹建峰和郑琼的帮助下,我终于得以完成此书。8个章节中,我完成了其中的前7个章节,他们协助我完成了最后的第8章。在此,我要特别感谢他们为此所付出的努力。还是那句话,人无完人。虽然我在翻译过程中竭尽全力查阅相关资料,但肯定还是会存在某些不足之处,希望各位在遇到这些“Bug”时,能拨冗发个错误报告给我。我的电子邮件地址是:yuan505@mail.zjgsu.edu.cn。最后,本书的源代码可以在作者的网站http//dtt.wintellect.com下载到。不过访问这个地址所需的时间有时足够烧好一壶开水,所以,为了方便国内的读者,我将代码下载后也放了一份在http://econet.zjgsu.edu.cn/dtt/Debugging.Zip中。
最后,衷心感谢您阅读本书!...
陈缘
2008年元月,于浙江工商大学
作为一个凡人,我们虽然不能靠念几句咒语就让Bug变成南瓜车,但却可以尽己之力减少Bug的产生。而这也正是John Robbins在本书中要告诉我们的重要内容之一。对于剩下的顽固Bug,John告诉我们:拿起武器,斗争到底。那这武器是什么?武器就是调试工具。
在程序员中,知晓调试者十之八九,但真正深谙调试之道者却有如凤毛麟角。为什么?正如John所说的那样,在大学的计算机专业课设置中根本没有专门的软件调试课程,即便偶尔有涉及调试内容的课程,也都是语焉不详,一带而过。同时,在校园之外也鲜有此类书籍的身影。可以说,除却本书及本书的前两个版本,能在书店发现一本介绍软件调试的专业书籍,就好似中了500万元的彩票一般。所以,对于很多新手来说,按下F5,然后祈祷世界和平,是他们唯一能做的事情。
作为Wintellect公司的资深专家和MSDN Magazine杂志“Bugslayer”专栏的资深作家,John Robbins用他宝贵的经验为我们照亮了调试征途上原本充满雾霭的漫漫长路。感谢John Robbins,是他让我们拥有了一个可以站立的巨人肩膀。..
本书的翻译过程有些曲折,但在邹建峰和郑琼的帮助下,我终于得以完成此书。8个章节中,我完成了其中的前7个章节,他们协助我完成了最后的第8章。在此,我要特别感谢他们为此所付出的努力。还是那句话,人无完人。虽然我在翻译过程中竭尽全力查阅相关资料,但肯定还是会存在某些不足之处,希望各位在遇到这些“Bug”时,能拨冗发个错误报告给我。我的电子邮件地址是:yuan505@mail.zjgsu.edu.cn。最后,本书的源代码可以在作者的网站http//dtt.wintellect.com下载到。不过访问这个地址所需的时间有时足够烧好一壶开水,所以,为了方便国内的读者,我将代码下载后也放了一份在http://econet.zjgsu.edu.cn/dtt/Debugging.Zip中。
最后,衷心感谢您阅读本书!...
陈缘
2008年元月,于浙江工商大学
前言回到顶部↑
一句话,该死的Bug,是将你推入工程逾期、无尽的熬夜和被忿忿的同事所包围的绝境的罪魁祸首。Bug足以导致你的生活悲剧,如果它们过多地侵入你的软件,客户就可能停止使用你的产品,你就可能因此失业。因此,Bug是需严肃对待的问题。.
很多时候,业内人士简单地将Bug描绘成让人头痛的麻烦。问题远不止这些。所有的工程师都能指出几个含有失控Bug的工程,甚至可以列举出因过多程序错误而导致产品根本不可用以至使公司倒闭的例子。当我写本书第1版的时候,美国国家航空航天局就因为在设计阶段溜进了一个Bug而损失了一个火星航天探测器。当我写本书第2版的时候,因为GPS软件中的电池更换所产生的一个程序错误导致了一枚炸弹偏离其原定目标而砸向了美国特种部队士兵。当我写本书第3版的介绍的前一周,微软发布了——个程序补丁以挽救之前一个程序补丁造成的微软IE 6上的巨大缓冲区溢位漏洞。尽管Bug开始逐渐地受到应有的关注,但距离我们形成一种高度重视Bug,并不再将其视为开发过程中不可避免的小问题的开发氛围,我们还有很长的路要走。
我希望本书提供的信息能够帮助你学会如何从写程序开始就尽可能地避免Bug——这样,当到了需要调试纠错的时候,你就可以节省很多时间。多数开发小组由于没有意识到这一点,而将平均占开发周期近百分之五十的时间用在了调试纠错上。用正确的方法进行调试将极大地缩短调试所需的时间,这意味着你能够更快地交货。虽然你不能在需求采集和设计过程中节省更多的时间,但你肯定可以在调试过程中采取更加聪明的方法。本书对调试纠错的过程进行了全面的剖析。我不认为调试是一个孤立的步骤,它应该被视为整个产品开发周期中的有机部分。我认为,你应当从需求阶段就开始进行调试工作,并将其贯穿至最终版本的完成。
有两个问题使得在微软.NET环境中进行调试时艰难而且耗时。一是调试过程从来都是一门自学的手艺——你几乎一直以来都是靠自己的摸索前进的。即便你有计算机专业的学位,我打赌在你的大学里从没有一门课程是专门针对调试过程的。除了一些诸如设计某些根本没有人用的语言的自动程序校验之类的神秘兮兮的课程,或者为盲目乐观的超大平行进程计算机开发的调试器之外,对应用于商业软件的调试科学似乎从来都不大受教育机构的欢迎。有的教授指出,当你从开始写程序的时候就不应该出现Bug。尽管这是一个非常好的观点并且是我们孜孜以求的理想境界,但现实却往往不尽如人意。学习系统的、被实践验证过的调试技术虽然不能让你彻底避免写出带BuS的程序,但按照本书进行的练习将帮助你减少代码中出现Bug的数量,并能更快地追查出程序中出现的错误。
第二个问题是,尽管市面上有很多优秀的关于特定.NET技术的书籍,却没有哪一本书在调试问题上能够深入到有实用价值的内容。要想对任何技术进行有效的调试,你必须掌握远远多于一本特定技术专著所提供的内容。知道如何写一个嵌入到ASP.NET页面中的ASP.NET控件是一回事,而能够找出那个ASP.NET控件中的错误完全是另外一回事。要想对那个ASP.NET控件进行纠错,你首先必须了解.NET和ASP.NET的细节,知道DLL们是如何被放进ASP.NET的临时缓存的,ASP.NET又是如何着手找到那些控件的。有的书上将远程数据库连接之类的复杂特性的实现描述得很简单,诸如使用目前最热门的技术就能解决问题,但当db.Connect(“Foo”)在你的程序中失灵时——事实上它注定会失灵——你就得靠自己来找出并且修复这条技术链上断掉的环节。尽管个别涉及项目管理的书的确论及调试,但它们的侧重点多倾向于行政管理事务而不是从开发者的角度出发的。这些书或许包含了一些关于如何计划调试的有用信息,但当你面对着一个损坏的数据库或一个不停重启的ASP.NET工作进程而束手无策时,它们却帮不上什么忙。
本书的灵感来源于我在作为一个努力按时发布高质量产品的开发者和管理者,以及作为一个试图帮助其他人按时交付产品的顾问期间所经历的磨难。这些年来我学会的技巧和技术,足以用来对付这两类助长了基于微软视窗的程序开发的挑战性问题。对于正规程序调试训练上的资源匮乏,我在本书的第1部分中已给出了一个程序调试的速成教程——明确针对商业软件开发。至于第二个问题——对于一本专门针对.NET的书的需求——我想我已经提供了一本能够填补专业技术和现实应用之间空白的书。
在过去的11年中,我非常幸运地并能够有机会几乎专门致力于程序调试。其中一些经历帮助我形成了在程序调试方面的独到见解。第一个经历是在NuMega Technologies(即现在的Compuware),当时我是第一批从事BoundsChecker、TrueTime、TmeCoverage和SoftICE等超酷项目研究的工程师之一。在NuMega工作期间,我开始在MSDN杂志上撰写 “Bugslayer”专栏,之后我离开NuMega并开始撰写本书的第1版。当我和其他软件工程师们在开发各种人们能够想到的程序期间进行交流时所发送的那些令人难以置信的E-mail,让我了解到更多软件工程师们现今在交付软件产品时所面临的问题。
最后,决定我观点的最关键经历是Wintellect的创建,这给了我走出去并帮助遍布全球各地的公司解决那些棘手问题的机会。想象一下,当你在半夜两点的时候坐在某办公室黔驴技穷时,如果你再不解决Bug问题,你的客户就要终止这笔生意——这场景有些恐怖,但同时也可以让你的肾上腺素上溢。和诸如微软、eBay、Intuit等其他众多公司最优秀的工程师们合作,是我所知的学习解决各种程序调试问题的窍门和技术的最佳途径。
谁应该读这本书
本书是我为那些不想再熬夜调试程序,并且希望提高他们的代码及他们所服务的机构的工作质量的程序开发者们所写的。同时本书也是写给那些希望建设更加高效率、有影响力的团队的管理者和领导者们的。
从技术角度来说,理想的读者是那些有过一至三年在.NET或Windows平台上的开发经验的人。同时我还希望我的读者是某个现实开发部门的一员,并至少完成过一件产品的开发。尽管我并不太在意这一点,但软件行业将拥有此经验级别的开发者称为中级开发员。
高级开发员从本书中也很可能获益良多。在我收到的关于前几版的热情洋溢的E-mail中,有很多是来自于那些起初并没有指望从中学到什么的高级开发者。我很激动本书提供的一些工具能够被用来充实他们的工具箱。再有,和前面的版本一样,被称为审阅团的一群极其优秀的朋友们,在我向微软出版社交稿之前,审阅了各个章节。这些我在本书前面的致谢部分里所罗列的工程师们,可谓是开发精英中的精英,正是他们保证了所有阅读本书的人都能有所斩获。
如何阅读本书及第3版中的新内容
第1版侧重于Microsoft Visual Studio 6和Microsoft Win32的调试。第2版侧重于Microsoft Visual Studio.NET 2003和一个全新的编程范式、.NET,以及Windows本机开发。而这一版则全力关注.NET 2.0和Microsoft Visual Studio 2005。对于仍然大量从事本机开发的读者来说,本书将在未来的另一个版本中集中透彻地讨论本机C++开发。
第1版中仅本机开发的内容就占了512页,第2版中关于本机和.NET的内容占了约850页,而本版则有将近480页的内容论及.NET。当我着手撰写这部.NET专版的时候,本设想仅仅是对部分内容的改写,但结果却成了至少百分之八十的内容被改写。在第6章“WinDBG、SOS和ADPlus” (本书最长的章节)中,总共仅有4段文字沿袭自上——个版本。缩小本书的聚焦范围,以及.NET 2.0和Visual Studio 2005的重大改变是本书大量改写的主要原因。而另一个主要原因则是第2版的读者们与我交流的E-mail和展开的讨论,以及他们对于如何将此书写得更好的出色批评和建议。
代码范例
在之前的版本中,本书所含的大量代码和公用程序是广受欢迎的。第1版有2.5MB的文本源代码,而第2版中则有6.9MB。尽管因为将重点转移到.NET上后数量有所减少,但Windows资源管理器上的显示告诉我,本版至少有9.7MB的代码!请记住,这仅仅是文本和所支持的文件,不是编译指令。审阅团的一些成员说,本书包含的代码比目前绝大多数的开发类书籍的全文还要庞大。同时,所有这些代码都是最新的,因而能够充分利用.NET 2.0的特性。..
本书中,我将作为代码范例的一部分的源文件用“.\”在目录前标出。例如:当讨论将源代码装入WhoAmI目录下的WhoAmI外接程序中的Connect.cs文件时,我将文件参数标示为.\WhoAmI\Connect.cs。鉴于本书文本中有众多的代码引用,这样可以免去每次都要读一遍Book Source Code Installation Directory\WhoAmI\Connect.cs的麻烦。
本书的组织结构
我将本书分为3大部分。前两部分(第1章至第6章)您应该按顺序阅读,因为该部分的信息是按逻辑顺序来组织的。
很多时候,业内人士简单地将Bug描绘成让人头痛的麻烦。问题远不止这些。所有的工程师都能指出几个含有失控Bug的工程,甚至可以列举出因过多程序错误而导致产品根本不可用以至使公司倒闭的例子。当我写本书第1版的时候,美国国家航空航天局就因为在设计阶段溜进了一个Bug而损失了一个火星航天探测器。当我写本书第2版的时候,因为GPS软件中的电池更换所产生的一个程序错误导致了一枚炸弹偏离其原定目标而砸向了美国特种部队士兵。当我写本书第3版的介绍的前一周,微软发布了——个程序补丁以挽救之前一个程序补丁造成的微软IE 6上的巨大缓冲区溢位漏洞。尽管Bug开始逐渐地受到应有的关注,但距离我们形成一种高度重视Bug,并不再将其视为开发过程中不可避免的小问题的开发氛围,我们还有很长的路要走。
我希望本书提供的信息能够帮助你学会如何从写程序开始就尽可能地避免Bug——这样,当到了需要调试纠错的时候,你就可以节省很多时间。多数开发小组由于没有意识到这一点,而将平均占开发周期近百分之五十的时间用在了调试纠错上。用正确的方法进行调试将极大地缩短调试所需的时间,这意味着你能够更快地交货。虽然你不能在需求采集和设计过程中节省更多的时间,但你肯定可以在调试过程中采取更加聪明的方法。本书对调试纠错的过程进行了全面的剖析。我不认为调试是一个孤立的步骤,它应该被视为整个产品开发周期中的有机部分。我认为,你应当从需求阶段就开始进行调试工作,并将其贯穿至最终版本的完成。
有两个问题使得在微软.NET环境中进行调试时艰难而且耗时。一是调试过程从来都是一门自学的手艺——你几乎一直以来都是靠自己的摸索前进的。即便你有计算机专业的学位,我打赌在你的大学里从没有一门课程是专门针对调试过程的。除了一些诸如设计某些根本没有人用的语言的自动程序校验之类的神秘兮兮的课程,或者为盲目乐观的超大平行进程计算机开发的调试器之外,对应用于商业软件的调试科学似乎从来都不大受教育机构的欢迎。有的教授指出,当你从开始写程序的时候就不应该出现Bug。尽管这是一个非常好的观点并且是我们孜孜以求的理想境界,但现实却往往不尽如人意。学习系统的、被实践验证过的调试技术虽然不能让你彻底避免写出带BuS的程序,但按照本书进行的练习将帮助你减少代码中出现Bug的数量,并能更快地追查出程序中出现的错误。
第二个问题是,尽管市面上有很多优秀的关于特定.NET技术的书籍,却没有哪一本书在调试问题上能够深入到有实用价值的内容。要想对任何技术进行有效的调试,你必须掌握远远多于一本特定技术专著所提供的内容。知道如何写一个嵌入到ASP.NET页面中的ASP.NET控件是一回事,而能够找出那个ASP.NET控件中的错误完全是另外一回事。要想对那个ASP.NET控件进行纠错,你首先必须了解.NET和ASP.NET的细节,知道DLL们是如何被放进ASP.NET的临时缓存的,ASP.NET又是如何着手找到那些控件的。有的书上将远程数据库连接之类的复杂特性的实现描述得很简单,诸如使用目前最热门的技术就能解决问题,但当db.Connect(“Foo”)在你的程序中失灵时——事实上它注定会失灵——你就得靠自己来找出并且修复这条技术链上断掉的环节。尽管个别涉及项目管理的书的确论及调试,但它们的侧重点多倾向于行政管理事务而不是从开发者的角度出发的。这些书或许包含了一些关于如何计划调试的有用信息,但当你面对着一个损坏的数据库或一个不停重启的ASP.NET工作进程而束手无策时,它们却帮不上什么忙。
本书的灵感来源于我在作为一个努力按时发布高质量产品的开发者和管理者,以及作为一个试图帮助其他人按时交付产品的顾问期间所经历的磨难。这些年来我学会的技巧和技术,足以用来对付这两类助长了基于微软视窗的程序开发的挑战性问题。对于正规程序调试训练上的资源匮乏,我在本书的第1部分中已给出了一个程序调试的速成教程——明确针对商业软件开发。至于第二个问题——对于一本专门针对.NET的书的需求——我想我已经提供了一本能够填补专业技术和现实应用之间空白的书。
在过去的11年中,我非常幸运地并能够有机会几乎专门致力于程序调试。其中一些经历帮助我形成了在程序调试方面的独到见解。第一个经历是在NuMega Technologies(即现在的Compuware),当时我是第一批从事BoundsChecker、TrueTime、TmeCoverage和SoftICE等超酷项目研究的工程师之一。在NuMega工作期间,我开始在MSDN杂志上撰写 “Bugslayer”专栏,之后我离开NuMega并开始撰写本书的第1版。当我和其他软件工程师们在开发各种人们能够想到的程序期间进行交流时所发送的那些令人难以置信的E-mail,让我了解到更多软件工程师们现今在交付软件产品时所面临的问题。
最后,决定我观点的最关键经历是Wintellect的创建,这给了我走出去并帮助遍布全球各地的公司解决那些棘手问题的机会。想象一下,当你在半夜两点的时候坐在某办公室黔驴技穷时,如果你再不解决Bug问题,你的客户就要终止这笔生意——这场景有些恐怖,但同时也可以让你的肾上腺素上溢。和诸如微软、eBay、Intuit等其他众多公司最优秀的工程师们合作,是我所知的学习解决各种程序调试问题的窍门和技术的最佳途径。
谁应该读这本书
本书是我为那些不想再熬夜调试程序,并且希望提高他们的代码及他们所服务的机构的工作质量的程序开发者们所写的。同时本书也是写给那些希望建设更加高效率、有影响力的团队的管理者和领导者们的。
从技术角度来说,理想的读者是那些有过一至三年在.NET或Windows平台上的开发经验的人。同时我还希望我的读者是某个现实开发部门的一员,并至少完成过一件产品的开发。尽管我并不太在意这一点,但软件行业将拥有此经验级别的开发者称为中级开发员。
高级开发员从本书中也很可能获益良多。在我收到的关于前几版的热情洋溢的E-mail中,有很多是来自于那些起初并没有指望从中学到什么的高级开发者。我很激动本书提供的一些工具能够被用来充实他们的工具箱。再有,和前面的版本一样,被称为审阅团的一群极其优秀的朋友们,在我向微软出版社交稿之前,审阅了各个章节。这些我在本书前面的致谢部分里所罗列的工程师们,可谓是开发精英中的精英,正是他们保证了所有阅读本书的人都能有所斩获。
如何阅读本书及第3版中的新内容
第1版侧重于Microsoft Visual Studio 6和Microsoft Win32的调试。第2版侧重于Microsoft Visual Studio.NET 2003和一个全新的编程范式、.NET,以及Windows本机开发。而这一版则全力关注.NET 2.0和Microsoft Visual Studio 2005。对于仍然大量从事本机开发的读者来说,本书将在未来的另一个版本中集中透彻地讨论本机C++开发。
第1版中仅本机开发的内容就占了512页,第2版中关于本机和.NET的内容占了约850页,而本版则有将近480页的内容论及.NET。当我着手撰写这部.NET专版的时候,本设想仅仅是对部分内容的改写,但结果却成了至少百分之八十的内容被改写。在第6章“WinDBG、SOS和ADPlus” (本书最长的章节)中,总共仅有4段文字沿袭自上——个版本。缩小本书的聚焦范围,以及.NET 2.0和Visual Studio 2005的重大改变是本书大量改写的主要原因。而另一个主要原因则是第2版的读者们与我交流的E-mail和展开的讨论,以及他们对于如何将此书写得更好的出色批评和建议。
代码范例
在之前的版本中,本书所含的大量代码和公用程序是广受欢迎的。第1版有2.5MB的文本源代码,而第2版中则有6.9MB。尽管因为将重点转移到.NET上后数量有所减少,但Windows资源管理器上的显示告诉我,本版至少有9.7MB的代码!请记住,这仅仅是文本和所支持的文件,不是编译指令。审阅团的一些成员说,本书包含的代码比目前绝大多数的开发类书籍的全文还要庞大。同时,所有这些代码都是最新的,因而能够充分利用.NET 2.0的特性。..
本书中,我将作为代码范例的一部分的源文件用“.\”在目录前标出。例如:当讨论将源代码装入WhoAmI目录下的WhoAmI外接程序中的Connect.cs文件时,我将文件参数标示为.\WhoAmI\Connect.cs。鉴于本书文本中有众多的代码引用,这样可以免去每次都要读一遍Book Source Code Installation Directory\WhoAmI\Connect.cs的麻烦。
本书的组织结构
我将本书分为3大部分。前两部分(第1章至第6章)您应该按顺序阅读,因为该部分的信息是按逻辑顺序来组织的。
媒体评论回到顶部↑
“《.NET 2.0应用程序调试》是众多卓越的调试开发工具与技术的实战手册——而这仅仅是该书优点的一部分。你还能从中了解到如何解决非常棘手的问题,以及如何让你在一开始就避免那些Bug发生的工程实践方面的建议。John Robbins以一种生动的写作方式,提供了许多实用参考资料,它是一个装满实用工具和代码的百宝箱,所以,你可以马上就开始应用他的建议(而你也应该这么做)。”.
——Maria Blees,软件开发工程师,Microsoft Corporation
“《.NET 2.0应用程序调试》是.NET调试方面的权威书籍。我觉得我在每一页中都学到了新的东西,并且迫不及待地要一瞥下一章的内容。这本书将会成为我们开发团队的必读之书。”
——Jeff Lewis,资深开发者,Xactware Inc.
“既然我们无法消灭Bug,我们就得高效地处理它们。这是一个涉及很多方面的问题,包括态度、思考技巧、计划,以及工具。John Robbins为我们深度覆盖了所有的东西:如何在一开始就避免Bug的产生,如何系统地解决Bug,以及如何最有效地使用所有我们可以使用的工具。《.NET 2.0应用程序调试》将会拯救你的饭碗!”
——David Douglass,技术顾问II,ADP,Inc.
“《.NET 2.0应用程序调试》真是一笔很棒的资源。你能从中获得一整套可以帮助你更好更快地进行调试的关键技巧,而且John对那些技术的激情讲解将确保你编写出最好的代码,并使你在Bug发生前就消灭它们。”
——Jim McGregor,HBOS Plc
“拜读完《.NET 2.0应用程序调试》之后,我只能说,如果John生活在300多年前,那他肯定会被当作一个巫婆而烧死。”
——Dave Montgomery,Triant
“John是主代码害虫的灭杀者,而《.NET 2.0应用程序调试》是每一位.NET开发者书架上都应有的为数不多的几本书籍之一。这是一本扣人心弦的读物,它的内容从Visual Studio中最浅显的技巧到低级别的.NET-Windows交互Bug。最棒的是,这本书融入了John在多年帮助其他开发人员寻找和清除最坏、最有害Bug的过程中所获得的智慧。”..
——Don Keily,资深技术顾问
“John Robbins再一次编著了一本生动且非常实用的调试书籍。通过最新的.NET 2.0技术,深入探讨如何最有效地使用IDE、编译器和调试器,以及他那成堆的实用工具源代码,John继续与我们分享着他具有深度的经验。《.NET 2.0应用程序调试》通过提供快速消灭,乃至完全避免Bug的正确工具、方法和建议,节省了无数的调试时间。”
——Thomas Fejes,独立顾问,DeltaFusion Pty Ltd
“对于一个软件工程师来说,获得足够拯救一个项目的调试技能,是职业生涯上非常重大的一项任务。阅读《.NET 2.0应用程序调试》就是获取这些技能的一个重要步骤。这本书中的某些东西适合所有的经验级别。你在读完之后可能会希望能有更多的Bug可以跟踪,而这仅仅是为了将你所学的东西付诸使用。”
——Mark Bartosik,www.leakbrowser.com
“软件开发者最多可以花去他们一半的开发时间进行调试。John Robbins的《.NET 2.0应用程序调试》会帮助所有.NET程序开发者学习到主动式的调试技能。这些技能可以帮助他们更快地找到Bug,并大大地减少沮丧感。这是.NET开发者必备的书籍之一。”
——Roger Orr,OR/2.
“如果你觉得自己是个调试权威,并且已经没有什么可以学习的,在放弃John Robbins的《.NET 2.0应用程序调试》前请你三思。书中有关Bug猎杀的提示、工具及信息量令人吃惊,而这些对于帮你搜寻隐藏于某些应用程序内部最棘手和最吓人的Bug,绝对绰绰有余。这本书绝对是必读的!”...
——Roberto A.Farah,专家级工程师,Microsoft
——Maria Blees,软件开发工程师,Microsoft Corporation
“《.NET 2.0应用程序调试》是.NET调试方面的权威书籍。我觉得我在每一页中都学到了新的东西,并且迫不及待地要一瞥下一章的内容。这本书将会成为我们开发团队的必读之书。”
——Jeff Lewis,资深开发者,Xactware Inc.
“既然我们无法消灭Bug,我们就得高效地处理它们。这是一个涉及很多方面的问题,包括态度、思考技巧、计划,以及工具。John Robbins为我们深度覆盖了所有的东西:如何在一开始就避免Bug的产生,如何系统地解决Bug,以及如何最有效地使用所有我们可以使用的工具。《.NET 2.0应用程序调试》将会拯救你的饭碗!”
——David Douglass,技术顾问II,ADP,Inc.
“《.NET 2.0应用程序调试》真是一笔很棒的资源。你能从中获得一整套可以帮助你更好更快地进行调试的关键技巧,而且John对那些技术的激情讲解将确保你编写出最好的代码,并使你在Bug发生前就消灭它们。”
——Jim McGregor,HBOS Plc
“拜读完《.NET 2.0应用程序调试》之后,我只能说,如果John生活在300多年前,那他肯定会被当作一个巫婆而烧死。”
——Dave Montgomery,Triant
“John是主代码害虫的灭杀者,而《.NET 2.0应用程序调试》是每一位.NET开发者书架上都应有的为数不多的几本书籍之一。这是一本扣人心弦的读物,它的内容从Visual Studio中最浅显的技巧到低级别的.NET-Windows交互Bug。最棒的是,这本书融入了John在多年帮助其他开发人员寻找和清除最坏、最有害Bug的过程中所获得的智慧。”..
——Don Keily,资深技术顾问
“John Robbins再一次编著了一本生动且非常实用的调试书籍。通过最新的.NET 2.0技术,深入探讨如何最有效地使用IDE、编译器和调试器,以及他那成堆的实用工具源代码,John继续与我们分享着他具有深度的经验。《.NET 2.0应用程序调试》通过提供快速消灭,乃至完全避免Bug的正确工具、方法和建议,节省了无数的调试时间。”
——Thomas Fejes,独立顾问,DeltaFusion Pty Ltd
“对于一个软件工程师来说,获得足够拯救一个项目的调试技能,是职业生涯上非常重大的一项任务。阅读《.NET 2.0应用程序调试》就是获取这些技能的一个重要步骤。这本书中的某些东西适合所有的经验级别。你在读完之后可能会希望能有更多的Bug可以跟踪,而这仅仅是为了将你所学的东西付诸使用。”
——Mark Bartosik,www.leakbrowser.com
“软件开发者最多可以花去他们一半的开发时间进行调试。John Robbins的《.NET 2.0应用程序调试》会帮助所有.NET程序开发者学习到主动式的调试技能。这些技能可以帮助他们更快地找到Bug,并大大地减少沮丧感。这是.NET开发者必备的书籍之一。”
——Roger Orr,OR/2.
“如果你觉得自己是个调试权威,并且已经没有什么可以学习的,在放弃John Robbins的《.NET 2.0应用程序调试》前请你三思。书中有关Bug猎杀的提示、工具及信息量令人吃惊,而这些对于帮你搜寻隐藏于某些应用程序内部最棘手和最吓人的Bug,绝对绰绰有余。这本书绝对是必读的!”...
——Roberto A.Farah,专家级工程师,Microsoft
相关资源回到顶部↑
· 【推荐】众多高校学子口口相传,他们共同的选择--华清远见嵌入式学院(嵌入式Linux就业课程、3G手机开发就业课程,通过入学测试即签100%就业协议,4个月集中实训,世界500强企业成功就业保障!!!)· 【亚嵌教育 嵌入式培训专家】(嵌入式培训,嵌入式Linux培训,ARM培训,Linux培训,3G培训,Android培训,WINCE培训,DSP培训,FPGA培训,嵌入式就业培训)
· InfoQ中文站论坛:.NET讨论区(InfoQ .NET)
· 程序员的7种武器(正则表达式、编程语言、数据库、算法、软件调试、开发环境)
· WCF的开山之作 WCF画卷的清明上河图(WCF WF WPF)








点击看大图






加载中...

