谢谢 但是这样相当我得改我的接口了 现在能不能不这样做比如 我想把lamda表达式 转换成表达式树这样可以吗？

@魔方菜鸟: 你能明白为什么 remoting 服务传递对象时需要先序列化吗？

@Launcher: 序列化不是为了 在两个程序间的通道传递数据吗？

@魔方菜鸟: 由于你目前的接口使用了无法序列化的类型，你是不是应该将其修改为可序列化类型？你是不是就必须得修改你的接口？

@Launcher: 首先谢谢您能够耐心的给我回复。 你说的确没错。  如果这样的话我得重新改我的业务了。其实我这样做的目的是想让客户端这边 根据不同的业务去创建表达式树，然后service 去解析表达式树， 这样我service 这层能简化。 现在我就考虑 能不能客服这个序列化！  

@魔方菜鸟: 请问，你是不是要将一个客户端建立的表达式树传递给服务端？

@Launcher: 是的 。

@魔方菜鸟: 我的服务端这个接口 会有多个客户端调用。  我如果 让他传递string  这样太危险了。  因为 表达式目的就是为了让他传输 表达式树的条件  。  Expression<Func<T, bool>> ） 最后转换成一个 sql 的条件。 

@魔方菜鸟: 要传递表达式树，你是不是需要对表达式树做序列化和反序列化操作？

@Launcher: 嗯 是的。 

@魔方菜鸟: 那我提供给你的两个链接的文章，是不是旨在解决表达式树序列化的问题（虽然尚有 BUG）？

@Launcher: 嗯  是的 我看了 但是相当把我接口改变了。 好吧  我想现在 也只能这样了 如果想解决这个问题只能这样了 谢谢你了！ 

@魔方菜鸟: “ Expression<Func<T, bool>> ） 最后转换成一个 sql 的条件” 如果仅仅是这样的一个场景的话，那么你自己提出的解决方案是不恰当的，最佳的方式是服务端使用 EF 操作数据库，使用 Dynmic-LINQ（http://dynamiclinq.codeplex.com/） 转换客户端提交的条件，它允许客户端提交字符串形式的查询表达式，服务会将查询表达式解析为 Expression<T> 对象，然后将其传递给 DbContext 执行查询。

@Launcher: 现在是我的服务端是用的 ado.net 原生的 Expression<Func<T, bool>> 只是  用了一个第三方的库把 表达式树转换成条件语句  然后在拼接上。