扩展名：csproj

作用

“csproj文件究竟是做什么用的”

csproj文件 是“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文件——呵呵，谁还能证明这三个文件不是我们手动创建的呢？这就是“开发环境”，一切都是为了开发效率的提高，一切都是为了能够最终产生一个可执行的二进制文件。而在开发环境的最后一个成员“编译器”工作完成之后，所有开发工具便默默地退居二线。