本來以為項目結項，皆大歡喜，沒想到到最后自動提醒居然不好使了，而且還找不到原因。
上學的時候學習global的時候沒遇到這個問題，所以不知道出現在什么地方，檢查代碼沒有發現任何問題。定時是每天的中午12點和晚上12點進行一次執行。可惜人算不如機器算。
第一天沒執行。。重啟IIS，執行。好吧，只能等第二天在去測試晚上12點的執行情況。第二天上班一看。。沒執行。
當時的分析是，線程可能睡死了（當時怎么就沒意識到睡死的概念）。剪短時間間隔。為了檢測是不是代碼引起的問題，1分鍾執行一次。檢測出來了，代碼的確拋出異常。之前自己的檢查的時候沒有發現。好吧改掉之后。繼續執行，一切OK。
改為1小時一次，坐等一小時，並且去找一些關於global的配置問題，但是無果。檢查到也有不執行的，但是說的是沒給權限的問題，我覺得這個東西和權限沒有什么太大的關系，所以也就是做嘗試的給IIS加上而已。
當然答案是肯定的，對於結果沒有任何改變，本機測試1小時沒問題。好吧。應該沒問題了，提交上去，再次發布。第一小時，執行了一次。我覺得問題被找到了，測試人員告訴我，數據刪除再次測試。結果第二次應該執行的時候沒有執行。
當時百思不得其解，因為為了避免線程不好操控，是用了輕量級的timer。但是沒想到這么不靠譜。執行一次就停止了。有點坑啊。
當時覺得他是消散了（還沒意識到錯誤在眼前二次經過），那把timer定義成public的吧。我看你怎么消失，順便在給你加個static。
好吧。加完之后測試1分鍾的。沒問題
測試10分鍾的沒問題。
測試1小時的。消失了。。。
而且是在本地消失的，不理解他的消散原因。因為壓根就沒執行。錯誤到底在哪呢？
一宿的糾結，導致失眠第二天沒有什么精神並且頭疼。打開電腦第一件事就是找問題。但是很可惜沒有任何思緒，這個問題我也跟我的群說了，他們建議我加日志。考慮再三我加上了日志，在去執行。根據日志反饋的情況來看他是突然消失的。並沒有征兆。具體來說就是當Application_Start事件執行結束后，timer的委托時間並沒有執行。
那只能用笨方法來測了，調成執行時間是1分鍾。一切正常。10分鍾也正常。半個小時。中午休息一下，打了一盤三國殺。下午在看結果，沒有運行。沒想到這個破問題糾結了我一上午。這時候群里有人說可能是被IIS回收了。抱着試試看的態度在百度上搜索了一下 IIS global 回收 這三個關鍵字。果真搜索出答案了。
但是我不敢確信這個答案是否是正確並且針對我的程序，所以我在Application_End寫了日志，如果進入這里則記錄一下。程序還是半小時的。結果很明顯。程序啟動成功，21分鍾之后程序結束。
21分鍾。這能做啥呢。我把我的程序修改成15分鍾執行。
執行一次。等待第二次的時候到達21分鍾 程序結束。一切都被Dispose。
在去看百度的文章，大意思“Asp.Net 應用程序會不定時的關閉，這個時間間隔大約為 1~5 個小時一次。”其實這個結果並適合我，因為這個間隔是21分鍾。也就是說他的應用程序池自動關閉的時間不是可以掌控的，那么現在就有幾個解決方案
1.修改IIS的垃圾回收時間，並且做回收之后的Application_Start在起事件。（http://blog.csdn.net/orain/article/details/4589984）
2.修改運行時間的間隔（已經被PASS了，因為無論怎么運行最后都被回收）
3.讓網站一直被訪問狀態。在Application_Start做手腳。
4.寫windows 服務
考慮再三直接寫windows服務吧。因為那篇文章也說道了對於這種長時間的自動程序寫windows服務是最適合不過的。IIS的不可控因素實在太多了。
開始寫windows服務，因為之前的網站代碼都是封裝在類庫里面的，我本想把動態類庫倒動過來引用調用方法就OK了。沒想到。引用直接出錯。我表示精神不振的我。崩潰了，三觀倒塌了。但是要淡定。根據警告的信息百度了一下，原來windows服務和asp.net應用程序的默認框架集是不一樣的。而是在net framework4.0上有兩種（我的電腦沒有沒法截圖）
調整框架集在生成一切都成功。但是添加到服務里面運行后停止。。自動停止。好吧在使出山寨日志寫法。BLL層的引用方法的時候異常沒有拋出而是直接結束了。windows服務你是有多么的脆弱。
這時候頭疼的不行，把類庫復制過來引用上吧。結果還是有問題。好吧三層架構的確不適合你了。一層來吧。東弄弄西弄弄。還是不行。到底是什么地方出錯了。領導給我看了一個以前公司寫的windows調用公司的組件項目。原來是App.Config里面還差一句話。providerName="System.Data.SqlClient" （驅動） 但是在asp.net項目中並沒有用到這句話。看來我是長時間做web項目做傻了。
服務起來了。但是數據庫沒有變化。好吧，我忍了了，因為我知道windows服務的調試必須基於服務運行起來，或者使用windbg，但是后者沒用過啊。而且還不好找他的安裝包，屬於windows sdk的一種。
運行成功了那就來調試下吧。。
數據庫他喵的誰改什么了。。。為什么字段是必填的。。。。
最后運行成功了。心理留下了陰影反復的問不能被回收吧。。
把幾個方法都寫好，也到下班點了。沒有做最后一次測試。星期一在去測試吧。
最后總結出來幾點。
在設計項目的最初一定要考慮回收的問題，因為在.net的的世界回收是不需要人為操控的（IIS屬於.net范圍么？）所以不考慮內存的問題。
其次做web項目必須要考慮你做的自動是否是屬於那種長時間的自動程序。要考慮IIS的回收，最后也是最重要的一點就是要設計日志，這個日志是系統日志，因為這個日志可以幫助未來的維護人員來進行科學的快速的維護，減少開發人員和維護人員不必要的時間支出。如果最初就考慮了日志的話也許問題曝光時間就會長一些解決辦法會多一些。
在使用不同程序的時候發現dll的使用發生不正確，最好檢查一下兩個程序的框架集是不是同一個（項目類庫右鍵屬性就能看到）
因為框架集不同IDE認為你是錯誤的使用。其實這個問題應該大多數出在不同的IDE版本之間的dll使用，我這事偶然碰上。
最后就是關於 global的。他的編譯是動態編譯，應該是在IIS運行的時候才進行編譯。global的編譯出來的dll並不存在在任何的dll里面（我個人認為沒有經過IL的檢驗）網上說會生成一個global.dll但是我沒有發現，后來嘗試按照web網站的寫法寫，把后置的CS代碼放入到他的頁面。因為在net編譯的時候前置頁面頁面並不編譯，只是把所有cs文件打包。
還有就是自己的意識和代碼質量需要提高。端正心態。最初意識到消散，但是沒有去尋找原因，二次消失也沒有去找。只有到最后通過別人知道他的消失與垃圾回收有關。
並且更深的認識到 asp.net並不是萬能的。很多東西還是需要使用CS程序來進行實現更靠譜，畢竟IIS不是我們這群人開發的，當然可以嘗試開發一個IIS。。
有一個經驗老道的團隊是很重要的。出現問題至少能請教別人。我是自己硬生生摳出來的。
當然有寫的不對的地方請各位高手指點，畢竟新手還是需要磨練的！~
我也臭不要臉的發布到首頁。。。。嘿嘿。
群：59557329 希望高手進來指點一二