C#/.NET易錯的幾點

1 及時釋放資源
      CLR託管環境扮演了垃圾回收的角色，所以你不需要明確釋放已建立物件所佔用的記憶體。但這不代表你可以忽略所有的使用過的物件。許多物件封裝了其 他類型的系統資源（例如，磁碟文件，資料連接，網路連接埠）。維持這些資源的使用狀態會急劇的耗盡系統的資源，削弱效能並且最終導致程式出錯。當你開啟一個 檔案、網路連接埠或資料連線時，當你不再使用這些資源時，就應該盡快明確釋放這些資源。
另外針對資源的操作，一般需要增加異常捕獲處理（Try..Catch），這時別忘記在finally中進行資源釋放，以確保在捕獲異常時也可以正常釋放資源。
2 正確停止多執行緒
FileStream fs = File.Open(…);
Try{…} Finally{ fs.Close;}
假設如上程式碼在工作執行緒中，已經進行到finally裡面，這個時候UI執行緒呼叫了該執行緒的Abort()方法，則很有可能fs.Close還沒執行的時候，工作執行緒跳出finally程式碼區塊了。這樣你的fs就永遠不會被Close了。
大多數情況下，finally會永遠被執行，但不包括呼叫Thread.Abort所引發的ThreadAbortException異常，鑑於此理由，不建議使用Abort。
要正確停止線程，不在於呼叫者採用了什麼行為(不要直接使用Thread.Abort())，而更多依賴於工作線程是否能主動回應呼叫者的停止請求。
大體機制是，如果執行緒需要被停止，那麼執行緒本身就應該負責開放給呼叫者Cancel的介面。
3 類型轉換相關
如果從資料庫讀取某個值，有資料時是int型，沒有資料的話取得到的是null，型別強轉則會異常。所以一般很少用強轉，用的話也必須做一個異常捕獲，避免程序異常。
在強轉不好的情況下，我們建議使用TryParse方法，該方法已經對Parse方法進行了異常處理。
也可以用Convert，同樣需要進行異常捕獲；其實，凡是涉及到類型轉換，序列化等操作的地方，都需要捕獲異常；
4 字符串操作問題
在對字符串操作中，若涉及大量拼接操作建議使用StringBuilder。若使用String會帶來明顯的效能損耗。原因在於string對像是 個很特殊的對象，它一旦被賦值就無法改變。在執行時間呼叫String類別中任何拼接操作（如賦值、”+”等），都會在記憶體中建立一個新的字串對象，也意義 著要為該新物件分配新的記憶體空間。
5 const常數修改所導致的問題
當程式引用其他dll中的const常數時要特別注意。
若修改了此dll中的const常數後，要重新編譯引用了此dll中這個const常數的所有程序，否則程式中使用的這個常數值將會和dl中的不一致。
另外如果使用readonly代替const可以解決這個問題，不需要重新編譯，因為const是編譯型常數，而readonly是運行時常數。
6 C#編譯目標平台問題
當程式依賴的dll的編譯的目標平台是X86，則程式本身的編譯目標平台也必須是X86(而不是預設選項Any CPU)，否則64位元電腦將無法運行。
7 跨執行緒存取控制項
在開發介面程式時，會遇到比較耗時的操作，為了程式的友善性，我們一般會在任務執行緒中執行耗時操作，並將執行資訊顯示在主UI線程。
假如直接在任務線程中操作主UI線程中的控件，這樣極易出現異常，則報“不能在其他線程中修改創建控件線程的值”，如果設置了禁止編譯器對跨線程訪問做檢查，就不會報錯，但是會出現無法預測的問題。此時建議採用委託或匿名委託的方式實現。

以上是C#/.NET易錯的幾點的詳細內容。更多資訊請關注PHP中文網其他相關文章！