WCF：与非 .NET Web 服务共享库
我已将 Sonic ESB 进程公开为 Web 服务，并编写了一个 .NET 应用程序，通过调用其方法将数据上传到该进程。
为此，我在 .NET 端有一个复杂对象库，我以 xml 格式将其添加到 Sonic ESB 端的 Web 服务定义中。这是公开 Sonic ESB 进程的必要步骤，因为要调用的方法应该能够识别从 .NET 应用程序传递的对象。
但是，当我尝试将服务引用添加到 .NET 应用程序时，同一库在服务的每一侧被视为两个不同的库，因为它们被分配给不同的命名空间。确保在创建服务引用时选中“重用引用程序集中的类型”不会产生任何影响：彼此对应的不同类型是分开的。
因此，以下代码会产生错误：
public string PushManifest(FargoGate.DtoLib.OutboundFargoMessage message)
{
FargoGateOnRampWSRequest wsRequest = new FargoGateOnRampWSRequest();
OutboundFargoMessage outMessage = new OutboundFargoMessage();
//TODO ERROR: Cannot convert source type 'FargoGate.DtoLib.OutboundMessage' to target type 'PollFargoJob.FargoGateOnrampWS.OutboundFargoMessage'
wsRequest.OutboundFargoMessage = message;
throw new NotImplementedException();
}
任何建议将不胜感激！
I have exposed a Sonic ESB process as a webservice and wrote a .NET application to upload data to it by calling its methods.
To this end, I have a library of complex object on the .NET side that I added in xml format to the web service definition on the Sonic ESB side. This is a necessary step in exposing the Sonic ESB process, because the methods to be called should be able to recognize the objects being passed from the .NET application.
However, when I try to add the service reference to the .NET application, the same library is treated as two different ones on each side of the service, because they are assigned to different namespaces. Making sure that 'Reuse types in referenced assemblies' is checked when creating the service reference makes no difference: The different types corresponding to one another are kept apart.
The following code thus yields an error:
public string PushManifest(FargoGate.DtoLib.OutboundFargoMessage message)
{
FargoGateOnRampWSRequest wsRequest = new FargoGateOnRampWSRequest();
OutboundFargoMessage outMessage = new OutboundFargoMessage();
//TODO ERROR: Cannot convert source type 'FargoGate.DtoLib.OutboundMessage' to target type 'PollFargoJob.FargoGateOnrampWS.OutboundFargoMessage'
wsRequest.OutboundFargoMessage = message;
throw new NotImplementedException();
}
Any suggestions would be greatly appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我最近遇到了类似的问题，很少有链接可以帮助我解决，要点是尝试使用像 SVCUTIL 这样的工具，而不是使用 VS：
http://kjellsj.blogspot.com/2008/06/wcf-using-shared-types.html
http://msdn.microsoft.com/en-us/library/aa702581.aspx
i confronted the similar problem recently, there are few links that helped me out, the main point is try to use tools like SVCUTIL, not with VS:
http://kjellsj.blogspot.com/2008/06/wcf-using-shared-types.html
http://msdn.microsoft.com/en-us/library/aa702581.aspx
尝试单独的 Web 服务中的相同类型，特别是那里的第一个答案。
我不清楚你在做什么，但似乎这就是你所需要的。
Try Identical Types In Separate Web Services, and specifically the first answer there.
I don't have a clear picture of what you're doing but it seems like that's what you need.
在我看来，我根本不需要 svcutil.exe，正如建议的那样，而是继续使用 xsd.exe 生成数据模型的架构。我这样做只是为了确保服务双方的数据模型完全相同。但是，由于某种原因，我无法正确创建 Web 服务，因为每当我尝试使用更新的架构时，Sonic Workbench 都会不断崩溃。也许架构对于 Workbench 来说太复杂而无法处理？
好吧，我现在用一个肮脏的伎俩解决了这个问题。我没有使用 WCF，而是使用标准 .NET 2.0 方式来注册 Web 服务。在 Sonic ESB Web 服务中，我将输入参数类型设置为字符串，而不是库中的数据类型。在调用 Web 服务操作的 .NET 代码中，我将对象序列化为 xml 并将结果字符串传递给 Web 服务。
因此，我传递的不是序列化对象，而是包含序列化对象 xml 的字符串。这似乎有效！
我知道这是一个糟糕的解决方案，但我很绝望。
It would seem to me that I do not need svcutil.exe at all, as is suggested, but rather continue generating the schema for the data model using xsd.exe. I did just that to ensure that the data model was exactly the same on both sides of the service. However, for some reason, I could not create the webservice properly, as Sonic Workbench keeps on crashing whenever I try with the updated schema. Perhaps the schema is too complex for Workbench to handle?
Well, I now solved it by using a dirty trick. Instead of using WCF I am using a standard .NET 2.0 way of registering the webservice. In the Sonic ESB webservice, I set the input parameter type to string, rather than the data type from the library. In the .NET code calling the webservice operation, I serialize the object to xml and pass the resulting string to the webservice.
So instead of passing a serialized object, I am passing a string containing the xml of a serialized object. And that seems to work!
It's a bad solution, I know, but I am desperate.