Last post Jun 13, 2013 01:15 PM by GDB
Jun 09, 2013 10:56 PM|GDB|LINK
If I use Add Service Reference in a WCF client the Fault Contracts are not being included in the generated code. If I use SvcUtil they are. Am I doing something wrong with Add Service Reference, i.e. missing a setting?
Not sure what the protocol is for renaming a thread but we have determined that this is NOT a client issue; the problem is that the service is not being updated when revisions are published, even after IIS is restarted and the app pool is recycled.
Jun 10, 2013 02:17 AM|syed amjad|LINK
where is wcf service deployed, is it with in the same solution are deployed some where else.
Jun 10, 2013 07:16 AM|GDB|LINK
It's deployed in a seperate solution Syed.
If I run svcutil from the assembly folder the Fault Contract properties are included in the generated class. If I run it against the end point url they are not. I obviously need to dig deeper into the scvutil documention because a must be missing a parameter.
Jun 11, 2013 04:18 AM|Illeris|LINK
Please check this sample : http://www.c-sharpcorner.com/uploadfile/SunilBabuYLV/using-the-fault-contracts-soap-faults-in-wcf-programming/
I assume you're not using fault contracts the right way. If this does not solve your issue, please post us some code.
Jun 13, 2013 02:40 AM|Amy Peng - MSFT|LINK
Many people meet the same question as you. When they tried to use the Add Service Reference wizard in Visual Studio, they had a problem: they could not import the fault contracts. But using the Svcutil.exe works.
The difference between Add Service Reference and Svcutil.exe is that one has the UseSerializerForFaults option
easily available to you as a switch on the command line. Using this switch instructs Svcutil.exe to use the XmlSerializer to handle faults instead of the default, which is the DataContractSerializer. In this case, although Svcutil.exe has indicated that the
WSDL for the fault is flawed, it continues to import the service operation.
If you want to enable VS Add Service Reference to do the same thing:
For more information, please try to refer to the following article which tells the details:
Hope it can help you.
Jun 13, 2013 08:28 AM|GDB|LINK
Thanks very much for your efforts to document this solution Amy. I had already tried what you suggested. Unfortunately it does not solve my problem, which, it develops, is
not a problem with FaultContract attributes but one of caching. I was going to add more detail to this thread but wanted to work through to a solution before doing so.
First we can take the client out of the mix altogether for purposes of testing; I can navigate to the site and look at the wsdl.
Regardless of the changes I made to the contact, e.g. renaming a method. the changes were not showing up in the results. I tried stopping and restarting IIS. I tried recycling the app pool. I even deleted the dll. Now for the really strange bit: I created
another little test service, one with a single method. When I published it the new service had successfully replaced the other one. Then I added a method and published it. The new method was successfully added. The I published the problem service but it did
not replace the little test service.
So my working hypothesis right now is that this is an IIS caching issue that I don't understand. I've certainly not encountered anything similar with web applications. I will continue wokring on it and add to this thread when the problem is corrected.
Jun 13, 2013 08:50 AM|sukumarraju|LINK
When ever Service is updated/republished make sure that service reference is updated in client application i.e., Update Service context menu in solution explorer.
Jun 13, 2013 10:17 AM|l.laxmikant|LINK
As you said the WCF service is deployed in seprate application. Check the build version of dlls of hosting application is same as you are making add service reference.
Some time I build the applications in Release mode however while adding reference add it from debug and find nothing updated.
Jun 13, 2013 01:15 PM|GDB|LINK
Issue resolved. It was related to how the svc file was being named. Like I reported above, I started referring to the wsdl on the site so as to bypass the client while I was sorting out why the changes weren't being reflected in the service.
Amy's suggestion was the way I decided to go with client updates. Thanks to all.