当到期时，异常信息和调用堆栈如下：
    ----> CoreLab.MySql.MySqlException : Sorry, your trial period has expired.
    --MySqlException
         at CoreLab.MySql.MySqlConnection.Open() 

    在打开MySqlConnection出错，用Reflector分析CoreLab.MySql.dll看一下代码：

Code
License license = ac.a().GetLicense(LicenseManager.CurrentContext, typeof(MySqlConnection), this, false);

u u = license as u;
if ((u != null) && (u.b() != null))
{
    throw new MySqlException(-1, u.b());
}

可以看到，ac这个类实现LicenseProvider用于产生License，而u这个类继承License对象，同时保存更具体的认证信息。
由于混淆过，我们无从知道u这个类每个字段的含义(a,b,c,d,e,f)，这个时候我们需要人为执行一下GetLicense，看里面到底包含什么数据：

Code
Type licenseType = typeof(LicenseProvider);
Assembly coreLabMySql = typeof(CoreLab.MySql.MySqlConnection).Assembly;

Type t = coreLabMySql.GetType("CoreLab.Common.ac");
Type u = coreLabMySql.GetType("CoreLab.Common.u");

// 创建ac对象
var aMethod = t.GetMethod("a", BindingFlags.Static | BindingFlags.Public);
var ac = aMethod.Invoke(null, new object[] { });

// 模拟调用GetLicense
MySqlConnection conn = new MySqlConnection();
var getLicense = t.GetMethod("GetLicense");
var license = getLicense.Invoke(ac, new object[] { LicenseManager.CurrentContext, typeof(MySqlConnection), conn, false });

// 查看返回的license
var uLicense = Convert.ChangeType(license, u);

调试的时候我们可以看到，u.a包含了LicenseString, u.c则包含了认证失败的错误信息，u.e=3，这个貌似是返回码。
我们把系统时间调前，看一下未到期的时候，产生的license是什么样子：
u.a=LicenseString, u.c=null, u.e=0

2、产生可以使用的License

Code
public class MyLicenseProvider : LicenseProvider
{
    public override License GetLicense(LicenseContext context, Type type, object instance, bool allowExceptions)
    {
        Assembly coreLabMySql = typeof(CoreLab.MySql.MySqlConnection).GetType().Assembly;
        Type uType = coreLabMySql.GetType("CoreLab.Common.u");
        object u = Activator.CreateInstance(uType, "Here is license string", null, false, 0, null);
        return u as License;
    }
}

自己运行一下，OK，可以产生一个正常的license

3、修改DLL
     首先，将上述MyLicenseProvider编译成一个DLL，我们需要得到上述代码的IL:
     ilasm MyLicenseProvider.dll /out=MyLicenseProvider.il
     找到 GetLicense 方法：

Code
// Code size       82 (0x52)
.maxstack  4
.locals init ([0] class [mscorlib]System.Reflection.Assembly coreLabMySql,
       [1] class [mscorlib]System.Type uType,
       [2] object u,
       [3] class [System]System.ComponentModel.License CS$1$0000,
       [4] object[] CS$0$0001)
IL_0000:  nop
IL_0001:  ldarg.0
IL_0002:  call       instance class [mscorlib]System.Type [mscorlib]System.Object::GetType()
IL_0007:  callvirt   instance class [mscorlib]System.Reflection.Assembly [mscorlib]System.Type::get_Assembly()
IL_000c:  stloc.0
IL_000d:  ldloc.0
IL_000e:  ldstr      "CoreLab.Common.u"
IL_0013:  callvirt   instance class [mscorlib]System.Type [mscorlib]System.Reflection.Assembly::GetType(string)
IL_0018:  stloc.1
IL_0019:  ldloc.1
IL_001a:  ldc.i4.5
IL_001b:  newarr     [mscorlib]System.Object
IL_0020:  stloc.s    CS$0$0001
IL_0022:  ldloc.s    CS$0$0001
IL_0024:  ldc.i4.0
IL_0025:  ldstr      "here is license string"
+ "k0WXphh/g4KEcX"
IL_002a:  stelem.ref
IL_002b:  ldloc.s    CS$0$0001
IL_002d:  ldc.i4.2
IL_002e:  ldc.i4.0
IL_002f:  box        [mscorlib]System.Boolean
IL_0034:  stelem.ref
IL_0035:  ldloc.s    CS$0$0001
IL_0037:  ldc.i4.3
IL_0038:  ldc.i4.0
IL_0039:  box        [mscorlib]System.Int32
IL_003e:  stelem.ref
IL_003f:  ldloc.s    CS$0$0001
IL_0041:  call       object [mscorlib]System.Activator::CreateInstance(class [mscorlib]System.Type,
                                     object[])
IL_0046:  stloc.2
IL_0047:  ldloc.2
IL_0048:  isinst     [System]System.ComponentModel.License
IL_004d:  stloc.3
IL_004e:  br.s       IL_0050

IL_0050:  ldloc.3
IL_0051:  ret

接下来我们要反汇编 CoreLab.MySql.dll
运行 ildasm CoreLab.MySql.dll /out=source.il
这时出现提示信息 "Protected Module"，无法反汇编。这是因为这个动态库增加了SuppressIldasmAttribute属性，从而ildasm不允许反汇编。我们可以很容易制造一个hack过的ildasm.exe版本，方法如下：
用二进制编辑器(如WinHex)打开C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\ildasm.exe
查找SuppressIldasmAttribute，将其修改为任意字符串，保存。

现在重新执行ildasm CoreLab.MySql.dll /out=source.il，得到CoreLab.MySql的il代码，查找以下代码：

Code
  .method public hidebysig virtual instance class [System]System.ComponentModel.License 
          a(class [System]System.ComponentModel.LicenseContext A_0,
            class [mscorlib]System.Type A_1,
            object A_2,
            bool A_3) cil managed

Code
  Type type = (a == null) ? Type.GetType("CoreLab.MySql.Entity.MySqlEntityProviderServices, CoreLab.MySql.Entity, Version=4.85.35.0, Culture=neutral, PublicKeyToken=09af7300eec23701", false) : a.GetType();
    if (type == null)
    {
        Assembly assembly = Assembly.Load("CoreLab.MySql.Entity, Version=4.85.35.0, Culture=neutral, PublicKeyToken=09af7300eec23701");
        if (assembly != null)
        {
            type = assembly.GetType("CoreLab.MySql.Entity.MySqlEntityProviderServices");
        }
    }

把这里的PublicKeyToken=09af7300eec23701替换成我们刚才自己产生的KeyToken, a603cb3085449c2c。

好了，现在可以重新编译 CoreLab.MySql.dll 了，运行以下命令：
ilasm source.il /dll /key=key.snk /out=CoreLab.MySql.dll

接下来我们修改CoreLab.MySql.Entity.dll对CoreLab.MySql.dll的引用。
  1) 反汇编IL
   ildasm CoreLab.MySql.Entity.dll /out=entity_source.il
  2) 查找 .assembly extern CoreLab.MySql
   将publickeytoken改成上面产生的新key，每个字节用空格隔开
  3) 重新编译
   ilasm entity_source.il /dll /key=key.snk /out=CoreLab.MySql.Entity.dll

对DLL和强名称的修改完成后，我们可以重新注册这些DLL并且使用了。

5、注册GAC
     gacutil /i CoreLab.MySql.dll
     gacutil /i CoreLab.MySql.Entity.dll
     如果打开C:\Windows\Assembly，我们现在应该可以看到两个版本的DLL，一个是原始版，一个是修改版

6、最后一步，修改machine.config使用修改版Data Provider.
    编辑 C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config
    找到以下这一段配置：
      <add name="MyDirect .NET" invariant="CoreLab.MySql" description="CoreLab MyDirect .NET"
        type="CoreLab.MySql.MySqlDirectFactory, CoreLab.MySql, Version=4.85.35.0, Culture=neutral, PublicKeyToken=09af7300eec23701" />
   将PublicKeyToken改成我们的key

大功告成~!

public class TestClass : MarshalByRefObject { 
    public string Call(int i) { 
        long t1 = DateTime.Now.Ticks; 
        if ( i % 2 == 1 ) 
            System.Threading.Thread.Sleep( 3000 ); 
        long t2 = DateTime.Now.Ticks; 
        return string.Format( "Hello [I={0},T={1}]", i, t2 - t1 ); 
    } 
} 

　　客户端，执行 (new ClientTest ()).Run()：

class ClientTest { 
    public void Run() { 
        ChannelServices.RegisterChannel( new TcpClientChannel() ); 
        for ( int i = 0; i < 2; i++ ) 
        { 
            Thread t = new Thread( new ThreadStart( Test ) ); 
            t.Start(); 
        } 
    } 

    int i = 0;

    private void Test() { 
        int t = i++; 
        TestClass tc = (TestClass) Activator.GetObject( 
           typeof( TestClass ), "tcp://localhost:8086/Test" ); 
        Console.WriteLine( tc.Call( t ) ); 
    } 
} 

　　运行这个测试程序，发现有3种情况：
　　1、正常运行后两个线程几乎都是在3秒以后，返回：
　　　　Hello [I=0, T=0] Hello [I=1, T=30000384]
　　2、用SockMon监视网络的时候，再运行测试程序，
　　　　I=0的消息马上返回，I=1的是3秒以后返回。这个结果应该是正常的。
　　3、用RemotingConfiguration.Configure( "Client.exe.config" ); 替换掉
　　　　ChannelServices.RegisterChannel( new TcpClientChannel() );
　　　　也就是说用配置文件注册通道的时候，
　　　　不管SockMon有没有开启，测试程序的结果也都是正常的，同第2种情况。

　　这第2和第3两种情况着实让人郁闷，出现测试结果全然不同的原因是什么？服务端到底是怎样处理的？让我们先来看看跟踪数据：

No.	对象	线程	Local Port	Remote Port	操作	备注
1	Server	4584	8086		绑定端口并开始监听	发生在信道注册 ChannelServices .RegisterChannel
2	Client	5132	2296	8086	连接并发送请求tcp://localhost:8086/Test	发生在远程方法调用 tc.Call( t )，t = 0
3	Client	4276	2297	8086	连接并发送请求tcp://localhost:8086/Test	发生在远程方法调用 tc.Call( t )，t = 1
4	Server	780	8086	2096	返回信息 Hello [I=0, T=0]
5	Client	5132	2296	8086	接受到 Hello [I=0, T=0]
6	Server	780	8086	2096	返回信息 Hello [I=1, T=30000384]
7	Client	4276	2297	8086	接受到 Hello [I=1, T=30000384]

　　我们来大致回顾一下这个流程。首先Server端在信道注册(ChannelServices.RegisterChannel)以后，就会立即在指定端口开始监听。然后Client开始创建第一个TestClass。并调用它的远程方法Call()。这时，Client选取一个新的端口(2296)与服务器进行通信请求。然后我们看到第二个线程(ID:4276)里又创建一个TestClass，并在新端口(2297)上连接服务器。
　　到这一步为止，我们可以看到非常重要的一个事实，就是执行 Activator.GetObject() 时，实际上并没有访问网络。
　　只有在实际调用远程方法的时候，Remoting才实际开始通过网络通信向服务器请求处理。对于在服务器端激活的SAO对象来说，也正是在这个时候创建远程对象（注：Singleton在全局范围内只创建一个对象实例，SingleCall则为每个客户端创建一个对象实例，所以实际上这个时候并不一定全都是创建新的对象实例）

　　其次，Client在不同的线程当中，使用了不同的端口与服务器通信。也就是说开启了两个网络连接。而在测试代码中，不管是通过配置文件，还是通过代码注册信道，我们实际上都只注册了一个TcpClientChannel。在这一点上还是有些疑问... 另外，对于客户端信道来说，似乎无法指定其端口。每次系统都无视我指定的端口，而自行开启别的端口进行通信 -_-

　　好了，我们从No.4继续。可以看到Server分别处理了Call(0), Call(1)两个调用。而且I=0的时候，中间没有进行线程休眠，所以处理耗时基本为0。但是我注意到，Server在实际处理远程调用时，是用了另外一个线程(ID:780)。也就是说，在Server端，4584线程负责监听，而780线程则另外开辟用来处理客户请求。而且，对于Client在2296和2297两个端口上的请求，Server端用的是同一个线程进行处理！

　　等等，有没有可能是这样一种情况：
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　   /-----线程A
　　SERVER(4584线程）：监听 ____/----780线程：负责联络ClientA -------\-----线程B
　　　　　　　　　　　　　　　  　　 \----XXX线程：负责联络ClientX------/----线程C
　　　　　　　　　　　　　　　　　　　　　　　　　　　    　　　　　    　\----线程D

　　也就是说主监听线程在接受到不同客户端发来的请求时，开辟新的通信线程与客户进行沟通。而每个通信线程只负责网络层的传输，仍不负责实际的远程处理，而是再开辟新的多线程分配任务的处理呢？似乎有这样的可能，因为这样的好处是实现真正的并发处理。不管客户端是单线程还是多线程，只要有请求过来，都会立即交去处理。

　　我们把代码稍微改动一下，注释掉 TestClass.Call() 方法里的 // if ( i % 2 == 1 ) ，这样只要调用Call()，结果都会在3秒以后返回。
　　测试结果，在网络跟踪上与上一次无异。但是两个 Hello 几乎是在3秒以后同时出现。这也就说明了服务端两个Call()方法差不多是同时调用的。但这次客户端的两个请求，在网络层的跟踪看来，仍然是在一个通信线程(780)里进行。这就验证了我在上面的猜想有可能是正确的。因为通过SockMon跟踪到的线程，只是Socket相关的线程，并不能代表所有的线程的使用情况。很可能远程方法是由哪个未知名的线程完成的。

　　我们再来做今天最后一个测试。同时开两个Client。代码修改如下：

public class TestClass : MarshalByRefObject { 
    public string Call() { 
        return string.Format( "Hello " + this.GetHashCode().ToString() ); 
    } 
} 
class ClientTest { 
    public void Run() { 
        ChannelServices.RegisterChannel( new TcpClientChannel( 
        "Channel" + this.GetHashCode().ToString(), 
        new BinaryClientFormatterSinkProvider() ) ); 

        TestClass tc = (TestClass) Activator.GetObject( 
           typeof( TestClass ), "tcp://localhost:8086/Test" ); 
        Console.WriteLine( tc.Call() ); 
    } 
} 

　　先开启一个Server，然后执行两个Client。

　　我们看到，这回Server一个监听线程(4008)，两个Client分别使用不同的线程和端口，这点和之前的情况差不多。但是这次Server针对Client1和Client2终于使用了两个不同的通信线程。那么Remoting怎么区分通信线程呢？我想是根据我们注册的信道。之前我们一个Client两个线程，都是通过同一个 TcpClientChannel。所以Server也相应的用同一个通信线程。而现在每个Client都使用独立的信道，Server端相应的也使用不同的网络连接。

　　总结来说，Server端有一个主线程在我们创建ServerChannel时所指定的端口上负责监听。当客户端有请求时，Server为每一个ClientChannel分配一个辅助通信线程和一个专门的网络连接。在每一个信道上，可以同时处理多个请求。

　　顺便提一下，通过网络跟踪还验证了这句话：
　　MSDN:TcpChannel 打开并缓存与当时正在向另一个服务器发出请求的线程一样多的连接。客户端上的套接字连接将在处于不活动状态 15-20 秒钟之后关闭。

　　在15秒未进行操作后，两个Channel在服务器和客户端的通信线程均被结束。