ref:
https://jhxk.iteye.com/blog/471906
https://blog.darkthread.net/blog/misleading-error-msg-of-precompiled-web/
http://tomex.dabutek.com/2014/09/aspnet-globalasax.html
https://stackoverflow.com/questions/6508415/application-error-not-firing-when-customerrors-on

application_error not firing when customerrors on:
Summary:
Remove the line: filters.Add(new HandleErrorAttribute());
Use Application_Error() method to log exceptions
Use customErrors with a ResponseRewrite, pointing at ASPX pages
Make the ASPX pages responsible for their own response status codes
There are a couple downsides I have noticed with this solution.
The ASPX pages can't share any markup with Razor templates, I had to rewrite our website's standard header and footer markup for a consistent look and feel.
The *.aspx pages can be accessed directly by hitting their URLs
There are work-arounds for these problems but I wasn't concerned enough by them to do any extra work.



Gloalbal.asax(以下簡稱G檔)是ASP.NET站台在IIS中最先啟動執行的檔案，它的Application_Start(), Session_Start()可以應用在線上瀏覽人數統計等相關應用上，從ASP.NET 2.0以後我都有使用它，歷經很多網站架構的改朝換代，直到使用ASP.NET 4.0之後突然發現其檔案內的Event都沒被突發。網上搜尋的可能方法都試過N遍了，最後才歸納出一些結果。以下研究是以ASP.NET 4.0為例，架構在WIN2008R2 + IIS 7.5下，更舊.NET版本就不在本文研究範疇了。

當站台要發佈Release到正式主機時，通常我們會在Publish介面把各頁面的源碼編譯成一個Main DLL檔，除了能保護源碼及方便Copy佈署簡單外，頁面載入速度更快(因為CodeFile方式的自動編譯碼似乎會在某時間後被Recycle回收)。以下是以Single Assembly的發佈方式(編號1)，而編號2主要的差別是把App_Code下的類別獨立成一個App_Code.dll而己。我個人偏好第一種方式，因為Library會以另外的專案加入，App_Code/下通常只放與專案UI連動的相關函式庫而己。

Publish前，若根目錄下的G檔存在(未被Excluded)，它就會被編譯入主要的輸出DLL內，因此Deploy根目錄下不會出現G檔，並會自動產生「/Bin/App_global.asax.compiled」標示檔。因此，若想讓User日後能修改G檔源碼，記得先把Global.asax遮蔽(Exclude)再Publish，這樣產生的Main DLL就不會含有G檔編譯碼，接著手動將Global.asax複製至Deploy根目錄下，並移除或更名「/PrecompiledApp.config」及「/Bin/App_global.asax.compiled」兩個檔案。
根目錄之「PrecompiledApp.config」標示檔案，它的存在是告訴ASP.NET優先執行Main DLL下的編譯碼版本, 而非最新動態自動編譯的版本(若頁面使用CodeFile即時源碼編譯，則優先執行不受該檔存在與否影響)。因此要手動執行G檔源碼事件，PrecompiledApp.config必須移除或更名，否則會被Main DLL取代(假如它不含有G檔編譯)而不執行了。
最後，了解在Publish相關概念及差異後，若發現站台的G檔事件未能正確執行，也許它因為編譯方式及2個標示檔的存在與否，讓Main DLL檔給Override蓋掉了。



application_error無作用:
Remove precompiledapp.config from your root and bulid agian .

佈署有問題時, 先部署非先行編譯的版本, 才能看出錯誤...
  publish選項中: (不選擇 Allow this precompiled site to be updatable.), 預設為勾選.
  建議 File Publish Options: (完全覆蓋更新模式:)
    1. 勾選 Delete all existing files prior to publish.
	2. 勾選 Precompile during publishing, 
	     再點選 Configure, 將(預設為勾選Allow this precompiled site to be updatable), 改為不勾選
    3. 不勾選 Exclude files from the App_Data folder.
  

It's a false error, indicative of a specific assembly it cannot load. To give you the specific one(s) it is having trouble with, clear out the entire compiled version and deploy your uncompiled code instead. Launch it and you should get the lovely yellow and white Server Error page telling you exactly what assembly it can't load. Figure out how to get that assembly loaded and repeat. Once your site comes up completely then wipe out the uncompiled version and replace with the precompiled version and you are all set."
意思是，這是個誤導效果十足的錯誤訊息，真正的錯誤可能源於該網頁執行時無法載入必要的組件，建議的解決方式是先部署非先行編譯的版本到該主機上，再執行同一網頁。此時應可看到一般的ASP.NET錯誤訊息回報，指出是哪顆DLL載入發生問題，排除後再重上預先編譯版本。在本案例中，使用前述做法，也真的找到了錯誤根源，網頁用了某個舊版DLL版本才有的方法，排除後問題即告解除


Sample PrecompiledApp.config 內容:
<precompiledApp version="2" updatable="true"/>

ASP.NET2.0的编译功能。预编译有三种方式 
一、允许更新UI预编译 
     也就是只编译cs的文件，像aspx的页面文件是不编译的。 
二、不允许更新UI预编译 
     也就是编译的时候不止编译cs文件连aspx页面文件和主题文件都编译。当然web.config配置文件和图片了什么的是不编译的。 
三、强命名预编译 
     这个不止编译源文件而且对编译后的文件进行强命名，这样他们不能随便替换你的dll文件。 
     完成这个模块时我首先考虑前两种，因为用第三种有点小题大做故作高深之意。我就在前两种中徘徊，于是我就一直反复的测试前两种方法编译后的文件在客户的开发中配合整体测试的便捷性。我想给客户最少最简单的文件，所以在做第二种方法的单独测试中，我删除了PrecompiledApp.config文件，然后让IIS目录指向编译后的文件，结果显示“这是预编译工具生成的标记文件，不应被删除!”于是我就把PrecompiledApp.config文件加上，结果才能正常显示。其实在发现是PrecompiledApp.config的影响的时候并不这么简单因为IIS有缓存，这个过程中你必须重启IIS。最后一查才知道该文件是一个标记，它通知ASP.NET运行库该应用程序已经被预编译，所以没有他用第二种方法程序是不能正常显示的。