csproj文件的用途

原文地址：csproj文件的用途 作者：何静

  

文章来源：老赵博客 不管是不是有人会说老赵是“学术派”，“学术派”是不是适合“做项目”，我还是要强调事物的“概念”和描述一个问题的严谨性。我不认为在面试时回答“我都是在做实际项目，但是对于概念都不太关心”的人真有能力把项目做好。老赵觉得将一些事物的概念理清之后，有些推论自然而然就得出了，想要“误解”也很难。例如：“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 DocumentsVisual Studio 2008Templates目录下是否存在一些zip文件，那就是存放“My Templates”的压缩包，感兴趣的朋友可以学习一下如何建立一个模板。而在“运行环境”下，更不会知道开发中用了什么模板。不知您是否提过这样的问题：“为什么Web Site中无法使用ASP.NET AJAX，而Web Application就可以？”现在您应该已经知道了，运行时期的问题和Web Site、Web Application与否没有任何关系。那么是如何产生这个问题的呢？看看您的Web.config？看看页面上提示了什么信息？用Fiddler看看请求的输出是什么？其实在很多时候“排错”并没有什么妙法，唯“仔细”二字。 而且事实上，“模板”在开发环境中的“地位”比csproj文件都要低，因为只要通过模板创建好内容之后，就无法说明结果和自己有什么联系了。例如我们使用模板创建一个AjaxControlToolkit的Extender，其中会生成一个.cs，一个.designer.cs和一个js文件——呵呵，谁还能证明这三个文件不是我们手动创建的呢？这就是“开发环境”，一切都是为了开发效率的提高，一切都是为了能够最终产生一个可执行的二进制文件。而在开发环境的最后一个成员“编译器”工作完成之后，所有开发工具便默默地退居二线。在产品环境的舞台上，最耀眼的一定不是我们的开发工具。 这就是“开发环境”与“运行环境”的宿命。