WCF 无法生成客户端代理 [英] WCF Fails to generate client proxy

问题描述

我有一个奇怪的问题，我似乎无法诊断，这似乎是 PEBCAC 的问题，但我花了很多时间试图解决它.我创建了一个通过 Windows 服务托管的 WCF 服务.这项服务已经运行了一段时间，我有一个 windows 窗体和一个 web 界面.该服务最初是在 XP 上开发的，但我最近迁移到了 Windows 7.当我迁移时，我发现该服务的 Windows 安全性阻止我在 Windows 7 上使用我的 WinForms 应用程序，但它在 XP 上运行得很好Windows Server 2008 R2、Windows 7 和 XP 上的服务.为了在开发过程中简化事情，我完全禁用了安全性，我的 WinForms 应用程序再次在 windows7 上运行.

I have an odd problem that I just can't seem to diagnose, and it seems to be a PEBCAC thing, but I have spent a good deal of time trying to solve it. I created a WCF service that I host via a windows service. This service has been working fine for a while, and I have a windows forms and a web interface to it. The service was originally developed on XP but I have recently migrated to Windows 7. When I migrated, I found out that the windows security for the service prevented me from using my WinForms app on windows 7, yet it worked just fine on XP talking to the service on Windows Server 2008 R2, Windows 7 and XP. To simplify things while in development, I have disabled security completely, and my WinForms app works again on windows7.

然后我对 WCF 服务进行了一些其他更改，添加方法，更改数据协定等.唯一的端点更改是禁用 wshttp 上的安全性.突然，更新 Web 应用程序的服务引用不再创建客户端代理，但它会生成 wsdl 和 xsd 文件.我在 XP 和 Win7 上尝试了许多旧服务和新服务的组合，结果是:

I then made some other changes to the WCF service, adding methods, changing data contracts, etc. The only endpoint changes were to disable security on wshttp. Suddenly, updating the service reference for the web app no longer creates the client proxy, but it does generate the wsdl and xsd files. I have tried numerous combinations of the older and newer service on XP and Win7 with the result that:

1. 旧服务在更新参考时运行良好，无论是在 XP 还是 Win7 上运行，以及网络应用代码是在 XP 还是 Win7 上.
2. 新服务不会创建代理，无论是在 XP 还是 Win7 上运行，以及网络应用代码是在 XP 还是 Win7 上.我没有从服务引用更新中得到任何错误，但是，configuration.svcinfo 和 configuration91.svcinfo 文件没有列出行为、绑定或端点.其余文件看起来不错.
3. 我能够使用 svcutil 获取元数据并使用新版本的服务生成代理代码.
4. 更新服务引用时，我确实在对象资源管理器中显示了作为数据契约一部分的两项，但只有一项是正确的.我没有得到客户端或其他数据契约对象.
5. 最重要的是 Windows 窗体应用程序与新服务配合得很好，包括更新引用和调用服务方法.嗯?

1. The old service works fine when updating the reference, whether it runs on XP or Win7 and whether the web app code is on XP or Win7.
2. The new service does not create the proxy, whether run on XP or Win7 and whether the web app code is on XP or Win7. I get no errors from the service reference update, however, the configuration.svcinfo and configuration91.svcinfo files have no behaviors, bindings or endpoints listed. The rest of the files look fine.
3. I am able to use svcutil to get the metadata and to generate the proxy code using the new version of the service.
4. When the service reference is updated, I do get two of the items that are part of the data contract showing up in object explorer, but only one of them is correct. I get no client, or other data contract objects.
5. The kicker is that the windows forms app works just fine with the new service, including updating the reference and calling the service methods. Huh?

我查看了新服务中的服务、行为和端点定义，它们与旧服务相匹配.网上没有什么我可以找到引用这样的错误.我意识到我一定在新代码中做错了什么，但由于它在 WinForms 应用程序中运行良好，我无法解释其中的差异.

I have looked at the service, behavior and endpoint definitions in the new service and they match the old one. Nothing online that I could find references such an error. I realize that I must be doing something wrong in the new code, but since it works fine with WinForms app, I am at a loss to explain the difference.

任何帮助将不胜感激.也许我可以保留一些头发;)

Any help would be greatly appreciated. Perhaps I can keep some of my hair ;)

-编辑-

阅读答案后，我做了更多的研究并尝试了更多的东西:

After reading the answer I did some more research and tried a few more things:

我在没有安全性的情况下查看了该服务的 xsd 等文件，并且在将事物恢复到具有 DataContract 属性的顶级枚举方面后的状态(没有这些) 并将安全值恢复到以前的状态.在这两种情况下，我都没有发现任何问题，只是文件的命名不同:旧的服务引用使用数字后缀范围为 2 - 5 的 xsd 文件，而最新的使用 1 - 4(看不出这应该影响事物，因为 svcmap 中的指针似乎是正确的).这确实让差异变得更加困难，但我已经详细查看了每个文件，数据似乎是正确的，只是放在不同的文件中.

I have looked at the xsd, etc files for the service with no security and also after restoring things to the way they were in terms of top-level enums with DataContract attribute (have none of these) and also restoring the security values to what they used to be. In both cases, I see nothing amiss, except that the files are named differently: the old service reference uses xsd files with numeric suffixes that range from 2 - 5, whereas the latest one uses 1 - 4 (can't see that this should affect things, since the pointers in the svcmap seem correct). It does make it more difficult to diff things, but I have looked at each file in detail and the data seems correct, just placed into different files.

安全恢复到旧值后，wsdl 文件与预期的一样，除了主机 IP 和机器名称之外.但是 configuration.svcinfo 和 configuration91.svcinfo 仍然没有定义端点、行为或绑定.此外，奇怪的是，在定义的两个数据契约中，一个只有一个新成员:它的数据成员不存在.这是一个数据协定，它引用一个标记为 Serializable 的类，但未与 DataContract 属性一起列出.唯一改变的是我向类中添加了一个新的字符串成员.更奇怪的是，xsd 文件中对数据契约类有正确的定义.

The wsdl file, after security is restored to the old values is identical except for the host IP and machine name, as expected. But still the configuration.svcinfo and configuration91.svcinfo have no endpoints, behaviors or bindings defined. Also, oddly, of the two data contracts that do get defined, one only has a New member: its data members are not present. This is a data contract that references a class that is marked as Serializable, but is not listed with a DataContract attribute. The only thing that has changed there is that I added a single new string member to the class. What is even more odd is that there is a proper definition of the data contract class in the xsd files.

我很困惑.

推荐答案

好吧，经过一番折腾，我终于弄明白了.问题是由于我在 Web 应用程序中使用的程序集与服务中使用的程序集相同(我在 Web 应用程序中使用了程序集的不同部分).这导致作为数据契约一部分的类，并且我已修改该类以在 Web 应用程序的编译程序集中与服务的发布不同.这反过来导致服务引用无法生成客户端代理.如果没有客户端代理，我的 Web 应用程序代码会显示错误，因此我从未尝试编译解决方案.简单的答案是只在 Web 应用程序中构建公共程序集(有效)，然后服务引用正确生成代理.想象一下，如果一个类的单个数据成员成为问题的明显原因，我是多么困惑，但它的名称、数据类型、在代码中的位置等对问题没有影响！无论如何，无论如何，重用这个程序集可能是糟糕的设计 - 可能更好地使用来自服务本身的信息.最后要说明的是，winform 应用程序运行的原因是因为我也在 winform 应用程序中使用了相同的程序集，并且在我编译应用程序时它始终保持最新状态，因此更改从未发生冲突.希望这对未来的人有所帮助.作为对 Microsoft 的旁注 - 有关此冲突的任何错误信息都将极大地帮助排除故障，尽管我承认这可能不是常见情况.

Well, after a lot of futzing about, I eventually figured this out. The problem was caused by my using the same assembly in the web app as is used in the service (I used a different portion of the assembly in the web app). This caused a class that is part of a data contract and that I had modified for the service's use to be different in the web app's compiled assembly than the service was publishing. This in turn caused the service reference to fail to generate the client proxy. Without the client proxy, my web app code showed errors and so I never tried to compile the solution. The simple answer was to build only the common assembly in the web app (which works) and then the service reference generated the proxy properly. Imagine how perplexed I was to have a single data member of a class be the demonstrable cause of the problem, but its name, data type, position in the code, etc. had no effect on the problem! Anyway, probably bad design to be reusing this assembly anyway - likely better to consume this information from the service itself. As a final note, the reason that the winform app worked was because I also use the same assembly in the winform app and it was always being kept up-to-date when I compiled the app, so the changes never conflicted. Hope this helps someone in the future. As a side note to Microsoft - any error information about this conflict would have helped immensely in trouble-shooting, though I grant that it is probably not a common scenario.

这篇关于WCF 无法生成客户端代理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！