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 的幾種使用方式。
當需要用 Console App / WinForm給其他應用程式呼叫時，比如工作排程，會需要分析調用端傳過來的參數。
PowserArgs 除了能分析參數並轉成強型別之外，還能生成詳細的說明文件，只需要定義幾個 Attribute 就能完成，真的是令我驚艷阿
.NET Core 跟以往 .NET Framework 存取組態設定檔有很大的不一樣，概略的比較如下：
這裡就著重在 .NET Core 的組態設定
有天跟同事結對開發的時候，發現 EF6 新增後，會多一個 IDENTITY 欄位的查詢，經研究後發現這個是 EF 6 的特性，觀察了一下 EF 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 的設計彈性較大。』
當需要雙向及時通訊，SingalR 則是我的選項之一，它算是非常容易上手的框架。
小朱前輩寫了一些基礎概念的文章，有興趣的可以前往看一下：
https://www.dotblogs.com.tw/regionbbs/Search?q=signalr
CEF 的全名是 Chromium Embedded Framework，是用於嵌入 Chromium 瀏覽器的簡單框架，用 C++/CLI 開發
CefSharp 是在 .NET 平台封裝了 CEF，可以使用 C# / VB 語言開發
Winform 桌面應用程式要做出酷炫的畫面門檻相當的高，反觀當前的網頁技術發展的相當蓬勃，酷炫的畫面相當的多，CefSharp 可以讓我們嵌入 Chromium，輕鬆的使用前端技術，UI 的開發團隊，只要完成一個設計就可以同時給桌面應用程式和網站使用。
前端語言怎麼跟 C# 溝通？JavaScript + Handler 直接整合 C# 或者 JavaScript + Web API OWIN，這兩種方式都可以
之前有寫過用 Web API 2 整合 JWT [ASP.NET Web API] 實作 System.IdentityModel.Tokens.Jwt 進行身分驗證，到了 ASP.NET Core 之後，用法沒有太大變化，不過我個人認為驗證的注入設定可讀性變的更高了...
ASP.NET Core 預設似乎沒有提供 Basic Authentication 的 DI，但仍然可以自行實作 AuthenticationHandler