公司內部的一個網站，Aspx的，最近莫名其妙的出現一個問題：
file 'soLog.aspx' has not been pre-compiled,and cannot be requested.
這個問題只有在網站發布到服務器之后才會出現，本地一切正常，但不是每一個頁面都有這一個問題，部分頁面可以正常使用，於是把本地的網頁重新編譯之后再次發布到服務器，結果還是不行，一會兒是頁面A有這個問題，一會兒是頁面B有這個問題，網上都說是由於少了一些DLL文件或者是沒有引用的緣故，可是我項目里面根本都沒有用到什么第三方控件，都是MS自帶的東西；於是我把服務器上面虛擬目錄里面的Bin文件全部干掉，然后我重新發布項目，悲催的是問題依舊。
仔細檢查了服務器上面的虛擬目錄，發現Bin里面有一些這樣的文件“頁面名稱.aspx.cdcab7d2.compiled”，每一個頁面對應這么一個文件，猜想應該是發布網站之后生成的編譯文件，是不是這個文件引起異常的呢？不試一下也不知道，於是我在發布網站的時候勾選了“允許更新此編譯站點”的選項，如下圖:
然后重新編譯，重新發布網站，依然是將服務器上面所有的Bin文件全部殺掉，發布之后發現沒有aspx.cdcab7d2.compiled這種文件了，為了防止出現其它的異常，我把應用程序池重啟了一下，刷新頁面，意想不到的結果出來了----OK了。難道真的是這個原因嗎？
但是這樣做也有問題，如果勾選了“允許更新此編譯站點”的選項，那么發布的網站安全性非常差，除了所有的CS文件編譯成為一個DLL文件之外，其它的文件和原來的沒有任何變化，原來是什么現在就是什么，通過記事本打開可以看到里面的代碼以及HTML代碼等，我們可以將兩個文件打開互相比較一下，
這個文件是以“不允許更新此編譯站點”的方式發布之后的：
這個文件是以“允許更新此編譯站點”的方式發布之后的：
兩者的區別顯而易見，以“允許更新此編譯站點”的方式發布之后網站的安全無法保障，另外效率也會比較低，虛擬目錄里面的.aspx.cdcab7d2.compiled文件也都沒有了，也就是沒有預編譯，沒有預先生成，每次需要的時候臨時編譯頁面，訪問第一次會很慢，但是第二次...第三次...就很快了。但是我測試了很多次這種做法確實可以解決“file 'soLog.aspx' has not been pre-compiled,and cannot be requested.”的問題，這種方式確實有很多的隱患，偶爾臨時用一下以解燃眉之急。