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，該是時候準備換掉了...
Hangfire 是一款個人認為相當不錯的非同部步服務器，它脫離 Windows 工作排程，在 Web 檢視、重送任務，在 Hangfire 操作 UI 介面可以知道你指派給它的任務狀態，何時成功？為什麼失敗？(例外捕捉)下一次任務觸發時間？訊息可說是相當的完整。不過有點可惜的是，預設 Hangfire 操作介面沒有手動觸發任務的介面，幸好 Hangfire.Dashboard.Management 彌補了這個不足...
延伸閱讀
當需要在用戶端建構 REST API，目標只能是.NET Framework 4 時，我們可以選擇 Web API 1，搭配 Self-Host 自我掛載在 Console App，再加上 Topshelf 就可以輕易的把 Console App 變成 Windows Service。
這篇沒有太多的 Web API 的建立方式，主要是筆記一下 Self Host 的使用方式。