|
|
其實并非我們不看重這些新手的能力，事實上很多時候，他們的技術(shù)水平和編程能力非常非常的高，所以我們是害怕他們創(chuàng)新的力量，記憶中無數(shù)次了，經(jīng)常是新來的人一臉委屈的解釋說，"我什么也沒做"，不過結(jié)果有時是災難的，比如VSS的某個項目文件被莫名破壞了，DailyBuild莫名中斷了，一個運行很穩(wěn)定的模塊突然出現(xiàn)奇怪的Bug。甚至是一秒鐘前還能正常運行的程序，突然不能運行了。
那些所謂的老鳥，往往蒙頭大干很久，才發(fā)現(xiàn)原來原來，某個地方被小小修改了一下，而往往這種修改是這樣的機緣巧合。而更多的時候，這些老鳥，把這個問題程序化的變成了運氣說，運氣好，你能解決這個問題，運氣更好一點，你還能找到原因。
這兩天我們Team的一個老鳥就碰到了這樣的問題，ASP.NET的項目突然在一個新來的開發(fā)人員的機器上報下面的錯誤，老鳥又看到了委屈而無畏的神情---對方的潛意識在說，"我什么也沒做，一分鐘前還好好的，突然就這樣了"
錯誤信息：
CS0016 : 未能寫入輸出文件
C:/Windows/Microsoft.NET/Framework/V1.1.4322/Temporary ASP.NET File/logtest/ae3a7b05/21b60d47/kxxnk5bg.dll --拒絕訪問
然后老鳥接著做了很多嘗試
關(guān)閉索引服務 --結(jié)果錯誤依舊！
重新啟動機器 ----結(jié)果錯誤依舊！
使用 ASPNET_regiis.exe 重新注冊一下----結(jié)果錯誤依舊！
修改NETwork Services在Temporary ASP.NET File目錄下的權(quán)限到最高----結(jié)果錯誤依舊！
修改IIS Application Pool 的啟動用戶為系統(tǒng)用戶 ---成功
-----看來是NETwork Service 用戶的權(quán)限問題，總算有了方向 找到了FileMon
10秒鐘發(fā)現(xiàn)了問題，原來NETwork Services 不能存取系統(tǒng)目錄的Temp目錄
ASP.NET 會使用這個目錄做編譯嗎？ 但修改NETwork Services帳戶對Temp目錄的權(quán)限之后，問題解決了。
老鳥自己也很奇怪，ASP.NET為什么會使用Temp目錄做某一個文件的即時編譯？ 第二，為什么剛剛還沒有問題的機器，突然需要做這樣的權(quán)限設置？
吃飯的時候，如果有酒，我們差點一起敬他一杯，因為---他的運氣不錯!
AspNet技術(shù)：看到本質(zhì)而不是現(xiàn)象--解決ASP.NET CS0016的問題，轉(zhuǎn)載需保留來源！
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。
