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线程中的控件，这样极易出现异常，报“不能在其他线程中修改创建控件线程的值”，如果设置了禁止编译器对跨线程访问做检查，就不会报错，但是会出现无法预知的问题。此时建议采用委托或匿名委托的方式实现。