之前在开发定制的 .Net 平台 Test Library 时，考虑过是做成 Remote Library 还是 Normal Library。
我更倾向于 Normal Library 的模式。
Remote Library
Remote Library 模式下，Test Library（实现具体功能的 dll 文件）host 在一个独立的进程中，也就是 Remote Server （如：NRobotRemote）。
优点
- 驱动更自由。CPython、IronPython 都行，只要装了相应的 Robot Framework。
缺点
- 对 Keyword 的调用不支持可选参数的模式，必须填写所有参数；
- 能传给 Keyword 的参数类型也太少，经常要在 Keyword 内部 Cast 参数类型；
- 需要额外维护 Remote Server 这个进程。
Normal Library
缺点
- 要调用 .Net Test Library 必须用 IronPython 驱动测试。
- IronPython 的 Built-In 及 第三方库 不及 CPython 丰富，很多第三方 Test Library 也不兼容。对此问题可以：
1. 不用 .Net Test Library。
如果 .Net Test Library 中关键字在具体测试中使用率不高，则尽量用其它方法替代这个 Library。如：《Robot Framework 网页自动化测试中“下载文件”》。
2. 可以启另一个进程去操作，操作完成就销毁这个临时进程。（比 Remote Server 轻）
3. 重新设计 Case。好的 Case 设计可以规避一些这类问题。
如：测 UI 的 Case 只操作 UI；测 SUT 内部逻辑的就做好 Service 层自动化，别管 UI。
Remote 形式的 Normal Library
(2015-07-31更新)
这种模式是指：将 Normal Library 以 Remote 的形式提供服务。（Python Remote Server for Robot Framework）
这种模式除了像 Remote 模式那样需要维护一个额外的 Remote 服务进程外，几乎规避了所有单纯的 Remote Library 或 Normal Library 的缺点；同时又有它们各自的优点。
当然，提供服务的进程驱动必须和 Normal Library 匹配。如：Normal Library 内部调用 .Net Assembly，服务进程就得是 IronPython。
另：搭建这个服务进程比单纯的 Remote Library 服务进程更方便。
from robotremoteserver import RobotRemoteServer
from mylibrary import MyNormalLibrary
RobotRemoteServer(MyNormalLibrary())
