m.Runtime.InteropServices命名空间。
C#的语法为：
using System.Runtime.InteropServices;
（1）.NET访问API
.NET允许C＃访问未托管的DLL的函数。如要调用Windows User32.dll的MessageBox函数：
int MessageBox(HWND hwnd,LPCTSTR lpText, LPCTSTR lpCaption,UINT uType)
可以声明一个具有DLLImport属性的static extern方法：
using System.Runtime.InteropServices;
[DllImport(“user32.dll”)]
static ertern int MessageBox(int hwnd,string text,string caption,int type);
然后在代码里面直接调用就可以了。这里要注意在调用返回字符串的API中使用StringBuilder对象。
（2）.NET访问COM组件
从.NET调用COM组件比较容易，只要使用tlbimp.exe产生COM的装配形式的WarpClass，然后在.NET项目中调用即可。
注意COM的类型信息通过Type Library文件描述，.NET装配件是自描述的。Tlbimp的作用是从COM组件及其类型信息中产生自描述的装配件。
1．编写Com组件
编译生成一个ComAccount.dll。
2. 产生.NET可访问的包装类（assembly），使用TlbImp.exe产生.NET装配件。
TlbImp /out：NetAccount.dll ComAccount.dll
3．在.NET代码中访问
.NET代码只需引用NetAccount.dll,就可以像访问.NET的装配件一样访问COM组件。
四、异常处理
异常处理的原则
n 在应用程序级（线程级）错误处理器中处理所有的一般异常。遇到“意外的一般性错误”时，此刻错误处理器应该捕捉异常，给用户提示消息，在应用
程序关闭或用户选择“忽略并继续”之前记录错误信息。
n 不必每个方法都用try-catch，当特定的异常可能发生时才使用。比如，当写文件时，处理异常FileIOException。
n 别写太大的 try-catch 模块。如果需要，为每个执行的任务编写单独的 try-catch 模块。这将有助于找出哪一段代码产生异常，并给用户发出特定的错误消息。
n 如果应用
程序需要，可以编写自己的异常类。自定义异常不应从基类SystemException派生，而要继承于IApplicationException。
n 在开发阶段，不必在所有方法中捕捉一般异常。刻意的放纵异常，将帮助在开发周期发现大多数的错误。
异常处理的提示
n 不要捕捉了异常却什么也不做，看起来系统似乎在正常运行。如果这样隐藏了一个异常，将永远不知道异常到底是否发生，为什么发生。
n 发生异常时，给出友好的消息给用户。但要精确记录错误的所有可能细节，包括发生的时间，和相关方法，类名等。
n 永远别用像“应用
程序出错”，“发现一个错误”等错误提示消息，而应给出类似“更新数据库失败，请确保登陆id和密码正确。”之类的具体消息。
n 显示错误消息时，还应提示用户如何解决问题。如：“更新数据库失败，请确保登陆id和密码正确。”，而不是仅仅说“更新数据库失败”。
n 显示给用户的消息要简短而友好。但要把所有可能的信息都记录下来，以助诊断问题。
异常处理的代码实例
推荐如下异常处理模式：
void ReadFromFile ( string fileName )
{
try
{
// 读文件.
}
catch (FileIOException ex)
{
// 记载异常日志
// 重抛具有针对性的异常信息
throw;
}
}
不推荐如下的异常处理模式：
void ReadFromFile ( string fileName )
{
try
{
// 读文件
}
catch (Exception ex)
{
// 捕捉一般异常将让我们永远不知道到底是文件错误还是其他错误
// 隐藏异常将我们永远不知道有错误发生。
return "";
}
}
五、对象实例的申请与释放
.Net平台的垃圾回收机制，可以自动的dispose不再引用的对象实例，所以很多开发人员并不主动释放申请的对象资源。事实上，在对象的生命周期结束之前是不会被释放的。
但是，很多时候当对象处于生命周期之内时，我们不再使用它，以便释放资源提
