Develop Reference

how to add encodingStyle to soap client using c#

the data I send to a web service, gets there with some strange characters.
so the web service developer asked me to add this code to the soap envelope:
soap:encodingStyle=http://www.w3.org/2003/05/soap-encoding
I tried adding this code, but it did not work:
MessageHeader aMessageHeader =
MessageHeader.CreateHeader("encodingStyle", "http://tempuri.org",
"2003/05/soap-encoding");
OperationContext.Current.OutgoingMessageHeaders.Add(aMessageHeader);
how do i add to the soap:envelope a encodingStyle attribute in c#?

I had the same issue as you reported. I found that this was a reported issue in the WCF.
https://github.com/dotnet/wcf/issues/3870
For the fix, I updated the following NuGet packages in my project from version "4.4.*" to "4.7.0"
System.ServiceModel.Duplex
System.ServiceModel.Http
System.ServiceModel.NetTcp
System.ServiceModel.Security
It now includes the "encodingStyle" attribute in the correct location.

What generates a WebServiceRef Reference.cs file?

Working with inherited code that reads data from one database (Visual Fox Pro) and stores it in SQL server. These are separate systems and use a WebService to send XML containing data from VFP.
A field has been added to both databases, and data has been seeded in the VFP database, but we are having problems with the WebService that is meant to sync the data. The WebService seems to be correctly generating and sending XML (with the new field and data) however it appears that the models that are meant to handle it on the .NET application are not being generated correctly and do nothing with this new field.
While viewing the object browser there is an 'OnlineAudienceWebServiceRef' within that, there is an OnlineAudienceDAL.OnlineAudienceFoxProRow which appears to contain a description of columns of the model. We are trying to add a new column to this Object (to receive the new data) but it appears auto-generated.
My question is, fundamentally, what is happening when Visual Studio is linked to a WebService? What files are generated, and how are they generated?
Given the web service correctly sends the new data, I was expecting Refs to be updated upon clicking 'Update Web Reference' from the solution explorer, but apparently that is not the case, and I would like know know what is going on.
There is an 'OnlineAudienceDAL.xsd' where we have added the new column, but we do not see that impacting the Object that is used to read the data.
According to App.config the app is using .NET v4, we are using Visual Studio 2010.
I am not familiar with .NET and the many things that are going on here, and would like to be pointed in a good direction. Sorry if this is confusing, please let me know what information I might be omitting and if anything is unclear.
Thank you for any help.

This is an example the Command Line Utility used by visual studio to generate the web service manually IF you have the WSDL (or XSD) file in a local folder. (WSDL is the Web Service Definition File)
This is in a batch file in my case... and also generates a VB file, but is easy to switch to C# I'm assuming with the last command line argument.
cd C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin
wsdl.exe "c:\development\WebServiceClients\CORE_Webservice_Interface_WS.wsdl" /fields /n:Telus /out:"c:\Development\output\WebServiceClients\referencefile.vb" /l:VB
WSDL.EXE is the core of this... below are the options...
c:\Program Files (x86)\Microsoft Visual Studio 8\SDK\v2.0\Bin>wsdl /?
Microsoft (R) Web Services Description Language Utility
[Microsoft (R) .NET Framework, Version 2.0.50727.42]
Copyright (C) Microsoft Corporation. All rights reserved.
wsdl.exe -
Utility to generate code for xml web service clients and xml web services
using ASP.NET from WSDL contract files, XSD schemas and .discomap
discovery documents. This tool can be used in conjunction with disco.exe.
wsdl.exe ...
OPTIONS -
-
A url or path to a WSDL contract, an XSD schema or .discomap document.
/nologo
Suppresses the banner.
/language:
The language to use for the generated proxy class. Choose from 'CS',
'VB', 'JS', 'VJS', 'CPP' or provide a fully-qualified name for a class
implementing System.CodeDom.Compiler.CodeDomProvider. The default
language is 'CS' (CSharp). Short form is '/l:'.
/sharetypes
Turns on type sharing feature. This feature creates one code file with
a single type definition for identical types shared between different
services (namespace, name and wire signature must be identical).
Reference the services with http:// URLs as command-line parameters
or create a discomap document for local files.
/verbose
Displays extra information when the /sharetypes switch is specified.
Short form is '/v'.
/fields
Generate fields instead of properties. Short form is '/f'.
/order
Generate explicit order identifiers on particle members.
/enableDataBinding
Implement INotifyPropertyChanged interface on all generated types
to enable data binding. Short form is '/edb'.
/namespace:
The namespace for the generated proxy or template. The default namespace
is the global namespace. Short form is '/n:'.
/out:
The filename or directory path for the generated proxy code. The default
filename is derived from the service name. Short form is '/o:'.
/protocol:
Override the default protocol to implement. Choose from 'SOAP',
'SOAP12', 'HttpGet', 'HttpPost'.
/username:
/password:
/domain:
The credentials to use when connecting to a server that
requires authentication. Short forms are '/u:', '/p:' and '/d:'.
/proxy:
The url of the proxy server to use for http requests.
The default is to use the system proxy setting.
/proxyusername:
/proxypassword:
/proxydomain:
The credentials to use when the connecting to a proxy server that
requires authentication. Short forms are '/pu:', '/pp:' and '/pd:'.
/appsettingurlkey:
The configuration key to use in the code generation to read the default
value for the Url property. The default is to not read from the config
file. Short form is '/urlkey:'.
/appsettingbaseurl:
The base url to use when calculating the url fragment. The
appsettingurlkey option must also be specified. The url fragment is
the result of calculating the relative url from the appsettingbaseurl
to the url in the WSDL document. Short form is '/baseurl:'.
/parsableerrors
Print errors in a format similar to those reported by compilers.
ADVANCED -
/server
Server switch has been deprecated. Please use /serverInterface instead.
Generate an abstract class for an xml web service implementation using
ASP.NET based on the contracts. The default is to generate client proxy
classes.
/serverInterface
Generates interfaces for server-side implementation of an ASP.Net
Web Service. An interface is generated for each binding in the wsdl
document(s). The wsdl alone implements the wsdl contract (classes
that implement the interface should not include either of the following
on the class methods: Web Service attributes or Serialization
attributes that change the wsdl contract). Short form is '/si'.
/parameters:
Read command-line options from the specified xml file. This allows you
to specify options not available from command line such as choosing
which type of asynchronous programming model is generated. For details,
please see the tool documentation. Short form is '/par:'.

Error when trying to add a Service Reference

I´m trying to create a client in C# to a web service which (I suppose) is written in Java. It´s my first time trying to write a client, so I´m following the instructions on MSDN, but I´m stuck on a problem with Add Reference. When I open the Add Service Reference dialog and add the URL, an error occurs:
There was an error downloading 'http://geoportal.cuzk.cz/WCTService/WCTService.svc'.
The request failed with HTTP status 404: Not Found.
Metadata contains a reference that cannot be resolved: 'http://geoportal.cuzk.cz/WCTService/WCTService.svc'.
There was no endpoint listening at http://geoportal.cuzk.cz/WCTService/WCTService.svc that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
The remote server returned an error: (404) Not Found.
If the service is defined in the current solution, try building the solution and adding the service reference again.
What should my next step be? I don´t know what I should do with this!
(It is a coordinates-transformation service from the Czech Republic.)
For more information:
Property services (GetCapabilities)
http://geoportal.cuzk.cz/WCTService/WCTService.svc/get?
Localization services:
http://geoportal.cuzk.cz/WCTService/WCTService.svc/get?request=GetCapabilities&service=WCTS

I was facing a similar situation in which I had created a WCF Service (Employee.svc) and later changed the named to EmployeeService.svc. WCF project compiled just fine but when I was trying to add service reference from by UI Client, I was getting following error:
Metadata contains a reference that cannot be resolved: 'http://localhost:2278/EmployeeService.svc?wsdl'.
The document format is not recognized (the content type is 'text/html; charset=UTF-8').
Metadata contains a reference that cannot be resolved: 'http://localhost:2278/EmployeeService.svc'.
There was no endpoint listening at 'http://localhost:2278/EmployeeService.svc' that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
The remote server returned an error: (404) Not Found.
If the service is defined in the current solution, try building the solution and adding the service reference again.
I resolved it by replacing the correct service class name everywhere. In my case, it should have been EmployeeService and NOT employee. The left out place was in the markup code of svc file:
<%# ServiceHost Language="C#" Debug="true" Service="WCFServiceHost.**Employee**" CodeBehind="EmployeeService.svc.cs" %>
Changed it to
<%# ServiceHost Language="C#" Debug="true" Service="WCFServiceHost.**EmployeeService**" CodeBehind="EmployeeService.svc.cs" %>
And it started working again!!! Dont forget to build your WCF project after changing the service name.

I tried browsing to http://geoportal.cuzk.cz/WCTService/WCTService.svc?wsdl. It looks like this service is not exposing metadata.
I did a bit of googling on OpenGIS, and I think you need to have a look at this article:
OpenGIS with .NET
You won't be able to just add a service reference and go. It looks like you need to craft a concrete WSDL.
There may be a client-side library you can use / customize to assist with integration. Have a look at Stack Overflow question Using MySQL GeoSpatial data types in .NET.

I know this is an old thread and has already been resolved, but I just finished troubleshooting this exact issue, and none of the resolutions presented here worked for me. Wanted to share my resolution in case anyone else runs into this thread with a similar issue.
My ENTIRE issue stemmed from a bad Refactor->Rename operation. I recently purchased Resharper for my dev team and Resharper did not like the name of our service implementation name. We had named it "WCFAccess" and Resharper wanted the name "WcfAccess". I had just published an update, had the release safely isolated in its own release branch in git, and figured this was a good time to perform a rename on the develop branch and shut Resharper up about the naming. I used Refactor->Rename to change the name of the file to match the naming convention we had defined in the Resharper configuration. The rename operation completed, the solution compiled and ran, time goes on and the WCF rename was forgotten.
Fast forward a couple weeks, and its time to deploy out web services to the test environment for regression testing. The solution compiled successfully, published successfully, then gave me the EXACT error that the OP posted. What I ended up finding out is that the Rename operation from weeks ago ONLY UPDATED SOURCE CODE REFERENCES to the old name and did not rename MARKUP. When I navigated out to our web server where the service was published to and double clicked on the .svc file, it opened the markup in Visual Studio and I noticed that the character casing of the CodeBehind="ServiceNameHere.svc.vb" was inconstant with the new naming convention. Updating the markup and web.config files to reference the correct character casing resolved my issue.
I hope this helps someone. It was incredibly frustrating to troubleshoot
(Please don't hate me for using VB.Net, I inherited this application) :-)

Is the service definitely up and running before you try to add a service reference? If it exposes meta data, does it have a service behaviour or equivalent configured? Have you configured your firewall correctly?

While adding service reference to the client application, metadata is not accessible from service to client application. hence The remote server returned an error: (404) Not Found. Actually we can host the WCF service as follows:
Self hosting(console application)
IIS Hosting
WAS Hosting
window service hosting.
if you are using self hosting then you need to host the service in console application and run the service(run the console application) and then add the service reference to the client application, then metadata would be exchange. If service is not running then while adding service reference to the client application then 404 not found error would be getting. Same process would follow for all the hosting type. first run the service then add service reference.

I had the same problem happen to me earlier today. The webservice was running fine on local host but for some reason, I was having a 400 when trying to add the service reference in another project.
My error was caused by setting the [DataMember] annotation instead of the [EnumMember] annotation on an enum of the service. Changing it solved my issue.

The webservices doesn't run.
If you don't have access to the server where this service run, you're blocked.
Otherwise, you need to check if the server run, etc. As I don't know how the Java webservice is run, I can't help you further.

Does myAssembly.xmlSerializer.dll always get generated?

I have a web service that does not use any xml attributes for serialization. I just return a string from the web service. In this case, does a serialization dll get created?
The reason I ask is I keep seeing c:\windows\temp\xxxxx.dll (where xxxxx is a random sequence of characters) every couple of weeks the web service is running. One solution is to pre-compile using sgen.exe and that might solve the problem.
Also, I saw a link that said only do this for client side libraries, but this error is on the web service side (server side), so can I still use sgen.exe?
JD

Every time you call the XmlSerializer constructor it will check the type you are trying to serialize and it will generate a temporary assembly. If the assembly already exists it will reuse it. So if your web service is a classic ASMX service it will use XmlSerializer on every request, no matter the return type. These temporary assemblies are part of the serialization process and in my opinion you shouldn't worry too much about them.

WCF proxy generated from WSDL, proxy method returns null

I've generated a WCF proxy from a WSDL file, but now when I call the proxy methods, they return null. I've enabled message logging, and can see that the messages from the server are correctly returned.
I've checked the answer of this question, but in my case at least the name of the returned object was the same in the message and in the WSDL. I still believe the problem has to do with the WSDL file, since it is not fetched the usual way through the "?wsdl" URL (it is a 3rd party webservice), but was given separately.
The return type of the method is just a string.
Has anyone else had similar problems, and what was the corresponding solution, if any? What is the most likely source of the problem?
Re-edit:
It is a RPC/Encoded web service. As written, I can see the SOAP response through message logging, but WCF seems not to be able to parse the information.
The message part of the response from the service looks like this:
<ns1:ServiceResponse soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="the target namespace">
<ns1:ReturnValue xsi:type="xsd:string">
However, when inspecting the outgoing message from my client, it's different:
<ns1:ServiceRequest soapenv:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:ns1="the target namespace">
<RequestValue xsi:type="xsd:string" xmlns="">
So maybe the proxy expects the response to have the same namespace structure, and thus fails to parse it.
I've tried to change the type attribute to element in the wsdl message definitions, and adding some new elements in the types part of the wsdl definition, but then the svcutil chokes when generating the proxy, complaining that there's a clash between the inferred style document and specified style rpc.
From the WSDL specification, section 3.5:
If use is encoded, then each message part references an abstract type using the type attribute.
But then I'm a bit confused, since it doesn't seem to have been a problem in this question. What would be needed to make a similar change, with the restriction that it is a RPC/encoded service?

You'll have to give specifics about the Java service in order to resolve this. However, I suspect that the Java service is using message parts defined with the type attribute. These do not conform to WS-I Basic Profile 1 because there is ambiguity about which namespace should be used for the elements of the message. Some services will use the namespace of the type, while others will (correctly) use the namespace of the web service itself.
Using the element attribute removes the ambiguity, and is therefore preferred.
Please post a snippet of the WSDL containing one of the messages you're having trouble with. When you then compare the definition of the message with what you're seeing on the wire, and then compare that to the details of the proxy class that's meant to consume the message, I believe you'll see what I mean. The proxy class is expecting one namespace, but on the wire, a different namespace is being used.

We have had something similar when using a WCF client against a WSDL from a Java web service.
Our problem was that we could not see the data that was coming back from the service, it looked like the data was missing.
However, when we looked at what was going over the wire, the data was there.
The problem was that the WSDL had many types that inherited from other types. By default we would only see the information in the base type.
The solution was to cast the object to the type we expected, then all the fields appeared.