今天更新 Web App 程式時，發生了下面的錯誤：
An error occurred while creating the WebJob schedule: Could not load type 'Microsoft.IdentityModel.Clients.ActiveDirectory.ActiveDirectoryAuthenticationException' from assembly 'Microsoft.IdentityModel.Clients.ActiveDirectory, Version=2.16.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
什麼鬼東西。我明明參考的是 2.19 版啊？於是又將這個assembly 加入這個 WebJob，然後還是不行。
原來，只是在 VS2015 上的 Cloud Explorer 的帳密過期了，需要重敲。
這個錯誤訊息也太…
會犯這種錯，當然是錯誤的示範啦。
首先，我們使用了 TDD 的開發方式，所以先寫測試，再寫商業邏輯。此時，還沒有網頁的需求。
然後，再加上網頁後，遵循 Agile 的精神，對使用者重要的先寫，所以仍以商業需求為主。此時用的是 EF Code First + MemberShip Provider 做登入驗證。
當然，使用者對他要求的商業需求已經滿意了。最後使用者常見的非功能需求，「要求登入失敗多次後，鎖定帳號 5分鐘」這種安全性的需求時，我們早就準備好了 ASP.NET identity (傳著等)。
等等！竟然鎖定機制失效了！故意打入正確帳號但錯誤的密碼，只見 AccessFailedCount 完全不聽使喚，全然不會遞增。
因為我們之前已經有自訂的 ApplicationUser 類別，而類別中已有 Email 屬性。而最後為了使用 ASP.NET Identity，自然地會將我們自訂的 ApplicationUser 類別繼承 IdentityUser.
此時，ApplicationUser 如下圖
看起來沒什麼狀況吧。咦？Email 屬性下有一點小波浪？反正是 Warning，應該不會有什麼問題。
就這個念題，讓我浪費了半天的好光陰.
仔細看一下提示訊息，the keyword ‘new’ is required on ‘Email’ because ….，這個意指著在 c# 中，如同上面的程式碼，代表著「身為 ApplicationUser 的 Email 與身為 IdentityUser 的Email 是不相同屬性」, 見下面的單元測試。這是dotnet framework 較為特殊的地方。而這個地方將導致 ASP.NET Identity Lockout 機制失敗。
只需要簡單地在ApplicationUser 將重複的 Email 屬性移除, 或者加上 override 指示詞就解決了這個看來完全不相干的問題。
要發生我遇到的狀況，其實很簡單。建立一個MVC新專案，找到 ApplicationUser，再加上那個沒有 override 的 Email 屬性，就可以還原我碰到的問題了。
這代表著：連 warning 都不可以忽略！
現在因為 SSL 3.0 的弱點關係，Azure 上的PaaS 將全面停用 SSL 3.0 (見
但是自建的 Virtual Machine，不管是自己機房的還是 Azure，都需要自行管理。
因此，建議大家也需要關閉 SSL 3.0
執行的做法如下連結
https://technet.microsoft.com/en-us/library/security/3009008.aspx
