本來今天是在寫一篇關於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檔案。
而且事實上，「模板」在開發環境中的「地位」比csproj檔案都要低，因為只要通過模板建立好內容之後，就無法說明結果和自己有什麼聯絡了。例如我們使用模板建立乙個ajaxcontroltoolkit的extender，其中會生成乙個.cs，乙個.designer.cs和乙個js檔案——呵呵，誰還能證明這三個檔案不是我們手動建立的呢？這就是「開發環境」，一切都是為了開發效率的提高，一切都是為了能夠最終產生乙個可執行的二進位制檔案。而在開發環境的最後乙個成員「編譯器」工作完成之後，所有開發工具便默默地退居二線。在產品環境的舞台上，最耀眼的一定不是我們的開發工具。
這就是「開發環境」與「執行環境」的宿命。
DayTen 依舊是筆記呀
c 中讀取一整行資料時，可以採用string類庫中的getline 函式 具體使用 getline cin，str 這樣讀入的資料就是包含輸入的空格，方便後續的操作。以下這一點 可以將輸入的字元按空格分割放入棧中 stack stk string str getline cin,str string...
HDFS依舊是儲存的王者
讓我們帶著這個問題來了解hdfs的架構與原理，我一直認為學習大資料最好的方法就是看官網。所以對初學者來說一定要多看官網，哪怕你看不懂英文，也要用軟體翻譯過來看。首先來看下官方介紹 hadoop分布式檔案系統 hdfs 是一種分布式檔案系統，設計用於在商用硬體上執行。它與現有的分布式檔案系統有許多相似...
見微知著 依舊是矩陣乘法演算法！
博主上大二了，接觸linux自我認為還是乙個有小小追求的人，覺得一直漂浮在上層沒有根基，於是還是想看看linux核心，便重新看是看pointers on c紮實c語言基礎。不再急功近利，不再認為看完書就學到了知識，實踐出真知，自己動手才是王道。不多說，就用乙個以前我寫過的例子嘲諷以前的我吧！還是一樣...