當你運作一段代碼、一個軟體，在運作時你發現：debug下正常， release下f5運作也正常，唯獨release編繹後單獨運作異常，你會怎麼想？
這個問題對我而言，腦海裡不曾有過，于是蛋定思蛋，先百度了一下：發現網上資訊并不多，偶爾幾條也是vc++的，對于c#的，絕無僅無。
當我把代碼發給一友人，讓他也幫忙試下時，發現對方的win7 64位竟然運作正常，靈異性又提升了一個等級。
面對這神一般的靈異bug，我費了n個小時折騰，找一個不能調試的bug，因為f5下都是正常的，那個辛苦啊。
靈異現象已經說了，那靈異點是什麼呢？标題已經出賣了這個問題，和aop的realproxy有關。
光說aop，園子裡懂的人不多，用的估計也不多，是以深入無謂，淺出又難，隻好簡單過過場。
我是怎麼發現問題是在aop realproxy?
這個使用正常方法，在代碼段裡插一些彈出資訊，來縮小出錯的代碼片斷，最終找到了它。
為了減少廢話，這裡直接講述兩點：
1：哪些代碼有問題，哪裡有問題？
這裡給出詳細的錯誤代碼，和注釋錯誤點，代碼通常都有點長，不容易看：
view code
通常大量的代碼測試及分析方法，我發現了，隻要aop對象涉及到内部成員變量，在release編繹後運作就一定會報錯。
2：如何解決。
在曆經各種無解後，我發現了，realproxy還有另一種寫法，而這另一種寫法，竟然可以解決這個問題，代碼如下：
3：debug和release還有f5，究竟隐藏怎樣的秘密？
我也不懂，這涉及更底層的問題，不在我深究的範圍内，懂的人士可以留言給大夥解答下。
總結：
在程式設計的世界裡，靈異總是無處不在的，但是找它靈異的原因，并且能找到一種解決這類事件的方法，是每個代碼建造師必須具有能力。
至于為何會産生這樣那樣的靈異事件，在研究的範圍内，可以追究原因，在非自身研究的領域，大夥看着辦了。