Global Error Handler 有很多的方式，這次來介紹 System.Web.Http.Filters.ExceptionFilterAttribute，用它集中管理應用程式的例外，不需要在每一個動作包裝錯誤，你可以針對不同的例外進行處理，比如，有專門的 Filter 處理交易例外
ASP.NET 的 Request 物件的生命週期很短，只會出現在一個 Http Request，當需要跨物件傳遞資料時，比如 HttpModule、HttpHandler、Page 、Controller，可以善用 Request 物件來存放短暫的狀態。
既然可以傳遞物件，那麼我們也可以在 Request 初始化的時候，將所需要的物件注入至 Request 裡面，然後再到到 Page / Controller 取出來用；在不同的專案範本可以使用的 Request 物件都不太一樣，接下來分享我已經知道的寫法。
Web API 的 ExceptionFilterAttribute、IExceptionFilter 能幫我們處理應用程式等級的例外，但無法處理載體 (Host) 的例外，當使用 IIS 作為載體，假使發生未處理的例外時會出現黃頁，OWIN 作為載體時，ExceptionFilterAttribute、IExceptionFilter 卻攔截不到錯誤，此時應該改用 Microsoft.Owin.Diagnostics.IAppBuilder.UseErrorPage 擴充方法，接下來將會利用 Error Handler 這個情境，介紹 OWIN Middleware 的幾種使用方式。
.NET Core 跟以往 .NET Framework 存取組態設定檔有很大的不一樣，概略的比較如下：
這裡就著重在 .NET Core 的組態設定
最近有人問到一個老骨董 .NET Remoting，當需要跨程式資料交換，它是一個選項
Wiki 這樣介紹它
以下內容出自：https://zh.wikipedia.org/zh-tw/.NET_Remoting
『.NET遠端處理[1]（.NET Remoting ）是微軟 .NET Framework 中的一種網路通訊技術，與 XML Web Service 不同的是，它可以使用 SOAP 以外的協定來通訊，而在伺服端和用戶端之間所操作的方法近乎相同，用戶端可以不必考慮使用的協定，即可存取伺服端所開放的物件。這個技術與是由 Distributed COM所發展而來的，與DCOM最大的不同是，DCOM有限制使用 TCP Port，但.NET Remoting 可以選擇使用 TCP 或 HTTP 的方式通訊，而資料可以利用 SOAP 或二進位傳輸方式在網路上流動，二進位的傳輸效能是 SOAP 所不能比的，但 SOAP 卻可以得到和 Web Service 相互溝通的能力，因此 .NET Remoting 的設計彈性較大。』
如果可以，應避免使用「註解/反註」解來切換設定。
預設 ，Transform 在 Web.config 執行部署才會觸發 Config 轉換，當開發人員需要在 VS IDE 除錯模式 (F5 /Ctrl+F5) 下切換設定時，卻無法套用切換設定，這時，可以透過 MsBuild 的 Task 來處理https://docs.microsoft.com/en-us/visualstudio/msbuild/how-to-extend-the-visual-studio-build-process?view=vs-2015&redirectedfrom=MSDN
當需要雙向及時通訊，SingalR 則是我的選項之一，它算是非常容易上手的框架。
小朱前輩寫了一些基礎概念的文章，有興趣的可以前往看一下：
https://www.dotblogs.com.tw/regionbbs/Search?q=signalr
之前有寫過用 Web API 2 整合 JWT [ASP.NET Web API] 實作 System.IdentityModel.Tokens.Jwt 進行身分驗證，到了 ASP.NET Core 之後，用法沒有太大變化，不過我個人認為驗證的注入設定可讀性變的更高了...
ASP.NET Core 預設似乎沒有提供 Basic Authentication 的 DI，但仍然可以自行實作 AuthenticationHandler
我在 .NET 用過 Swashbuckle(已停止更新)、Swagger-NET(fork Swashbuckle)，在 .NET Core，已經不適用了，同時支援 ASP.NET Core 及 OWIN Middleware，通吃 .NET Framework 與 .NET Core 版本的 WebAPI，該是時候準備換掉了...