.sln
bin->debug->dll
dll .net程序集
xap文件部署到真的手机程序当中 与bin文件类似 将其重命名为zip类型将看到与bin文件夹的文件相同,只是一个运行在模拟器一个与行在真机
pdb 用于在仿真器中使用
Visual Studio.NET采用两种文件类型（.sln和.suo）来存储特定于解决方案的设置,它们总称为解决方案文件。为解决方案资源管理器提供显示管理文件的图形接口所需的信息
从而在每次继续开发任务时，不会因开发环境而分散精力；
*.sln：(Visual Studio.Solution) 通过为环境提供对项目、项目项和解决方案项在磁盘上位置的引用,可将它们组织到解决方案中。
比如是生成Debug模式,还是Release模式,是通用CPU还是专用的等
*.suo: (solution user opertion) 解决方案用户选项记录所有将与解决方案建立关联的选项，
以便在每次打开时，它都包含您所做的自定义设置。
.suo是solution user option的缩写，它是很重要的文件，它储存了用户界面的自定义配置，包括布局、断点和项目最后编译的而又没有关掉的文件(下次打开时用)等，以便于下一次你打开Visual Studio可以恢复这些设置，因此不要随便删除也无法删除，况且它们就是隐藏文件，所以不要管它们。 其实上面英文中解释已经很清楚了，要申明的是PDB中不带断点信息
一 什么是PDB文件
大部分的开发人员应该都知道PDB文件是用来帮助软件的调试的。但是他究竟是如何工作的呢，我们可能并不熟悉。本文描述了PDB文件的存储和内容。同时还描 述了debugger如何找到binay相应的PDB文件，以及debugger如何找到与binay对应的源代码文件。本文适用于所有的Native和 Managed的开发人员。
在开始前，我们先定义2个术语：private build， 用来表示在开发人员自己机器上生成的build；public build，表示在公用的build机器上生成的build。private build相对来说比较简单，因为PDB和binay在相同的地方，通常地我们遇到的问题都是关于public build。
所有的的开发人员需要知道的最重要的事情是”PDB文件跟源代码同样的重要“， 没有PDB文件，你甚至不能debugging。对于public build，需要symbol server存储所有的PDB，然后当用户报告错误的时候，debugger才可以自动地找到binay相应的PDB文件， visual studio 和 windbg都知道如何访问symbol server。在将PDB和binay存储到symbol server前，还需要对PDB运行进行source indexing， source indexing的作用是将PDB和source关联起来。
接下来的部分假设有已经设置好了symbol server和source server indexing。TFS2010中可以很简单地完成对一个新的build的source indexing 和 symbol server copying。
二 PDB文件的内容
正式开始PDB的内容，PDB不是公开的文件格式，但是Microsoft提供了API来帮助从PDB中获取数据。
Native C++ PDB包含了如下的信息：
* public，private 和static函数地址；
* 全局变量的名字和地址；
* 参数和局部变量的名字和在堆栈的偏移量；
* class，structure 和数据的类型定义；
* Frame Pointer Omission 数据，用来在x86上的native堆栈的遍历；
* 源代码文件的名字和行数；
.NET PDB只包含了2部分信息:
* 源代码文件名字和行数；
* 和局部变量的名字；
* 所有的其他的数据都已经包含在了.NET Metadata中了；
三 PDB如何工作
当你加载一个模块到进程的地址空间的时候，debugger用2中信息来找到相应的PDB文件。第一个毫无疑问就是文件的名字，如果加载 zzz.dll,debugger则查找zzz.pdb文件。在文件名字相同的情况下debugger还通过嵌入到PDB和binay的GUID来确保 PDB和binay的真正的匹配。 所以即使没有任何的代码修改，昨天的binay和今天的PDB是不能匹配的。可以使用dempbin.exe来查看binary的GUID。
在VisualStudio中的modules窗口的symbol file列可以查看PDB的load顺序。第一个搜索的路径是binary所在的路径，如果不在binary所在的路径，则查找binary中hardcode记录的build目录，例如obj\debug\*.pdb, 如果以上两个路径都没有找到PDB，则根据symbol server的设置，在本地的symbol server的cache中查找，如果在本地的symbol server的cache中没有对应的PDB，则最后才到远程的symbol server中查找。通过上面的查找顺序我们可以看出为什么public build和private build的PDB查找不会冲突。
对于private build有时我们需要在别人的机器上debug的情况，需要将相应的PDB与binary一起拷贝，对于加入GAC的.NET的binary，需要将PDB文件拷贝到C:\Windows\assembly\GAC_MSIL\Example\1.0.0.0__682bc775ff82796a类似的binary所在的目录。另一个变通的方法是定义环境变量DEVPATH，从而代替使用命令GACUTIL将binary放入GAC中。在定义DEVPATH后，只需要将binary和PDB放到DEVPATH的路径，在DEVPATH下的binary相当于在GAC下。使用DEVPATH，首先需要创建目录且对当前build用户有写权限，然后创建环境变量DEVPATH且值为刚才创建的目录，然后在web.config，app.config或machine.config中开启development模式，启动对DEVPATH的使用
<configuration>
<runtime>
<developmentMode developerInstallation="true"/>
</runtime>
</configuration>
在你打开了development模式后，如果DEVPATH没有定义或路径不存在的话会导致程序启动时异常"Invalid value for registry"。而且如果在machine.config中开启DEVPATH的使用会影响其他的所有的程序，所以要慎重使用machine.config。
最后开发人员需要知道的是源代码信息是如何存储在PDB文件中的。对于public builds，在运行source indexing tool后，版本控制工具将代码存储到你设置的代码cache中。对于private builds，只是存储了PDB文件的全路径，例如在c:\foo下的源文件mycode.cpp，在pdb文件中存储的路径为c:\foo\mycode.cpp。对于private builds可以使用虚拟盘来增加PDB对绝对路径的依赖，例如可以使用subst.exe将源代码路径挂载为V:，在别人的机器上debug的时候也挂载V：。
DLL是Dynamic Link Library的缩写，意为动态链接库。在Windows中，许多应用程序并不是一个完整的可执行文件，它们被分割成一些相对独立的动态链接库，即DLL文件，放置于系统中。当我们执行某一个程序时，相应的DLL文件就会被调用。一个应用程序可有多个DLL文件，一个DLL文件也可能被几个应用程序所共用，这样的 DLL文件被称为共享DLL文件。DLL文件一般被存放在C:\Windows\System目录下动态链接库DLL(Dynamic Link Library)是一个可以被其它应用程序共享的程序模块，其中封装了一些可以被共享的例程和资源。动态链接库文件的扩展名一般是dll，它和可执行文件(exe)非常类似，区别在于DLL中虽然包含了可执行代码却不能单独执行，而应由Windows应用程序直接或间接调用。
动态链接库—优点
1. 共享代码、资源和数据
使用DLL的主要目的就是为了共享代码，DLL的代码可以被所有的Windows应用程序共享。
2. 隐藏实现的细节
DLL中的方法可以被应用程序访问，而应用程序并不知道这些方法的细节。
3. 拓展开发工具的功能
由于DLL是与语言无关的，因此可以创建一个DLL，被C++、VB或任何支持动态链接库的语言调用。这样如果一种语言存在不足，就可以通过访问另一种语言创建的DLL来弥补。
不管是不是有人会说老赵是“学术派”，“学术派”是不是适合“做项目”，我还是要强调事物的“概念”和描述一个问题的严谨性。我不认为在面试时回答“我都是在做实际项目，但是对于概念都不太关心”的人真有能力把项目做好。老赵觉得将一些事物的概念理清之后，有些推论自然而然就得出了，想要“误解”也很难。例如：“HTTP是无状态的 => 那么服务器端如果要知道当前请求用了哪个Session空间就要客户端告知了 => 客户端存储？那么SessionID应该是放在Cookie里的 => 禁用了Cookie还能不能用Session？除非有其他传递SessionID的方式，比如URL，否则就不能用”。数学是最为严谨的科学，各种定理和推论也全部是靠最基本的公理得出的——当然知道了公理能不能推出定理，这也需要相当的水平，因此我们也需要继续学习，锻炼这种“推理”的“思维能力”。所以老赵也不相信号称“做项目不需要懂数据结构”的朋友能够有较好的编程能力，能够应对“只有CURD逻辑”以外的应用程序……不多说了，进入我们的正题。
本来今天是在写一篇关于LINQ的文章，不过写着写着忽然觉得有些找不着北的感觉，似乎有点过于发散了？于是来博客园逛了一下，正好发现有朋友发了一篇文章《.NET面试题，看看你的水平》，于是就在这篇文章里和目前正红火的小包子同学为某个问题进行了一番争论。而在吵吵闹闹的过程中看到这么一句话“pdb文件需要放在Debug目录下才有效果”，忽然觉得有个话题值得一说：“开发环境与运行环境”。回想起平时被问到的问题，发现有不少朋友对于开发环境和运行环境并不是分的非常清楚。那么就让我们从标题中的问题开始：“csproj文件究竟是做什么用的”。
csproj文件大家应该不会陌生，那就是C#项目文件的扩展名，它是“C Sharp Project”的缩写。那么它究竟是给谁用的呢？那是给开发工具用的，例如我们在熟悉不过的Visual Studio，以及大家可以没有接触过，但是应该都听说过的MSBuild.exe。Visual Studio会根据csproj里的XML定义来管理项目文件以及相关其他一些种类非常丰富的数据及操作，MSBuild也会根据csproj文件来得知编译这个项目需要有哪些依赖，默认输出路径，Pre-Build和Post-Build需要哪些操作等等。Visual Studio和MSBuild都是开发工具，这就是csproj存在的唯一意义：为“开发环境”提供信息。而到了运行环境中，根本不会有人（操作系统？）关心所谓的csproj文件——也就是“程序是哪里来的”。
如果是个可执行程序，操作系统需要的只是exe，dll，甚至是配置文件或资源文件，而并非在开发中举足轻重的csproj，sln，dbproj等文件。而像IIS这样的运行环境，更加不会去关注csproj的影子：“csproj是什么？”IIS轻蔑地说，“我只听web.config的说法”。在运行环境中，csproj的辉煌不在——这是自然，你有办法向我们的IIS证明它使用的dll在开发期是由csproj，sln等文件来“统领”的吗？现在说到之前提到的“pdb文件需要放在Debug目录下才有效果”，其实不然。Debug目录只是VS的模板所“默认存在”的编译规则所生成的目录而已，我们在调试时使用pdb文件完全可以由VS指定pdb文件存在的目录——甚至我们根本不需要VS也能使用pdb文件。
说到了“模板”，这其实又是“开发环境”的概念。我们在VS中选择New Item或New Project时，可以在谈出窗口的左边找到模板的分类，而又边则是一堆可用的模板。这些模板是哪来的呢？自然是人为生成给VS用的，您不妨看看自己My Documents\Visual Studio 2008\Templates目录下是否存在一些zip文件，那就是存放“My Templates”的压缩包，感兴趣的朋友可以学习一下如何建立一个模板。而在“运行环境”下，更不会知道开发中用了什么模板。不知您是否提过这样的问题：“为什么Web Site中无法使用ASP.NET AJAX，而Web Application就可以？”现在您应该已经知道了，运行时期的问题和Web Site、Web Application与否没有任何关系。那么是如何产生这个问题的呢？看看您的Web.config？看看页面上提示了什么信息？用Fiddler看看请求的输出是什么？其实在很多时候“排错”并没有什么妙法，唯“仔细”二字。
而且事实上，“模板”在开发环境中的“地位”比csproj文件都要低，因为只要通过模板创建好内容之后，就无法说明结果和自己有什么联系了。例如我们使用模板创建一个AjaxControlToolkit的Extender，其中会生成一个.cs，一个.designer.cs和一个js文件——呵呵，谁还能证明这三个文件不是我们手动创建的呢？这就是“开发环境”，一切都是为了开发效率的提高，一切都是为了能够最终产生一个可执行的二进制文件。而在开发环境的最后一个成员“编译器”工作完成之后，所有开发工具便默默地退居二线。在产品环境的舞台上，最耀眼的一定不是我们的开发工具。
这就是“开发环境”与“运行环境”的宿命。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
