如何在WCF中序列化.NET非原始类型System.DirectoryServices.AccountManagement.PrincipalContext？

首先得明确核心点：System.DirectoryServices.AccountManagement.PrincipalContext这个类从设计上就不是用来跨服务边界传输的——它是一个操作Active Directory的上下文对象，包含连接状态、域资源等运行时信息，本身就不适合被序列化和传递。针对你的三个疑问，我来逐一拆解：

1. 如何让.NET框架自带的非序列化类型实现序列化？ #

你没法直接给框架原生类添加[DataContract]或[DataMember]特性（除非修改程序集，这显然不现实）。可行的方案有两种：

• 方案一：用DTO（数据传输对象）封装需要的信息
  不要直接返回PrincipalContext，而是提取你业务需要的关键信息（比如域名、上下文类型等），封装成自己的自定义类并标记数据契约特性。比如：

  [DataContract]
  public class PrincipalContextInfo
  {
      [DataMember]
      public ContextType ContextType { get; set; }
      [DataMember]
      public string DomainName { get; set; }
  }
  

  然后修改服务方法：

  public PrincipalContextInfo GetPrincipalContextInfo()
  {
      var domainName = GetUserDomainName();
      return new PrincipalContextInfo
      {
          ContextType = ContextType.Domain,
          DomainName = domainName
      };
  }
  

  客户端拿到这个DTO后，可以自行在本地创建PrincipalContext实例。

• 方案二：使用序列化代理（Surrogate）
  WCF支持通过ISerializationSurrogate为不可序列化类型提供自定义序列化逻辑，但这个方案复杂度高，而且PrincipalContext包含的运行时连接状态无法被有效还原，序列化后的对象大概率无法正常工作，所以不推荐。

2. MSDN文档为啥没有这种场景？ #

因为PrincipalContext属于操作类，而非数据实体类。WCF的设计初衷是跨服务传递承载数据的对象（也就是数据契约），而不是传递这种带有业务逻辑和运行时资源的工具类。MSDN的示例都针对自定义数据实体，这是WCF的典型使用场景——传递数据，而非传递操作上下文。

3. MyWCFService类包含该类型成员时，是否必须让其可序列化？ #

是的！如果你的服务类（或服务方法返回的对象）包含PrincipalContext类型的成员，WCF在序列化时会尝试处理这个成员，一旦发现它不可序列化就会报错。解决办法有两个：

• 把PrincipalContext成员标记为[IgnoreDataMember]，这样WCF会跳过它的序列化。但要注意：这个成员在服务端可以正常使用，但客户端拿到的对象里该成员会是null，如果你的业务逻辑依赖客户端使用这个成员，此方案不适用。
• 彻底不在服务契约（包括服务类、返回对象、参数）里暴露PrincipalContext类型。既然你的核心目的是暴露AD操作功能，那应该在服务端封装好所有AD操作逻辑，客户端只需要调用服务方法获取结果即可，不需要拿到PrincipalContext自己去操作。比如你可以提供GetUserInfo(string username)、ValidateUser(string username, string password)这类具体的业务方法，而非把底层操作对象暴露出去。

总结一下：不要试图序列化和传输PrincipalContext，而是在服务端封装好AD操作，给客户端提供高层的业务方法，或者传递封装后的DTO信息。

内容的提问来源于stack exchange，提问作者user7512953