Simple Is Not Easy

這篇是為了紀錄依賴注入時, 利用建構子注入的情境下, 當注入到有繼承關係的類別時所引發的維護上的困擾與解決方案.

這個問題比較複雜, 一開始引發問題的情境是

A 專案依賴 B 專案, 且雙方都依賴同一個套件, 但卻是不同版本的套件

由於情境比較複雜, 所以我開了一個範例專案 DependentAssemblyIssue 來做示範, 內文會依照情境來描述處理方式以及所造成的後遺症.

前陣子做了一個 dotnet core 的新專案, 上線前需要先跟 Jenkins 佈署流程整合, 本來很單純的想說用 dotnet MyCore.dll 指令開啟應用程式, 至於停止的時候就暴力用 kill 指令來關閉 (當然這種暴力解只是在實驗階段用來建立信心的, 接下來還是要找看有沒有其他更好的做法).

沒想到連信心都建立不起來, 透過 Jenkin 用 kill 指令時, 會出現錯誤 (沒有把錯誤細節記錄下來, 反正用 kill 也太暴力, 終究還是要換個方法的, 所以就果斷放棄去找尋新方法了).

在開發 C# 程式或是學習過程, 會用到許多不是由我們開發的框架或套件, 很多時候會需要知道內部的運作方式, 這篇紀錄幾個方式來讓我們能知道套件內部究竟做了什麼.

用 Json.NET 來將 JSON 字串反序列化成物件是很典型的做法, 以前也沒出過什麼問題, 但在某些使用方式下, 會出現數字的尾數 0 被移除的狀況, 例如: 10.00 會被轉成 10, 而 10.10 會被轉成 10.1.

雖然這個結果乍看之下沒什麼影響, 但如果資料是在跟第三方 API 介接時, 簽章 (sign) 所需要的欄位時, 就會直接導致簽章檢核錯誤.

在之前的文章 在 vs2017 中使用 Entity Framework 操作 SQLite 使用方式雖然方便, 但是相對的非常依賴工具, 所以這篇用來記錄用盡量少的工具來使用 Entity Framework 操作 SQLite.

有時候做一些實驗的時候會需要用到資料庫, 但是為了實驗特別架一個 SQL Server 的環境實在是很麻煩, 電腦重灌或是虛擬機重裝的時候重建也麻煩, 所以就把腦筋動到 SQLite 上了, 不過操作上沒有想像中的簡單呢.

因為是為了建構實驗用的資料庫, 不希望花太多時間, 希望能盡可能方便的將資料存取層建起來, 所以採用資料庫優先 (database first) 的方式來建立 ADO.NET Entity Data Model (*.edmx).

在跟外部廠商介接的過程發現少數廠商在發送到我們的 WebAPI 的 request 是 multipart/form-data 的, 以前舊的老專案中要處理這種資料還要透過第三方套件, 後來在遷移到 .NET 的過程中發現,用 .NET 處理這類型的資料是可以不用第三方套件的, 所以紀錄一下碰到的幾種情境的處理方式.

前陣子的新專案用的是 .NET core 2.1, 在加測試專案的時候發現測試專案編譯無法通過, 拋出類似於版本衝突/版本錯誤之類的錯誤 (錯誤碼忘了, 不知道是不是 CS1705), 經過檢查後發現產品專案和測試專案的相關組件版本都一樣, 一時間還真的找不到方向.

事情是這樣的, 有一天我需要在某個共用的 BaseApiController 中取得 request 中的內容並做一些操作, 所以寫下了像是這樣的內容, 然後 他就死掉了 就出現 NullReferenceException 了.

1
2
3
4
5
6
7
8
9

public class BaseApiController : ApiController
{
	public BaseApiController()
	{
		var request = Request;
		// do someting from request, ex: read headers
		var myHeader = request.Headers.GetValues("MyHeader");
	}
}