Question

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.

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. 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?

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 😉

-Edit-

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

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.

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.

I’m very confused.

Answer 1

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.