从 LdapConnection 序列化 .NET 类型

发布于 2024-10-20 15:01:40 字数 1393 浏览 1 评论 0原文

我遇到一个问题,因为我正在使用 LdapConnection 向 AD LDS(以前称为 ADAM)数据存储发出请求。美好的。但现在要求能够“远程”执行此操作。基本上,我们可以指望始终能够访问数据存储的程序现在需要通过“内部”网络上的“服务器”程序来完成此操作,以便外部网络上的“客户端”只能通过我们的新“服务器”进行通信程序。我们不能将 AD LDS 服务器暴露给外部是有原因的(不是一个伟大的原因,但确实是一个原因)。但他们希望它“快速”完成,因此不想重新设计客户端应用程序(这应该是真正发生的事情)。因此,我们需要序列化 ​​DataRequestDataResponse 以便往返于“服务器”部分。

大问题:DataResponses 似乎不可序列化。在测试期间,DataContractSerializer 序列化我的 SearchRequest 没有问题,但 SearchResponse 得到的是:

System.Runtime.Serialization.InvalidDataContractException occurred
  Message="Type 'System.DirectoryServices.Protocols.SearchResponse' cannot be serialized. Consider marking it with the DataContractAttribute attribute, and marking all of its members you want serialized with the DataMemberAttribute attribute.  See the Microsoft .NET Framework documentation for other supported types."
  Source="System.Runtime.Serialization"
  StackTrace:
       at System.Runtime.Serialization.DataContract.DataContractCriticalHelper.ThrowInvalidDataContractException(String message, Type type)
  InnerException: 

好的。但这两种类型都没有可序列化或其他类型。那么为什么 SearchRequest 能够顺利完成整个过程,而响应却不能呢?

但这最终并不重要。我应该如何序列化一个我无法更改的类型,因为它内置于 .NET 框架中,并且我无法“重新创建”,因为构造函数是内部的?如果我可以“获取我需要的信息”并在网络连接的另一端重新创建该类,我会这样做,但这些类型没有公共构造函数。

有什么想法吗?我什至想知道为什么即使没有 DataContractSerializer 的正确属性,其中一种类型也“正常工作”,而另一种却不能。

I'm having a problem in that I'm using an LdapConnection to make requests against an AD LDS (formerly known as ADAM) datastore. Fine. But now requirements have come along to be able to "remotely" do this. Basically, a program we could count on always having access to the datastore now needs to do it through a "server" program on the "internal" network, so that the "client" on the external one only communicates through our new "server" program. There's a reason (not a great one, but a reason) why we can't just expose the AD LDS server to the outside. But they want it done "fast" and thus don't want to re-engineer the client app (as should be what's really happening). Thus we need to serialize the DataRequest and DataResponses to go to and from the "server" part.

Big problem: The DataResponses don't seem to be serializable. During testing, a DataContractSerializer has no problem serializing my SearchRequest but the SearchResponse gets this:

System.Runtime.Serialization.InvalidDataContractException occurred
  Message="Type 'System.DirectoryServices.Protocols.SearchResponse' cannot be serialized. Consider marking it with the DataContractAttribute attribute, and marking all of its members you want serialized with the DataMemberAttribute attribute.  See the Microsoft .NET Framework documentation for other supported types."
  Source="System.Runtime.Serialization"
  StackTrace:
       at System.Runtime.Serialization.DataContract.DataContractCriticalHelper.ThrowInvalidDataContractException(String message, Type type)
  InnerException: 

OK. But neither type has Serializable or what not. So why does SearchRequest go through the process fine, and the response doesn't?

But that doesn't even matter in the end. How am I supposed to serialize a type that I can't change, as it's built-in to the .NET framework, and I can't "re-make" because the constructor is internal? If I could just "take the information I needed" and re-make the class on the other end of my network connection, I would, but these types don't have public constructors.

Any ideas? I'd even like to know why one of the types "just works" even without the right attributes for the DataContractSerializer but the other doesn't.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

谈下烟灰 2024-10-27 15:01:40

最好的(也可能是唯一的)方法是创建自己的包装类,然后读取结果并将其存储在类中并序列化。

SearchResponse 实际上是一个 COM 包装器,无法序列化。

The best - and probably only - approach is to create your own wrapper class and then read the result and store in the class and serialise.

SearchResponse in fact is a COM wrapper and cannot be serialised.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文