[DllImport("KERNEL32.DLL", EntryPoint="MoveFileW",  SetLastError=true,
CharSet=CharSet.Unicode, ExactSpelling=true,
CallingConvention=CallingConvention.StdCall)]
public static extern bool MoveFile(String src, String dst);

　　由于WindowsAPI用到的人实在是多，因此有一个专门的wiki站点，收集这方面的资料：http://www.pinvoke.net/，对于常用的函数甚至有完整的应用例子和帮助。当然，如果你有相应的资料和例子，你也可以贡献你的力量，给其它人帮助。

 　　场景二：用托管C++包装现有的DLL，供C#调用

　　当函数的参数或返回值比较复杂，或函数比较多的时候，这种方法对与人来说，实在是一个折磨。常常这些接口和定义就要用掉几千行的代码，而且还不能保证是正确的。这些错误往往在运行时才能显现出来，甚至有些错误会引起内存泄漏，或其它更为隐蔽的错误。
　　在这种情况下，使用C++/Managed代码来包装，就成了最合理的选择。因为托管C++代码可以直接引用原有的头文件，直接调用非托管函数，而不需要声明。这样，既减少了工作量，又避免引入错误。缺点是，这种方法会增加一个DLL。要注意的是托管字符串和非托管字符串是有区别的，并需要转换（特别要注意的Unicode字符串和多字节字符串的转换）。

　　仍以MoveFile为例吧，这样比较简单：

#include <windows.h>
#include <vcclr.h>

using namespace System;

namespace wrapper
{
    public ref class ApiWrapper {
    public:
        bool static MoveFile(String ^ lpExistingFileName, String ^ lpNewFileName )
        {
            pin_ptr<const wchar_t> src = PtrToStringChars(lpExistingFileName);
            pin_ptr<const wchar_t> dst = PtrToStringChars(lpNewFileName);
            return ::MoveFile(src, dst);
        }
    };
}

wrapper.ApiWrapper.MoveFile(@"c:\debug.log", @"c:\debug.txt");

class UnmanagedClass {
public:
    LPCWSTR GetPropertyA() { return L"Hello!"; }
    void MethodB( LPCWSTR ) {}
};

namespace wrapper
{
    public ref class ManagedClass {
    public:
        // Allocate the native object on the C++ Heap via a constructor
        ManagedClass() : m_Impl( new UnmanagedClass ) {}

        // Deallocate the native object on a destructor
        ~ManagedClass() {
            delete m_Impl;
        }

    protected:
        // Deallocate the native object on the finalizer just in case no destructor is called
        !ManagedClass() {
            delete m_Impl;
        }

    public:
        property String ^  get_PropertyA {
            String ^ get() {
                return gcnew String( m_Impl->GetPropertyA());
            }
        }

        void MethodB( String ^ theString ) {
            pin_ptr<const WCHAR> str = PtrToStringChars(theString);
            m_Impl->MethodB(str);
        }

    private:
        UnmanagedClass * m_Impl;
    };
}

ManagedClass mc = new ManagedClass();
mc.MethoB("Hello");
string s = mc.get_PropertyA;

#pragma unmanaged

#include <iostream>
using namespace std;

template<typename T>
void f(T t){
    cout << t << endl;
}

#pragma managed

using namespace System;

void m(String ^ s){
    Console::WriteLine(s);
}

void main(){
    f("Hello");
    m("World");
}

[PreserveSig, MethodImpl(MethodImplOptions.Unmanaged, MethodCodeType=MethodCodeType.Native), SuppressUnmanagedCodeSecurity]
public static unsafe void modopt(CallConvCdecl) f<char const *>(sbyte modopt(IsSignUnspecifiedByte) modopt(IsConst)*);

internal static unsafe void modopt(CallConvCdecl) f<char const *>(sbyte modopt(IsSignUnspecifiedByte) modopt(IsConst)* t)
{
      std.basic_ostream<char,std::char_traits<char> >.<<(std.operator<<<struct std::char_traits<char> >(*((basic_ostream<char,std::char_traits<char> >* modopt(IsImplicitlyDereferenced)*) &__imp_std.cout), t), (basic_ostream<char,std::char_traits<char> >* modopt(IsImplicitlyDereferenced) modopt(CallConvCdecl) *(basic_ostream<char,std::char_traits<char> >* modopt(IsImplicitlyDereferenced))) __unep@?endl@std@@$$FYAAAV?$basic_ostream@DU?$char_traits@D@std@@@1@AAV21@@Z);
}

　　当然是可以的。具体参见：让C++代码与C#代码一起生成一个单一的Assembly

-------
部份例子来自MSDN.

The last two Nuts and Bolts articles focused on database related topics. This month we'll change gears and focus on something different. The focus of this month's article will be .NET remoting. We'll discuss what is .NET Remoting, how it compares to DCOM and Web services, and go through an example.

What is .NET Remoting?

.NET Remoting is an enabler for application communication. It is a generic system for different applications to use to communicate with one another. .NET objects are exposed to remote processes, thus allowing interprocess communication. The applications can be located on the same computer, different computers on the same network, or even computers across separate networks.

.NET Remoting versus Distributed COM

In the past interprocess communication between applications was handled through Distributed COM, or DCOM. DCOM works well and the performance is adequate when applications exist on computers of similar type on the same network. However, DCOM has its drawbacks in the Internet connected world. DCOM relies on a proprietary binary protocol that not all object models support, which hinders interoperability across platforms. In addition, have you tried to get DCOM to work through a firewall? DCOM wants to communicate over a range of ports that are typically blocked by firewalls. There are a ways to get it to work, but they either decrease the effectiveness of the firewall (why bother to even have the firewall if you open up a ton of ports on it), or require you to get a firewall that allows support for binary traffic over port 80.

.NET Remoting eliminates the difficulties of DCOM by supporting different transport protocol formats and communication protocols. This allows .NET Remoting to be adaptable to the network environment in which it is being used.

.NET Remoting versus Web Services

Unless you have been living in a cave, or are way behind in your reading, you have probably read something about Web services. When you read the description of .NET Remoting it may remind you a lot of what you're read about Web services. That is because Web services fall under the umbrella of .NET Remoting, but have a simplified programming model and are intended for a wide target audience.

Web services involve allowing applications to exchange messages in a way that is platform, object model, and programming language independent. Web services are stateless and know nothing about the client that is making the request. The clients communicate by transferring messages back and forth in a specific format known as the Simple Object Access Protocol, or SOAP. (Want to get some funny looks in the hallway? Stand around in the hallway near the marketing department with your colleagues and discuss the benefits of using SOAP).

The following list outlines some of the major differences between .NET Remoting and Web services that will help you to decide when to use one or the other:

• ASP.NET based Web services can only be accessed over HTTP. .NET Remoting can be used across any protocol.
  
• Web services work in a stateless environment where each request results in a new object created to service the request. .NET Remoting supports state management options and can correlate multiple calls from the same client and support callbacks.
  
• Web services serialize objects through XML contained in the SOAP messages and can thus only handle items that can be fully expressed in XML. .NET Remoting relies on the existence of the common language runtime assemblies that contain information about data types. This limits the information that must be passed about an object and allows objects to be passed by value or by reference.
  
• Web services support interoperability across platforms and are good for heterogeneous environments. .NET Remoting requires the clients be built using .NET, or another framework that supports .NET Remoting, which means a homogeneous environment.

Channels

Remote objects are accessed through Channels. Channels physically transport the messages to and from remote objects. There are two existing channels TcpChannel and HttpChannel. Their names give away the protocols that they use. In addition, the TcpChannel or HttpChannel can be extended, or a new channel created if you determine the existing channels do not meet your needs.

Create a Remotable Object

A remotable object is nothing more than an object that inherits from MarshalByRefObject. The following sample demonstrates a simple class to expose the omnipresent hello world. This object exposes a single method HelloWorld that will return a string. The only values that can be returned from methods are the classes in the .NET Framework that are serializable such as string and DataSet. In addition, if you need to return a user-defined object then the object needs to be marked as serializable.

Create a new C# class library project. Add a class called SampleObject and put in the following code. Add a reference to System.Runtime.Remoting in the project, otherwise the TcpChannel will not be found. Compile the class to make sure you have everything correct.

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;
namespace CodeGuru.Remoting
{
/// <remarks>
/// Sample object to demonstrate the use of .NET Remoting.
/// </remarks>
public class SampleObject : MarshalByRefObject
{
/// <summary>
/// Constructor
/// </summary> 
public SampleObject()
{
}

/// <summary>
/// Return a hello message
/// </summary>
/// <returns>Hello world message</returns>
public string HelloWorld()
{
return "Hello World!";
}
}
}

Create a Server To Expose the Remotable Object

We need to create a server object that will act as a listener to accept remote object requests. For this example we will use the TCP/IP channel. We first create an instance of the channel and then register it for use by clients at a specific port. The service can be registered as WellKnownObjectMode.SingleCall, which results in a new instance of the object for each client, or as WellKnownObjectMode.Singleton, which results in one instance of the object used for all clients.

It is not necessary to create the server listener if you are planning to use IIS. For obvious reasons, IIS only supports the use of the HttpChannel. Create a virtual directory for your application and then put code to register your service in the Application_Start event.

For our example, we'll go ahead and create a server listener in case you don't have IIS. Since the service needs to be bound to an available port, for our example I chose 8080, which is a port that I know to be unused on my computer. You may need to choose a different port depending upon what ports you have available. To see a list of the used ports on your computer open a command prompt and issue the command "netstat --a". It may produce a long listing so make sure the command prompt buffer sizes are set to allow scrolling. Compile the class to make sure you have everything correct.

Create a new C# console application project. Add a class called SampleServer and paste in the following code. Add a reference to System.Runtime.Remoting in the project, otherwise the TcpChannel will not be found. In addition, add a reference to the project containing the SampleObject, otherwise the code will not compile because it won't know how to find a reference to SampleObject.

using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;
namespace CodeGuru.Remoting
{
/// <remarks>
/// Sample server to demonstrate the use of .NET Remoting.
/// </remarks>
public class SampleServer
{
public static int Main(string [] args)
{
// Create an instance of a channel
TcpChannel channel = new TcpChannel(8080);
ChannelServices.RegisterChannel(channel);
// Register as an available service with the name HelloWorld
RemotingConfiguration.RegisterWellKnownServiceType(
typeof(SampleObject),
"HelloWorld",
WellKnownObjectMode.SingleCall );
System.Console.WriteLine("Press the enter key to exit...");
System.Console.ReadLine();
return 0;
}
}
}
Create a Client To Use the Remotable Object
Now that we have our remotable object and a server object to listen for requests, let's create a client to use it. Our client will be very simple. It will connect to the server, create an instance of the object using the server, and then execute the HelloWorld method. 
Create a new C# console application project. Add a class called SampleClient and paste in the following code. Add a reference to System.Runtime.Remoting in the project, otherwise the TcpChannel will not be found. In addition, add a reference to the project containing the SampleObject, otherwise the code will not compile because it won't know how to find a reference to SampleObject. Compile the class to make sure you have everything correct. 
using System;
using System.Runtime.Remoting;
using System.Runtime.Remoting.Channels;
using System.Runtime.Remoting.Channels.Tcp;
namespace CodeGuru.Remoting
{
/// <remarks>
/// Sample client to demonstrate the use of .NET Remoting.
/// </remarks>
public class SampleClient
{
public static int Main(string [] args)
{
// Create a channel for communicating w/ the remote object
// Notice no port is specified on the client
TcpChannel chan = new TcpChannel();
ChannelServices.RegisterChannel(chan);
// Create an instance of the remote object
SampleObject obj = (SampleObject) Activator.GetObject(
typeof(CodeGuru.Remoting.SampleObject),
"tcp://localhost:8080/HelloWorld" );
// Use the object
if( obj.Equals(null) )
{
System.Console.WriteLine("Error: unable to locate server");
}
else
{
Console.WriteLine(obj.HelloWorld());
}
return 0;
}
}
}

Test the Remoting Sample
Once you have created the projects and successfully compiled each of them you are ready to try it out. Assuming you chose a free TCP/IP port for the service, start the server executable. After the server successfully starts it will result in a console window being displayed with the message "Press the enter key to exit". The server is listening so you are now ready to run the client. Executing the client should result in "Hello World!" being displayed in a separate console window. The client window will then close while the server remains open and available. 
If you have multiple computers available to you on a network you could execute the server on one machine and the client on another just to prove to yourself that it really is remoting. In order to run on separate machines you would need to change the reference to localhost in the sample client to point to the appropriate location. 
Summary
.NET Remoting is a powerful way to enable interprocess communication. It is more complicated to program against than Web services. You need to decide for yourself whether your standard architecture is to use .NET Remoting or Web services. 
Future Columns
The next column will be on the use of encryption in the .NET framework. We'll take a look at some of the encryption algorithms available in the framework and ways to use them. If you have a particular topic in mind please email me at mstrawmyer@crowechizek.com
About the Author
Mark Strawmyer, MCSD, MCSE (NT4/W2K), MCDBA is a Senior Architect of .NET applications for large and mid-size organizations. Mark is a technology leader with Crowe Chizek in Indianapolis, Indiana. He specializes in architecture, design and development of Microsoft-based solutions. You can reach Mark at mstrawmyer@crowechizek.com.

有许多人问的，.Net中的委托以及事件处理。我拿简单的例子说明一下，是现实中的例子：

比如说一个公司（场景），你是老板，手下有两个员工，小张和小王。
你命令小王，如果小张玩游戏，则小王扣去小张500元钱。

这就是现实中的委托。

实际上，在写程序中，程序员就是老板，小张和小王就是两个对象。小张玩游戏是一个方法，小张还有一个游戏事件，他玩游戏激发这个事件。而小王就是事件处理对象，他负责把小张的钱扣除500。

所以，委托有如下几个要素：
1 激发事件的对象--就是小张
2 处理对象事件的对象--就是小王
3 定义委托，就是你让小王监视小张。

如果这三个要素都满足的话，则你就写出了一个完整事件的处理。

下面有个例子：在vs.net2003 C#控制台应用程序编辑运行成功：
using System;

namespace CSharpConsole
{
 public class 场景
 {
  [STAThread]
  public static void Main(string[] args)
  {
   Console.WriteLine("场景开始了....");
   // 生成小王
   小王 w = new 小王();
   // 生成小账
   小张 z = new 小张();

   // 指定监视
   z.PlayGame += new PlayGameHandler(w.扣钱);

   // 开始玩游戏
   z.玩游戏();

   console.writeline("场景结束...");
   Console.ReadLine();
  }
 }

 // 负责扣钱的人
 public class 小王
 {
  public 小王()
  {
   Console.WriteLine("生成小王...");
  }

  public void 扣钱(object sender,EventArgs e)
  {
   Console.WriteLine("小王：好小子，上班时间胆敢玩游戏...");
   Console.WriteLine("小王：看看你小子有多少钱...");
   小张 f = (小张)sender;
   Console.WriteLine("小张的钱： " + f.钱.ToString());
   Console.WriteLine("开始扣钱......");
   System.Threading.Thread.Sleep(500);
   f.钱 = f.钱 - 500;
   Console.WriteLine("扣完了....现在小张还剩下：" + f.钱.ToString());
  }
 }

 // 如果玩游戏，则引发事件
 public class 小张
 {
  // 先定义一个事件，这个事件表示“小张”在玩游戏。
  public event PlayGameHandler PlayGame;
  // 保存小张钱的变量
  private int m_Money;

  public 小张()
  {
   Console.WriteLine("生成小张....");
   m_Money = 1000; // 构造函数，初始化小张的钱。
  }

  public int 钱 // 此属性可以操作小张的钱。
  {
   get
   {
    return m_Money;
   }
   set
   {
    m_Money = value;
   }
  }

  public void 玩游戏()
  {
   Console.WriteLine("小张开始玩游戏了.....");
   Console.WriteLine("小张:CS好玩，哈哈哈！ 我玩.....");
   System.Threading.Thread.Sleep(500);
   System.EventArgs e = new EventArgs();
   OnPlayGame(e);
  }

  protected virtual void OnPlayGame(EventArgs e)
  {
   if(PlayGame != null)
   {
    PlayGame(this,e);
   }
  }
 }

 // 定义委托处理程序
 public delegate void PlayGameHandler(object sender,System.EventArgs e);

}