今天更新 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
今天在調整校能的時候，想到可以使用非同步的方式來增加網站的校能。
就拿 Log 來試試身手好了。
真的是這樣，見 ActionFilterAttribute, 果然沒有像 WebAPI 上的 ActionFilterAttribute 的OnActionExecutedAsync 方法。
怎麼辦呢？
異相天開地找了一段如下的程式 (https://aspnetwebstack.codeplex.com/discussions/478983)，既然被標為解答，大概就可以運作了吧！
Task.Factory.StartNew(() => Logger.WriteLogAsync(log), TaskCreationOptions.LongRunning);
想法是：自己使用多執行緒的方式寫 log.
結果還不錯，而且單頁測試時，效能還快了將近10%呢？
想說單頁沒問題，應該就沒問題了呢？於是就送出去測試來。
這個效能測試是正式的首頁，測個10分鐘，效能變差也就算了，竟然還會出現 502 Bad GetWays？然後網站就掛了。
ASP.NET MVC 5 的ActionFilterAttribute 不支援 async/await，看來是有道理的。
印象中，ASP.NET 有這個規定：不要在頁面中自己產生新的執行緒。我不信邪，就只能撞撞牆，練練經驗了。
不要自己找麻煩。
一直以來，對 Azure Web Site 深懷無比的信心，因為它部署程式非常的快，無比的方便。因此，只要能力所及，就會推銷此方法來實作網站。
沒想到，上個星期部署網站失敗了。錯誤畫面如下。
試了幾下，將網站重起後，就可以繼續部署了。真是奇怪！
今天，同事又回報相同的狀況發生，而且，上面的招數沒用了。
於是，更進階的招數來囉！將網站刪除，然後重建，心想我都重建了，應該會有效果吧！
天不從人願！就跟薪水一樣不聽使喚。
找微軟吧！沒有技術支援點數，不鳥我！給了我 forum 自行發問吧。
微軟的論譠真的是有用的。於是找到了這一篇
http://azure.microsoft.com/blog/2014/06/30/web-deploy-as-a-site-extension/
原來，網站有新的部署方法，使用了 {yourwebsite}.scm.azurewebsites.net 來部署。就使用舊的部署端點來發行程式吧！
在Azure Portal 上，將該網站加上一個設定 WEBSITE_WEBDEPLOY_USE_SCM = false 後，記得按儲存
接下來下載發行設定檔，再使用這個發行設定檔，在Visual Studio 中發行！
萬歲！
(??) 我發現只有這個訂閱所建立的網站會這樣，即使建立新的網站也無法發行。但其他的訂閱就可以？到目前仍不明所以。
公司同事離職了，TFS上仍然是簽出的。如果是文字檔的話那還好，因為可以同時簽出，不會因為該檔案被簽出而被鎖住無法簽入。但 *.rdlc 就是一個例子。明明是文字檔，但tfs 不知道，只能以 binary 檔案來處理。
以下是我找出來的指令， tfs server url 自行置換
查詢所有的 workspaces
tf workspaces /collection:http://tfsserver:8080/tfs/defaultcollection /owner:*
刪除指定的 workspace
tf workspace /delete workspaceName;account /server:http://tfsserver:8080/tfs/defaultcollection
