以前都是針對設定檔依據不同環境有對應的檔案,或是安裝SlowCheetah 套件,可以將各類型
的設定檔依據組態產出對應的檔案;但若是組件(.dll)或是應用程式(.exe) 需要依據環境產生不同
的編號,可以怎麼做的呢?動手紀錄一下...
以前都是針對設定檔依據不同環境有對應的檔案,或是安裝SlowCheetah 套件,可以將各類型
的設定檔依據組態產出對應的檔案;但若是組件(.dll)或是應用程式(.exe) 需要依據環境產生不同
的編號,可以怎麼做的呢?動手紀錄一下...
最近再看舊的專案,發現有個 ExpandoObject 物件,搭配 dynamic 定義使用挺特別的;雖然我很少
這樣使用,之後也不會這樣用但是知道一下即可...
C#9 開始支援 Top-level statements,VS建立專案時預設都會使用頂層語句,除非手動勾選取消,
,若使用了頂層語句,在程式進入點(Program.cs)都會少了 Main() 方法,一開始會稍稍不習慣,
稍微了解後也就還好...
LINQ 的Join() 方法其效果等同於 SQL 的 INNER JOIN ,若有類似 Left Join 或Right Join 的效果話,
那使用 GroupJoin 會是一個解法,
使用 LINQ 有時會需要比對相關集合,若集合內比對的元素為「字串」或是「數值」那就單純許多,但
若是欲比對的元素為自訂型別(Class),那就需要注意了;這邊稍微紀錄一下若自訂型別屬性不多時,可
使用較為簡潔的比對方式...
最近又有機會玩 curl,在需要呼叫WebApi 的情境下可以幫助我們快速測試,當然Postman 也是
不錯的選擇;測試後對於 webapi 有了初步認知,後續就是要使用程式來實現了,而這個步驟若
能夠加快完成,提前下班不是夢...
對於系統可能發生例外的地方,一定都會採取必要措施,並且拋出美化後的訊息給用戶,如何
驗收我們要的「例外」,肯定是需要寫個測試來玩玩,這邊使用 NUnit 搭配 FluentAssertions
通常我們在某段成程式加入錯誤的攔截設計(try-catch),是因為覺得這邊可能發生預期的錯誤,
也許是網路或資料庫連結失敗,所以,為了避免發生錯誤時造成使用者體驗不好,通常會紀錄
該錯誤,但會回應使用者較無害的資訊,例如:系統忙碌中,請稍後再試
若是引用第三方套件的API,基本操作上能怎麼處理?
有時候就會有這種需求,Thirty Party 詭異的 Lib 設計,Method 不支援泛型,
也僅能傳入 Dictionary,故需要將 Object 轉成 Dictionary 後傳入...
一般這種需要確保屬性是否有值的動作,大都想到 MVC 有提供 ModelState.IsValid ,
快速且方便檢查Model Prop 上掛載的特性,如,是否可為Null 、長度... 等等;但若
無法在一開始就檢查,也許可以參考以下方式...
程式開發一段時間,對於序列化各個眉角,沒碰過一萬應該也有一千(誤),累積了不少經驗;
應該大部分情境也都能分出注意事項,逢凶化吉~,但這次dynamic 情境算是上了一課,
凡事還是小心為妙,別一昧的依賴經驗。在開始說明前先對於 dynamic 整理一點點資訊。
又往前推進了一個版本,這次來到 C# 7.3 ,而這小改版有一個地方讓我非常有感,
那就是「泛型的條件約束」,所以來特別來介紹,以前在設計泛型的時候,很常使用到「列舉」
,但就是無法直接使用關鍵字 Enum,需要轉念一下,原來是要使用 struct 關鍵字...
我認為單元測試主要用來驗證程式設計邏輯與系統功能正常運作的技法,期望哪些情境下,確保我們的設計都有考量到,
並且滿足需求,另外再未來擴充與修改系統功能下,依然能 維持既有的測試案例(不會改東壞西),
增加對軟體的信心度。但,再開始之前,
C# 7.0 持續追加feature,撰寫的自由度越來越高且狂,第一次看到時驚為天人,手感上有種慢慢偏動態語言的錯覺,
另外,在「模式比對」這一塊,有種遊戲使用「外掛」,看到黑影就可以開槍打中的錯覺,世界已經不是慢慢轉動,是跳耀式進展...
.net 發展至今,隨著.net core 3.1 的發佈,武器庫是越來越兇狠,新的語法支援可以更快速產出,編譯器也會
幫我們編出高效率的中繼碼,但實務還上還是有人不知道,這邊列出自己實務上很常使用的語法並且搭配應用情境,
另外,C# 6.0 其實在 VS2015 就已經支援了。
Reflection 很常使用,雖不是專案標配,但一年之內總會有使用它的地方,實務上往往與多型搭配起來完成動態實例化物件的技法;
但現實中既有程式難以捉摸,不一致的撰寫風格,或意指相同事務,但文字與設計方式卻充滿弔詭。這次遇上了,
還好C# 內建函式可以幫忙解決。