不知讀者們有沒有遇到過如下的狀況? 假設你需要從某個 CSV 檔案中匯入資料; 我們已經知道每個欄位是什麼。然後你為這份資料建立了類別, 也為每一個需要的欄位建立了屬性。當然, 你也一定知道每一個欄位是第幾欄, 但是 Visual Studio 並不知道。你必須每次都去查, 才能知道哪個欄位是哪一欄。假設 CSV 檔案內容如下
在 C# 6.0 中新增了方便的 String Interpolation 的功能, 它能進一步將原本的 string.Format 功能簡化。我們現在就可以使用 Visual Studio 2015 來做測試...
對於寫網頁的朋友而言, 或許和我一樣, 最害怕的問題就是, 在冗長的開發過程中解決了很多疑難雜症, 一路打通關之後, 卻在終於要發行到目標網站時, 才發生問題。這就像千辛萬苦爬上了 101 的頂樓, 才發現門竟然打不開...
今天遇到一個以前從未遇到過的小問題。我想把一個類別的建構式做成多載型式, 卻突然發現這個看起來很小的問題, 似乎並沒有直覺的做法...
雖然這是一個陳年的老問題, 我在實際應用中卻從來沒有踫到過 -- 直到今天。當然, 這也是一個陷阱; 如果我不是以前看過其他人的討論, 我恐怕會百思不得其解。這個問題很簡單, 相信許多人都有經驗: 把一個日期欄位寫進資料庫, 再取出來時, 發現兩個日期並不相等。它的陷阱在於, 這兩個日期有完全相同的年、月、日、時、分、秒, 但是寫進去 SQL 之後, 再讀出來, 它的 millisecond 值卻不同。Ticks 也不同。這個問題使得我的單元測試始終過不了...
最近遇到一個小需求。原本我為了讓使用者方便, 在不使用 TimePicker 的情況下, 讓他們可以手動方式輸入日期時間 (若使用 DateTimePicker 之類的工具, 效率會減少十倍)。然後我又幫他們自動加入當天的日期 (因為在大多數情況下, 他們需要輸入的日期都是當天, 但是都不是現在時間), 例如 "2014/9/30 "。接著, 我又下了 autofocus 屬性, 當網頁載入後, 讓這個文字框自動成為焦點, 因為這是第一個必須輸入的欄位。如此, 他們只要輸入時間的部份就行了。問題是, 他們每次要輸入時間時, 都必須再按一下滑鼠游標或者 End 鍵, 才能讓文字游標指到日期的後面, 這樣才能開始輸入時間。雖然這只是一個小工夫, 但是總讓人覺得討厭! 難道不能讓游標自動跑到最後面嗎?
在各式網站中用了一些 Log 套件之後, 我覺得其實有時候我們不一定需要那麼多複雜的功能, 或許我們只需要偶爾攔截並記錄一些例外錯誤而已。這時候, 我會推薦大家使用最簡單的方法, 也就是把網站中出現的所有例外情況都記在 Server 的 Event Log 裡面...
JSON.NET 是 James Newton-King 所開發的 JSON 程式庫, 他從 2005 年底著手開發, 於 2006 六月發表, 至今已歷經將近十年的時間。
Entity Framework (簡稱 EF) 發展到現在, 版本已經進入 6.1.0, 距離我寫的「在 VS2013 以 Code First 方式建立 EF 資料庫」這篇文章已有半年的時間。如果你和我一樣從那時候開始使用 EF Code First, 那麼你對 EF 應該已經有了基本的了解。依我個人的使用經驗, EF 雖然好用, 但是如果一直使用 AutomaticMigrations 的方式維護你的資料庫, 也許會遇到一些麻煩。因為在正常作業環境下, 資料庫的格式不可能永遠不變; 當我們已經開始寫入資料之後, 情況會變得更複雜, 迫使我們不得不去探究更適當、更有彈性的做法...
JSON.NET 可以讓我們很方便地讀寫 JSON 字串並對應到 C# 類別。在大部份的時候我們都可以簡單地使用 SerializeObject() 和 DeserializeObject() 方法進行轉換。但是一旦遇到 JavaScript 日期, 這招可能就行不通了。因為有些 JavaScript 開發人員會使用一種特殊的 JavaScript 日期表示法 (不是 Date 型別, 而是 Int64 型別) 來代表日期...
從 Visual Studio 2013 / .Net Framework 4.5.1 開始, 關於使用者驗證這件事, 可以說做了革命性的改變。大家在過去 12 年來再熟悉不過的表單驗證方式, 在這個版本中再也沒辦法使用 (或者更正確地說, 是沒辦法延用過去的做法)。相反地, 我發現它對 AD 認證的支援變得異常地簡單; 如果你在建立專案時選擇 Windows 驗證, 那麼你的網站自動可以抓取使用者的網域登入帳號, 不必再寫任何程式。如果你要寫的是企業內部網站的話, 就變得相當容易了。至於新的表單驗證方式, 我們會面臨的最大的困難在於不熟悉, 以及資訊太少(未來會慢慢變多, 這是確定的)。其實我是直到最近一個專案中需要用到表單驗證, 才突然驚覺它被改掉了。但是兩個多禮拜下來, 我覺得它其實基本上和原來的表單驗證方式並沒有太多的差異。你只要了解它的運作原理, 就會逐漸習慣...
我個人算不上什麼驚天動地的 SQL 專家, 只是一個離不開 SQL 的開發人員而已。在這篇文章裡, 我也不打算講什麼高深的 SQL 理論或技巧, 只打算把我個人研究出來的小小 SQL 管理心得拿來給大家分享。我還記得以前在設置開發環境時, 經常被 SQL 搞得七暈八素。不是怎樣都連不上資料庫, 就是必須牢記在什麼情況下要先裝 SQL, 後裝 VS, 再裝 SQL Management Studio 等等。不過時序來到 VS2013, 我發現似乎所有的事情都變得簡單了, 而且穩定。不過, 坦白說, 過去的陰影始終籠罩在心裡, 所以我把我的成功經驗寫在下面, 萬一有人又遇到類似的問題, 或許可以參考我的方法, 成功率也許高一點 (至少我自己試過是成功的)。此外, 我也要分享一個許多人不知道或者不熟悉的管理小技巧...
Linq2Excel 是一個非常方便好用的小工具, 它是一個 Excel 專用的 LINQ Provider, 可以讓我們很快速地讀取 Excel (包括 Excel 2013) 的試算表。我們可以直接在 Visual Studio 中透過 NuGet 取得, 目前的版本是 1.7.1。如果你對這個套件有興趣, 你可以參考「LINQ - 實作 LinqToExcel」這篇文章, 足以讓你快速入門...
App_Code 是一個 ASP.NET 網站專案的特殊子目錄。如果你的專案不是 Web Site 專案而是 Web Application 專案, 你並不需要、也不應該特別建立一個 App_Code 子目錄來存放你的程式碼 -- 除非是為了某種特殊的目的。例如, 如果你希望幫網站加入動態產生版本的功能的話, 那麼你可以建立 App_Code 子目錄 (在這裡都使用 Web Application 專案), 並且在這個子目錄下隨便建立一個如下的類別檔...
我想, 凡是已經寫 ASP.NET 很久的程式設計師, 一定都知道如何透過 RegisterStartupScript(key, script) 和 RegisterClientScriptBlock(key, script) 這兩種指令在頁面中插入動態的 JavaScript 程式。但是只有這種方法嗎? 以下, 我要示範一個「超級小」的技巧, 以更簡單的方式達到相同或類似的功能。只不過, 這種方式比較適合「罐頭」式的 JavaScript 指令, 也就是比較偏向靜態、很少改變的 JavaScript 程式。我將使用 ASP.NET 的網頁的 PostBack 機制, 讓已經寫好的 JavaScript 程式在網頁 PostBack 之後自動執行...
在 C# 中 Enum 是一個純粹靜態的結構, 當你宣告了一個 enum, 那麼它的值就固定在那裡了, 你非得去更改它的定義, 才能看到內容項目的變更。那麼, 如果我們能把它的內容項目 (包括它的值) 變成動態的呢? 在接下去之前, 我必須先把它適用的情境清楚的描述一遍, 否則大家可能無法理解為什麼要這麼做...
當你下載並安裝 Visual Studio 2013 Preview 之後, 要如何建立一個使用 Entity Framework 的專案呢? 在以下文章裡, 我要示範一個使用 Code First 方式建立的專案。我所將描述的內容可以在以下影片中看到... 此外, 你也可以在「Code First 至新的資料庫」這篇文章裡找到相當完整的 Step by step 操作步驟 (中文)...
在我目前的工作中, 環境略為有點複雜, 牽涉到開發、測試和正式環境, 而使用的資料庫伺服器也有兩到三個。如果能夠動態地切換不同環境下所使用的資料庫連線字串, 一定對工作相當有幫助。當然, 如果我都寫 ADO.NET 指令去指定連線字串, 我自然可以動態地決定應該採用哪一個連線字串。但是, 我又不想放棄簡單易用的 GridView/FormView 搭配 SqlDataSource 的作業方式。無可誨言的, 對於那些許多很小型的資料表、很少的資料、很簡單的工作, 實在沒有什麼能比上述情境更方便處理了...
最近在編寫程式時, 注意到幾個關於程式註解的注意事項, 我把它記錄起來, 同時提供朋友們參考。註解內要怎麼斷行? 例如以下用來註解 interface 的程式行, 你在註解中把它斷行是無效的...
這是一個相當古老的問題。不過, 似乎也很久沒遇到過了。當今天再度遇到時, 突然被嚇了一跳。問題是這樣的, 當我們建立單元測試專案時, 如果你看到測試不成功的原因是什麼「System.ArgumentException: 此處不允許應用程式相對虛擬路徑 '~/'」之類莫名其妙的錯誤的話, 大概就是依照以下解法就對了...
