不管是不是有人會說老趙是“學術派”，“學術派”是不是適合“做項目”，我還是要強調事物的“概念”和描述一個問題的嚴謹性。我不認為在面試時回答“我都是在做實際項目，但是對于概念都不太關心”的人真有能力把項目做好。老趙覺得將一些事物的概念理清之后，有些推論自然而然就得出了，想要“誤解”也很難。例如：“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文件——呵呵，誰還能證明這三個文件不是我們手動創建的呢？這就是“開發環境”，一切都是為了開發效率的提高，一切都是為了能夠最終產生一個可執行的二進制文件。而在開發環境的最后一個成員“編譯器”工作完成之后，所有開發工具便默默地退居二線。在產品環境的舞臺上，最耀眼的一定不是我們的開發工具。

　　這就是“開發環境”與“運行環境”的宿命。