Ron 2.0

如果組件 A 是組件 B 的 Friend Assembly, 則在組件 A 中能存取別的組件內的 internal 類別或成員, 更多細節在官方介紹.

為了降低多個專案間的複雜度, 我們通常會謹慎的控制專案之間的依賴, 但在最近新開案的 .NET Core 一系列的新專案中發現傳遞依賴會讓專案之間產生預期外的依賴.

Encoding.UTF8 和 new UTF8Encoding() 所建立的物件內容是極其相似的, 甚至有些問答網站是說完全一樣, 但實際上有個小小不同的地方, 雖然多數時候不會造成影響, 但前陣子在寫 xml 序列化的測試的時候就出現結果不同的情境, 所以稍微紀錄一下.

問題的起源在於某次搬遷程式碼的時候, 雖然看起來只是將一個方法移動到別的專案, 卻不小心讓一個有使用反射的方法在執行階段拋錯, 雖然查明後發現不是太刁鑽的問題, 但卻是容易不小心出錯的, 所以稍微紀錄一下.

一般來說套件的使用方式沒什麼好寫的, 但是使用 NUnit 的 OneTimeSetUp 時, 究竟是在多大的範圍做一次性的行為會根據這個特性 (Attribute) 的使用位置而不同, 這部分文件是放在 SetUpFixture Attribute 一節 說明, 不過沒有所有情境的範例程式, 所以做了一些實驗來簡單紀錄一下更細節的部分.

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

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

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) 所需要的欄位時, 就會直接導致簽章檢核錯誤.