第三章 编译、调试和发布
VS.NET不仅仅是一个伟大的编辑器，也是一个伟大的编译器，调试器和性能分析器。有许多东西可以钩在VS.NET中你可以用来控制你好的编译过程。下面就是绝对有效在定位和修补错误方面：分析你的代码，依附运行的进程到你的调试程序上，在运行时改变代码和变量。这只不过是我在这章中所讲的在编译和调试你的程序过程中需要知道的少数几个题目。
代替拷贝文件，链接文件到项目中
当你加另一个存在的项到你的项目时，VS.NET总是首先作一个物理拷贝，拷贝文件到你的项目的目录，然后加拷贝的文件到项目。但是，这并不总是你想要的。为了链接而不是拷贝文件到你的项目，选择项目>加存在的项。选择你想链接的文件，代替点击打开，点击打开旁边的下拉列可以看到链接选项（见图51）。
图51 链接而不是拷贝文件
选择链接文件加选择的文件到你的项目中同样不会拷贝文件到你的项目目录中。在解决方案资源管理器中，链接文件被一个文件旁边的小的快捷键图标所标识（类似于Windows资源管理器中的快捷键图标）。
这是一个非常重要的特性在许多项目间共享文件时。例如，在一个有许多项目的解决方案中。你能创建一个“全局的”AssemblyInfo.cs文件，你的所有的项目链接到这个文件而不是它们单独的文件。通过这种方式，你能在一个确定的位置设置所有项目的版本号。
设置缺省的命名空间和程序集的名称
如果你好遵循官方在业界建议的命名规范时，你会宣称你的类以你自己的公司和特定的项目的命名空间。类型地，你以下列的命名空间层次（至少）结束：
MyCompanyName.MyProject.MyClass
当你用增加新的项目对话框来增加新的类时，VS.NET并不会对你的新类设置任何项目的命名空间。缺省的，它把它放在一个顶层的命名空间中，它也通常是你的程序集的名字。你可能会想在你创建新的项目时设置缺省的命名空间。
如果你选择项目>属性>通用属性>常规（或VS.NET2005中的项目>属性>应用），你能指定缺省的命名空间在根命名空间域（对VB.NET）或缺省的命名空间域（对C#）。这个命名空间可以有许多层。除此之外，你也能控制产生的程序集的名称通过在程序集域中指定它的名称。Windows应用典型地使用一个词作为程序集的名称，控件类库项目的命名遵循和命名空间一样的命名规范。
产生编译警告和错误
编译指示符是你放在你的代码中的特定的关键字，它可以被编译器解析和处理。这些关键字允许你控制和调整编译过程。C++开发者都熟悉这些编译指示符，这种观念也被引入到C#中。
例如，在C#中你能指定编译警告如下：
#warning This code is untested
现在，当你编译你的项目时，文本“This code is untested”出现在任务列中作为一个警告（见图52）。警告并不会改变编译行为，所以这个改变能顺利通过。这是一个重要的技巧在一个大的项目中对于注释和警告协作者有关可能的问题。请注意如果项目编译成功的话，这个任务列并不会得到焦点，所以你不会自动看到这些警告，只到你手工切换到任务列时。
图52 指定一个编译警告指示符
一个更严重的情况就是放错误编译指示符在代码中：
#error don’t build solution until I finish this method
这个错误指示符同样强迫特定的文本出现在任务列中。但是，除此之外，它也会强迫编译失败。很明显，你使用这个编译指示符只是临时用来阻止编译开始。
在VS.NET2005中，你需要选择视图>其它窗口>错误列能够看到这些指示符产生的警告和错误。
通过“Obsolete”特性产生编译警告
另一个在VS.NET编译时经常使用的显示警告的就是对方法设置“Obsolete”特性。在你的产品的开发周期中，可能会发生某个特定的方法已经过时。可能旧的方法不再有用，它可能是低效的，或者它被另一个方法代替。如果你不修改这些方法，你可以写另一个方法的实现体使用稍微不同的名称或标示。出于兼容性的考虑，你不想移去旧的方法和打破你的代码。这时“Obsolete”特性就很方便了：
[Obsolete(“Use the new MyMethodEx instead!”)]
public void MyMethod()…
<Obsolete(“Use the new MyMethodEx instead!”)>-
Public Sub MyMethod()
如上面设置的“Obsolete”特性会使一个警告消息出现在任务列表中，说明对一个方法的特定调用已经过时。警告消息也包含你作为特性的参数传递的个性化的消息（例如“Use the new MyMethodEx instead!”）。
和警告编译指示符一样，这个方法并不会改变编译的行为。你也必须激活任务列表才能看到这些警告。但是，不象警告编译指示符一样，如果有代码试图触发过时的方法时，警告才会出现。如果你没有在你的代码中引用这些方法，警告并不会出现。
设置编译前/后事件
当你编译你的解决方案时，VS.NET只是编译每个项目和产生预期的程序集。但是，如果你有一个复杂的生成要求，涉及到额外的任务，你同样能在VS.NET中自动化这些过程。这些编译前/后事件在VS.NET2003和2005中只能应用于C#和非Web的项目。大多数C++开发者都熟悉这个特性，因为它是直接从旧的Visual C++ IDE中引进的。
选择项目>属性>通用属性（或VS.NET2005中项目>属性>生成事件）。在生成事件对话框中，你能指定预生成事件命令行和生成后事件命令行。这些DOS命令会在生成前后执行。按有…的按钮打开命令行编辑器，在这你能以行的方式指定多行命令。这些命令可能是常规的DOS命令，例如Copy和move或对批处理的调用-甚至别的Windows程序。所有的命令以开的顺序执行在VS.NET的生成过程中缺省的输出控制台是输出窗口。
在命令行编辑器中，代替对你的项目目录和程序集硬编码外，可以使用为你提供的宏，当你按底部的宏按钮时。这些预定义的，经常使用的，和解决方案相关的变量-例如$(ProjectPath)或$(TargetFileName)在生成时会被实际的值替换。
一个使用这个特性的常规方法就是编译过程中自动拷贝某个数据文件，如图像或文档到正确的bin目录。使用更复杂的批处理文件和参数，你现在就能创建高度定制化的生成过程和报告。
设置程序集的输出路径
当你生成一个项目时，产生的程序集典型地放在你的项目文件夹的\bin\配置子目录下，这时配置文件夹典型的确是Debug或Release。
但是，这只是一个缺省的设置。你实际上能指定另一个你想放产生的程序集和外部文件的目录， 选择项目>属性>配置属性>生成（在VS.NET 2005中，对VB.NET项目选择项目>属性>编译或对C#项目选择项目>属性>生成）。在输出路径域中输入一个相对或绝对的路径。下次生成时就会使用这些设置。
这些特定配置的属性允许你为每一个配置指定一个特定的输出路径。例如，你能设置Debug配置的缺省路径作为一个常规的Bin子目录，同时直接设置Release生成到一个你的公司内部的网络上。
为你的程序集设置.NET框架版本
.NET框架有一个重要的并行安装特性。这意味着你可能有多个.NET框架安装在一个计算机上，它们之间并没有任何干涉。缺省，所有非Web的应用总是使用它们被编译时的.NET框架（当然，如果有的话），但Web应用缺省的总是使用最近的.NET框架的版本。
你能指定你的程序集支持和要求的.NET框架通过修改应用的配置文件（MyApplication.exe.config或web.config）。你要作的就是在配置文件中插入恰当的Configuration/startup/supportedRuntime和Configuration/startup/requiredRuntimeXML标签，并设置它的版本特性到指定的.NET框架版本。例如，能过这个方式，你能强迫一个Windows应用使用一个旧的.NET框架的版本。
配置修改在VS.NET2003中是非常容易的。对C#，到项目>属性>常规属性>常规>支持的运行时。对VB.NET，到项目>属性>常规属性>生成>支持的运行时。在这你能为你的程序集设置支持的和要求的运行时的版本（见图53）。为了验证你的程序集有正确的版本，在.NET框架中的类System.Environment中检查版本属性。
图53 为你的程序集设置.NET框架
注意到你并不能设置类库项目因为只有可执行的和Web应用才有配置文件（只能在引用你的类库的项目中设置）。也注意到支持1.0框架，即使你在1.1版本下编译你的程序集，是一个非支持的环境。简单的程序极有可能运行，但对于更加复杂的程序强烈建议你手工检查你使用1.1版本所特有的特性的代码。
发布ASP.NET WEB应用
一旦你要发布你的ASP.NET Web应用到Web服务器上时，你好必须仔细选择你想通过FTP发送的文件。新手经常问的就是他们必须发布什么文件。例如，你不需要-一种推荐的方式-发布任何代码后置的源代码文件（因为他们已经被编译到Dll文件中）或项目和解决方案文件。在大多数情况下，所有你需要发布的就是Web.config，Global.asax，和以.aspx，asmx，ascx等结尾的文件或.dll文件。但是，你能让VS.NET来作这个单调的选择。
选择项目>拷贝项目允许你拷贝你的Web项目到Web服务器上，通过使用FrontPage扩展或通过一个网络共享（见图54）。我通常拷贝项目到一个临时的使用文件共享的虚拟目录中，因为缺省的它的设置是当地的开发计算机。在拷贝项目对话框的底部我指定拷贝“只有需要运行应用的文件”。通过选择这个选项，VS.NET会找到那个文件需要发布，并只拷贝它们。现在我仅仅需要使用FTP传送临时目录下的所有内容到Web服务器上。
图54 让VS.NET决定那个文件需要发布
在调试过程中移到下一句
在VS.NET2002的2003中，当调试一个程序时，并没有实现常常需要的编辑继续特性，但实现了某个调试特性，不幸的是，大多数开发者经常忽略了。
这些特性中的一个就是移去当前执行点到不同位置的能力。例如，当你单步调试你的程序到一行时，需要向后跳几行，你能右击任意的一行，从弹出的菜单上选择设置下一行（见图55）。这强迫调试器跳转到那行继续从此处“正常”调试。
图55 在调试过程中跳转到For语句外
这样作的一个更快的方法就是拖黄箭头到任意的行。你不但能向回跳，你也能向前跳或跳转到控制的外面。但是，你不能跳转到当前堆栈的外面，所以你被限制只能在你当前的方法内移动。
这个特性非常刺激。移当前的执行行会使你的程序处于正常执行时不能达到的状态。它也是非常有用的特性，因为并不用重新开始调试就能返回到代码行。
在监视窗口中改变变量的值
除了移动下一语句的指针外，在调试时你能改变变量的值。当调试你的应用时，你可能会移动你感兴趣的变量到监视窗口（可以拖变量过来）。监视窗口除了显示当前变量的值和类型外，值域也是可以编辑的。
对大多数值类型来说当输入一个新值时是直观的。（不幸的是，DateTime变量有点麻烦因为你需要改变它的内部的记号的值）。对一个引用的类型，你能重新引用一个变更到另一个变量。举例来说，在你的监视窗口你有两个Hash表的实例，叫做foo和bar。设置变量foo到引用的bar的Hash表是相当容易的：在foo的值域输入bar。当然，你只能改变引用变量的到有同样类型（或它的派生类型）的引用变量。
如同前面的技巧一样，你能非常刺激的使用这个技巧因为它能使你程序到正常环境下不能达到的状态。
通过服务器资源管理器执行SQL存储过程
在上服务器资源管理器中的SQL服务器树分支允许你查看和分析一个SQL服务器实例。除了常规的查看数据库表和象Excel一样通过编辑行来修改表的内容的特性外，服务器资源管理器还有别的有用的特性。
VS.NET有有限的编辑存储过程的能力。右击存储过程从弹出的菜单上选择运行存储过程。VS.NET查看你的存储过程的参数列，如果需要的话 ，显示运行存储过程对话框，在这你能输入每个参数的值。现在就可以执行的存储过程并看到结果。
使用即时窗口显示变量和执行方法
监视窗口能用来查看和修改调试过程中的变量的值。除了监视窗口，用户也能访问即时窗口，它不但允许你查询变量的值也能执行方法。
通过选择调试>窗口>即时或按Ctrl-Alt-I，或在命令窗口敲打immed可以调出即时窗口。你能通过标题条是的“命令窗口-即时”来认识即时窗口（见图56）。
图56 使用即时窗口执行方法
如果在你即时窗口敲入一个变量名按着按回车，你要么看到一个值类型变量的值，要么看到一个引用变量的所有成员的名称-值对列。这也包括你的类的私有成员。
但是，即时并不仅仅是监视窗口的克隆。你也能在运行时评估表达式。例如，敲：
dtMyTable.Rows.Count<5
它会返回一个布尔值，依赖于你的DataTable的大小。除此之外，你实际上能触发你的对象实例的方法。因为VS.NET2002和2003在调试时并没有很好的DataTables的可视化，许多开发者使用即时窗口调用DataSet的GetXml()方法来看DataTables的内容。这个功能在VS.NET2002中工作的很好，但在VS.NET2003中XML字符串不幸用脱字符（\r\n）来代表新行，这样使得XML文档难以阅读。
任意时刻，通过光标上下按钮你能浏览前面提到过的查询和命令。从VS.NET2003开始，即时窗口也支持智能感知。
定制调用堆栈
一个堆栈痕迹就是当VS.NET单步执行你的程序时当前的方法调用层次的可视化显示。当你调试你的程序时，你能单步执行到方法和方法中的方法。堆栈痕迹显示所有不同的层次。如果你选择调试>窗口>调用堆栈或按Ctrl-Alt-C，你就能看到当前的堆栈痕迹。它显示每个方法调用在它自己的行，伴随有行号和参数值。每一个新的方法调用作为一个堆栈框架。
堆栈痕迹是一个众所周知的工具已经存在Visual Studio中很长时间了。堆栈痕迹窗口的好处就是你能双击堆栈时VS.NET立即跳转到你的程序中方法调用处。这允许你验证你如何到达当前的执行点和察看传递到方法的参数。
大多数开发者不知道的就是你能定制堆栈调用窗口。如果你右击调用堆栈你能定制它的外貌（见图57）。除此之外，通过按Ctrl-C你能堆栈框架到剪切板发送关于单个方法调用的信息给你的协作。通过在拷贝选择到剪切板前首先按Ctrl-A你同样能发送给你的协作者完整的堆栈调用（或当你右击后从弹出的上下文菜单上选择所有）。
图57 定制堆栈调用窗口
放程序命令行参数到项目属性中
你经常传参数到控制台程序作为命令行参数。在多数的基于Shell的环境中，例如DOS，你可以通过控制台程序名字后跟用空格分隔的字符串的值作为命令行参数。
当你通过IDE调用你的控制台程序时，你同样能设置这些命令行参数。到项目>属性>配置属性>调试（在VS.NET2005中项目>属性>调试）。在开始选择段下，现在你能指定命令行参数和工作目录。你不再需要指定程序名字，只需要一个用空格分隔的参数字符串。
Windows窗体应用也能接受命令行参数。非控制台程序集使用Environment.GetCommandLineArgs()方法来引用这些参数。
附VS.NET到一个已运行的进程中
当你按F5调试你的程序时，VS.NET生成你的项目（如果必需）接着在调试模式下开始程序。这意味着VS.NET被附加到debug版本下提供的程序以便能与断点和其它的调试相关的方法进行交互。
但是，有许多情况，你需要或想要调试一个已经运行的进程，它并不是VS.NET开始的。这同样是可能的，只要生成的进程是Debug版本。
要成功地这样作，首先为已经运行的程序打开项目。到工具>调试进程能看到所有你机器上激活的进程列（见图58）。在进程对话框，选择你想调试的进程按附加。在下一个屏幕，会问你想调试的程序的类型。VS.NET足够聪明地为你预告选择，所以类型情况下你不需要修改。在点击确定后，VS.NET试图附加到运行的进程。你将看到操作的结果，就是你想调试的程序被列在底部的调试进程列中。
图58 附加VS.NET到ASP.NET工作进程
在此，你可能也注意到VS.NET已经切换环境到调试模式，察看和输出窗口已经可视。你现在正在调试运行的进程。这意味着断点会起作用，你能查看所有的变量的值，或者说你能作和从VS.NET内部起动的程序一样的事情。
你可能怀疑这个技巧的有用性，你需要遵循一系列的步骤来附加到运行的进程。但是，这个技巧允许你调试Windows基于服务的应用。对Windows服务的应用，你不能简单的按F5因为他们需要被安装和从管理工具中启动。如果你以调试模式生成和安装你的服务，使用这个技巧你能调试你的Windows服务。
另一个令人惊奇的事情是使用这个技巧你能调试SQL服务器的存储过程。提供已经被安装的SQL服务器的调试组件和必要的调试权限，你能附加到SQL服务器进程来单步执行存储过程，通过在服务器资源管理器中的存储过程中设置断点。
对于Web应用，我发现这个技巧更有用-更快。想像你正在调试一个Web窗体，按F5VS.NET附加它到ASP.NET工作进程（对于除了Windows2003服务器版外所有的Windows操作系统是aspnet_wp.exe）首先导航到开始页。如果开始页并不是你想调试的，你必须导航到第二页。如果你使用FormsAuthentication，你也需要登录；如果你的第二页要求你填写表单，你需要执行这步才能到你想调试的代码处。问题是在每个新的调试状态下你都必须重复这些步骤。
一个更容易调试你的页面的方法就是在重新生成你的代码后附加ASP.NET工作进程。首先使用外部的浏览器导航到你好怀疑的页面。填写表单信息（如果有）接着附加到工作进程开始调试你页面。当你正在调试时，按停止按钮来退出调试状态但是保持外部的浏览器打开。在你修改你的代码和重新编译后，你所有需要作的就是再次附加调试器和刷新外部的浏览器来重新提交信息。并不需要再次登录或填写表单。
这个技巧使调试Web应用更容易，我已经不再使用旧的F5调试方法了。
在解决方案中调试几个项目
在一个多项目的解决方案中，VS.NET类型地只开始你标记为“开始项目”的项目。在解决方案资源管理器中用粗的字母来表示开始项目。如果你通过Windows资源管理器开始其它的项目，你将看到VS.NET并不会中断在这些项目中的任何断点，因为VS.NET并没有被附加为调试器。
使用前面的技巧“附加VS.NET到一个已经运行的进程中”，你能调试任何程序。但是，如果你右击你的项目并从弹出的菜单上选择调试>开始新的实例，VS.NET会启动项目，同样会附加到这个程序上。你能重复这个步骤几次来启动你的程序的多个实例仍然能调试它们。这有助于调试多线程的客户端-服务器场景。
此外，你能告诉VS.NET在启动每一个新的调试时你想启动那个项目（见图59）。右击你的解决方案从弹出的菜单上选择设置启动项目。VS.NET缺省地使用单项目启动，即只有一个项目被启动。简单地切换到多项目启动和修改每个属性的动作值：None,Start或Start Without Debugging。此外，你能控制这些多项目的启动次序，通过点击上移和下移按钮定位列表中你的项目。此一个客户端-服务器端的场景下，你能使用这个技巧确保服务器端的程序在客户端的程序之前启动。
图59 同时调试几个项目
只在确定的异常类型下中止
一个好的程序通常捕获所有在运行时可能抛出的异常。但是，对开发者调试一个仍在开发阶段的程序来说是相当困难的。因为有一些未处理的异常，当一个指定的异常被抛出时，VS.NET从不会捕获一个异常并提示用户中止在引发的代码处。
幸运的是，在VS.NET中有设置允许开发者来指定他们感兴趣的异常。如果你到调试>异常（在VS.NET2005中调试>异常>中断在特定的异常），你会看到一个树风格的列表展现了VS.NET能够钩住的所有可能的异常（见图60）。除了许多通用语言运行时的异常外，你能钩住C++，运行时检查员和Win32异常。对这个对话框的快捷键是Ctrl-Alt-E。
图60 在某个异常被抛出时中断
对于每个可能的异常你能设置明确的什么时候中断到调试器。当一个特定的异常被抛出或一个异常没有被处理时，你也能中断到调试器。对某个异常的条件如果满足时你也能设置VS.NET所要采取的缺省动作：中断到调试器，简单继续（用常规的异常处理程序处理后程序继续执行），或使用异常的父设置（要作的动作由选择的异常的父类来指定）。
除了预定义的.NET异常，你能钩你自己的.NET异常。通过点击异常对话框上的增加按钮，你能指定完整的，强命名的字符串来定义你的.NET的异常（例如“MyCompany.MyProduct.MyBusinessException”）。
VS.NET2005版的异常对话框更加直观（见图61）。两个条件（异常被抛出时和末被处理时）被展现成两个不同的列。如果条件满足时并没有机会来选择执行的动作；当异常发生时只是中断到调试器。
图61 在VS.NET2005对于确定的异常中断
只在确定的条件下中止
大多数开发者通过点击编辑器左边的灰的垂直条来增加或移去异常。点击会增加和移去红色的圆来指示一个断点。这样作，许多开发者从来不会遇到对断点你能设置非常有用的条件。选择调试>新的断点（或按Ctrl-B）。在VS.NET2002和2003中，通过右击存在的断点的红色圆接着从弹出的菜单上选择断点属性，你能得到相同的窗口。在许多情况下，你可能不会看到菜单项，即使你非常精确地右击存在的断点。在这种情况下，推荐完全移去断点接着在同一个位置设置一个新的断点来弹出新的断点窗口。
在断点窗口的底部有两个按钮。在这你能指定一个条件，它可以激活断点。首先输入一个.NET表达式。它要么是一个简单的变量名（“MyBoolVariable”）或一个更复杂的.NET表达式（“((System.DataTime.Now.Second%10)==0)”）。你能选择中断到调试器，如果表达式被评估为True或表达式的值发生改变。对第一个选项，本质上，表达式被评估为一个Boolean值。对第二个选项，你的表达式可以是任意的。表达式运行时的值从最后由这个表达式传递给它时发生变化，VS.NET才会中断到调试器（这暗示程序执行至少曾经通过这个代码段，它才能认识一个值的改变）。
由于表达式的灵活性，这个特性功能非常强大。例如，只有DataTable行数大于0时你才能调试一个DataSet的快照。
在VS.NET2005中，所有上面提供的条件需要在不同的地方访问。首先设置你的断点。接着从上下文菜单上选择条件到同样的屏幕（见图62）。
图62 在VS.NET2005中设置断点的条件
你也能看到和修改VS.NET2005中断点窗口中的条件。通过选择调试>窗口>断点或按Ctrl-Alt-B打开窗口（见图63）。你会看到所有你设置的断点列还有它们的条件。使用检查框，你同样可以失断点暂时不起作用，或通过双击断点直接跳转到文件中的相应的位置。
图63 VS.NET 2005中的断点窗口
通过Trace.axd调试ASP.NET Web应用
跟踪Web应用比以往更容易因为VS.NET允许你调试实际的ASP.NET代码。过去ASP时代Response.Write(“here”)的日子一去不复返了。但是，即使没有VS.NET，ASP.NET也有非常有用的跟踪特性：trace.axd HTTP处理体。
为了利用这个特性，到你的Web.config文件中修改configuration/system.web/trace节点。设置它的“Enabled“属性为True，这样你的Web应用开始一个特定的HTTP处理体来监听虚拟的文件trace.axd（http://localhost/YourCurrentWeb/trace.axd）。
这个URL输出了最近的HTTP请求的列表，包括它们相关的处理请求的文件和时间。如果你通过点击查看详细链接来钻取一个性特定的请求的话，你会看到大量的Web相关的信息，包括HTTP头集合，所有服务器端的变量，Cookie和session状态信息，你的程序的执行流，还有你的控件树和伴随的ViewSate和重绘大小的信息（见图64）。在这个页面上的信息是指定到每个请求并且是相当有用的。你能快速地找到那个Web控件使用了大量的ViewState或重绘大多数的HTML代码。通过使用System.Web.TraceContext类你能忽略要监听的跟踪信息。注意并不是System.Diagnostics.Trace类，但是这个类你能用到你的web页面或web控件中得到跟踪信息。
图64 Trace.axd显示有用的调试信息
TraceContext类包含一个Write（）方法还有Warn（）方法。这两个方法都会发送字符到跟踪页面，伴随有它的时间相关的信息。这两个方法提供了重载你用来指定类别-字符串，出现在跟踪页面上一个单独的列中。Warn（）方法以红色显示消息。
注意：From First(s)列以秒指示了第一次跟踪信息被忽略以来所经过的时间-特别是，BeginInit以来的时间。From Last(s)列以秒指示了前一个跟踪消息被忽略以来所经过的时间。对前一行有一个时间差。偶尔，FromFirst的值等于前一个FromFirst的值加上当前的FromLast的值。
Web.config中的trace节点也允许你指定要跟踪的请求的最大数目。在requestLimit属性指定的数字定义了跟踪停止以后请求的数目。不幸的是，当旧的跟踪信息被抛出达到请求的最大数目时，并没有一种方式来提示是否继续记录。
localOnly属性也是非常重要的。在大多数情况下它应当设为True。这样作允许只有当前登录的用户能够看到这个页面。试图用一个URL而不是localhostURL来得到trace.axd都会遇到一个错误的消息。这也确保保有当地的开发者能够看到跟踪的信息，而internet用户并不能看到。
最后，pageOutput属性指定你是否想发送实际的页面的跟踪信息，除了trace.axd。我通常并不推荐这个因为它经常和实际的页面的HTML内容进行交互。
90
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
