bindingConfiguration vs bindingName - wcf

What exactly is the difference between bindingConfiguration and bindingName elements in a WCF endpoint element? The reason that I ask is I am creating an endpoint which uses basicHttpBinding and SSL. I configured the web.config like this:
<basicHttpBinding>
<binding name="basicHttps">
<security mode="Transport">
<transport clientCredentialType="None"/>
</security>
</binding>
<endpoint binding="basicHttpBinding" bindingConfiguration="basicHttps" contract="Hsp.Services.Interface.Catalog.ICatalogService" address="" />
However, when using bindingConfiguration then https isn't working. When I change bindingConfiguration to bindingName it works as expected. So, what exactly is the difference between the two?

The binding= attribute just defines, which binding (protocol) you want - basicHttpBinding, wsHttpBinding, netTcpBinding etc.
Those bindings all have system default values - if you don't specify any binding configuration, those system defaults will be used.
What you've defined in your <bindings> section of your config is a binding configuration - a set of parameters for your binding of choice that will be used instead of the system defaults.
So the binding= and the bindingConfiguration= need to match - you cannot define one binding (e.g. basicHttpBinding) but then assign a binding configuration for a different binding.
That however still doesn't explain why your https doesn't work - that must be some other problem. Can you elaborate a bit more? How does it not work? Just no response, or do you get an error (if so: what is that error??)

From the MSDN documentation
bindingConfiguration: A string that specifies the binding name of the binding to use when the endpoint is instantiated. The binding name must be in scope at the point the endpoint is defined. The default is an empty string. This attribute is used in conjunction with binding to reference a specific binding configuration in the configuration file. Set this attribute if you are attempting to use a custom binding. Otherwise, an exception may be thrown.
bindingName: A string that specifies the unique qualified name of the binding for definition export through WSDL. The default is an empty string.
I've never used bindingName, but it seems to only affect the WSDL generated for your endpoint. If something isn't working when you use bindingConfiguration="basicHttps", then it sounds like you have a misconfiguration that's preventing it from working correctly (if no bindingConfiguration is specified, the defaults will be applied, which is what's happening when you change bindingConfiguration to bindingName). I don't think <transport clientCredentialType="None"/> is valid, the possible values are Basic, Certificate, Digest, Windows, or NTLM. See Transport Security Overview

Your service configuration binding is incorrect. So when you correctly refer to your binding configuration using the bindingConfiguration attribute, your service is not working. When you use the bindingName attribute, which is an invalid used attribute in your case, the service just starts a basicHttpBinding without looking at your custom configuration, which seems to work correctly.
For the different between the two elements look at: http://msdn.microsoft.com/en-us/library/ms731320.aspx.
So, using the bindingConfiguration attribute is the only correct thing. Now we still need to look at what is wrong with you binding configuration itself :-) See the following example to extract your relevant information from.
<system.web.extensions>
<scripting>
<webServices>
<authenticationService enabled="true"
requireSSL = "true"/>
</webServices>
</scripting>
</system.web.extensions>
<system.serviceModel>
<services>
<service name="System.Web.ApplicationServices.AuthenticationService"
behaviorConfiguration="AuthenticationServiceTypeBehaviors">
<endpoint contract=
"System.Web.ApplicationServices.AuthenticationService"
binding="basicHttpBinding"
bindingConfiguration="userHttps"
bindingNamespace="http://asp.net/ApplicationServices/v200"/>
</service>
</services>
<bindings>
<basicHttpBinding>
<binding name="userHttps">
<security mode="Transport" />
</binding>
</basicHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="AuthenticationServiceTypeBehaviors">
<serviceMetadata httpGetEnabled="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment
aspNetCompatibilityEnabled="true"/>
</system.serviceModel>
See http://msdn.microsoft.com/en-us/library/bb398990.aspx for more details.

bindingConfiguration
A string that specifies the binding name of the binding to use when the endpoint is instantiated. The binding name must be in scope at the point the endpoint is defined. The default is an empty string.
This attribute is used in conjunction with binding to reference a specific binding configuration in the configuration file. Set this attribute if you are attempting to use a custom binding. Otherwise, an exception may be thrown.
bindingName
A string that specifies the unique qualified name of the binding for definition export through WSDL. The default is an empty string.

Related

How to authenticate wsdl get with TransportWithMessageCredential security mode for the endpoint?

I have a WCF endpoint that exposes a API with a basicHttpBinding. This biding is set to use security mode TransportWithMessageCredentialand UserName for clientCredentialType.
Because security is implemented at message level, at the WCF, the IIS needs to allow anonymous access. And so, wsdl can be obtain without providing any credentials.
How to force authentication to get the service metadata?
Here the current service configuration looks like (from web.config)
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="secure">
<security mode="TransportWithMessageCredential">
<message clientCredentialType="UserName" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service behaviorConfiguration="secure" name="someProject.MyService">
<endpoint binding="basicHttpBinding" contract="someProject.IService" bindingConfiguration="secure" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="secure">
<serviceMetadata httpsGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
I try the obvious, to set a specific binding for the metatada, by using service behavior configuration:
<behavior name="secure">
<serviceMetadata httpsGetEnabled="true" httpsGetBinding="basicHttpBinding" httpsGetBindingConfiguration="transportSecure" />
</behavior>
//and add the new binding
<basicHttpBinding>
<binding name="transportSecure">
<security mode="Transport">
<message clientCredentialType="UserName" />
</security>
</binding>
</basicHttpBinding>
But it is not supported. It throws this:
MessageVersion 'Soap11 (http://schemas.xmlsoap.org/soap/envelope/)
AddressingNone
(http://schemas.microsoft.com/ws/2005/05/addressing/none)' is not
supported in this scenario. Only MessageVersion 'EnvelopeNone
(http://schemas.microsoft.com/ws/2005/05/envelope/none) AddressingNone
(http://schemas.microsoft.com/ws/2005/05/addressing/none)' is
supported.
I don't understand this error or how to get around it.
Normally we will not disclose our metadata in the production environment,But if you want to enable metadata, we can use https binding to protect the metadata.
1.Configure a port with an appropriate X.509 certificate. The certificate must come from a trusted authority, and it must have an intended use of "Service Authorization." You must use the HttpCfg.exe tool to attach the certificate to the port.
2.Create a new instance of the ServiceMetadataBehavior class.
3.Set the HttpsGetEnabled property of the ServiceMetadataBehavior class to true.
4.Set the HttpsGetUrl property to an appropriate URL. Note that if you specify an absolute address, the URL must begin with the scheme https://. If you specify a relative address, you must supply an HTTPS base address for your service host. If this property is not set, the default address is "", or directly at the HTTPS base address for the service.
5.Add the instance to the behaviors collection that the Behaviors property of the ServiceDescription class returns, as shown in the following code.
ServiceMetadataBehavior sb = new ServiceMetadataBehavior();
sb.HttpsGetEnabled = true;
sb.HttpsGetUrl = new Uri("https://myMachineName:8036/myEndpoint");
myServiceHost.Description.Behaviors.Add(sb);
myServiceHost.Open();
This is authentication enabled on WCF, you can also enable windows authentication on IIS, both methods can protect metadata.
But in the production environment, I do not recommend that you enable metadata, because this will lead to the risk of metadata leakage.The call of WCF service can also be called through the channel factory. In this case, we can call WCF service without knowing the metadata of the server.
For more information on how to protect metadata, you can refer to this link:
https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/how-to-secure-metadata-endpoints?redirectedfrom=MSDN

Content Type application/soap+xml; charset=utf-8 was not supported by service

I am getting the error below while trying to add WCF service to WCFTestClient. I went through a number of solutions on the web but I couldn't get it to work.
Can someone help me with the issues?
I am also providing my config file for service:
Content Type application/soap+xml; charset=utf-8 was not supported by
service The client and service bindings may be mismatched. The
remote server returned an error: (415) Cannot process the message
because the content type 'application/soap+xml; charset=utf-8' was not
the expected type 'text/xml; charset=utf-8
Code:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<compilation debug="true" />
</system.web>
<!-- When deploying the service library project, the content of the config file
must be added to the host's app.config file. System.Configuration does not
support config files for libraries. -->
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="basicHttp" allowCookies="true"
maxReceivedMessageSize="20000000"
maxBufferSize="20000000"
maxBufferPoolSize="20000000">
<readerQuotas maxDepth="32"
maxArrayLength="200000000"
maxStringContentLength="200000000"/>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name="WCFTradeLibrary.TradeService">
<endpoint address="" binding="basicHttpBinding"
bindingConfiguration="basicHttp"
contract="WCFTradeLibrary.ITradeService">
</endpoint>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior>
<!-- To avoid disclosing metadata information,
set the value below to false and remove the metadata endpoint
above before deployment -->
<serviceMetadata httpGetEnabled="true"/>
<!-- To receive exception details in faul`enter code here`ts for
debugging purposes,
set the value below to true. Set to false before deployment
to avoid disclosing exception info`enter code here`rmation -->
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
I run into naming problem. Service name has to be exactly name of your implementation. If mismatched, it uses by default basicHttpBinding resulting in text/xml content type.
Name of your class is on two places - SVC markup and CS file.
Check endpoint contract too - again exact name of your interface, nothing more. I've added assembly name which just can't be there.
<service name="MyNamespace.MyService">
<endpoint address="" binding="wsHttpBinding" contract="MyNamespace.IMyService" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
Here is the example of a web.config that solve the issue for me. Pay attention on the <binding name="TransportSecurity" messageEncoding="Text" textEncoding="utf-8">
In my case one of the classes didn't have a default constructor - and class without default constructor can't be serialized.
I had the same problem, got it working by "binding" de service with the service behaviour by doing this :
Gave a name to the behaviour
<serviceBehaviors>
<behavior name="YourBehaviourNameHere">
And making a reference to your behaviour in your service
<services>
<service name="WCFTradeLibrary.TradeService" behaviorConfiguration="YourBehaviourNameHere">
The whole thing would be :
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.web>
<compilation debug="true" />
</system.web>
<!-- When deploying the service library project, the content of the config file must be added to the host's
app.config file. System.Configuration does not support config files for libraries. -->
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="basicHttp" allowCookies="true"
maxReceivedMessageSize="20000000"
maxBufferSize="20000000"
maxBufferPoolSize="20000000">
<readerQuotas maxDepth="32"
maxArrayLength="200000000"
maxStringContentLength="200000000"/>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name="WCFTradeLibrary.TradeService" behaviourConfiguration="YourBehaviourNameHere">
<endpoint address="" binding="basicHttpBinding" bindingConfiguration="basicHttp" contract="WCFTradeLibrary.ITradeService">
</endpoint>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="YourBehaviourNameHere">
<!-- To avoid disclosing metadata information,
set the value below to false and remove the metadata endpoint above before deployment -->
<serviceMetadata httpGetEnabled="true"/>
<!-- To receive exception details in faul`enter code here`ts for debugging purposes,
set the value below to true. Set to false before deployment
to avoid disclosing exception info`enter code here`rmation -->
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
As suggested by others this happens due to service client mismatch.
I ran into the same problem, when was debugging got to know that there is a mismatch in the binding. Instead of WSHTTPBinding I was referring to BasicHttpBinding. In my case I am referring both BasicHttp and WsHttp. I was dynamically assigning the binding based on the reference. So check your service constructor as shown below
Refer this image
This error may occur when WCF client tries to send its message using MTOM extension (MIME type application/soap+xml is used to transfer SOAP XML in MTOM), but service is just able to understand normal SOAP messages (it doesn't contain MIME parts, only text/xml type in HTTP request).
Be sure you generated your client code against correct WSDL.
In order to use MTOM on server side, change your configuration file adding messageEncoding attribute:
<binding name="basicHttp" allowCookies="true"
maxReceivedMessageSize="20000000"
maxBufferSize="20000000"
maxBufferPoolSize="20000000"
messageEncoding="Mtom" >
My case had a different solution.
The client was using basichttpsbinding[1] and the service was using wshttpbinding.
I resolved the problem by changing the server binding to basichttpsbinding.
Also, i had to set target framework to 4.5 by adding:
<system.web>
<compilation debug="true" targetFramework="4.5" />
<httpRuntime targetFramework="4.5"/>
</system.web>
[1] the comunication was over https.
For me, it was very difficult to identify the problem because of a large number of methods and class involved.
What I did is commented (removed) some methods from the WebService interface and try, and then comment another bunch of methods and try, I kept doing this until I found the method that cause the problem.
In my case, it was using a complex object which cannot be serialized.
Good luck!
I experienced the same error message. I managed to fix it:
In my case the error was that I missed the [datacontract] and [datamember] attributes in the parent class of my returned class. The error message was misleading.
[OperationContract]
List<MyClass> GetData();
[DataContract]
public class MyClass : MyParentClass
{
[DataMember]
public string SomeString { get; set; }
}
// Missing DataContract
public class MyParentClass
{
// Missing DataMember
public int SomeNumber { get; set; }
}
In my case same error was caused by missing
[DataContract]
...
[DataMember]
attributes in the returned data type.
Check for that and try addinging those and see if it helps.
I too had the same error in trace logs. My newly created function in API was throwing the same error but to my surprise, the old functions were performing good.
The issue was - My contract data members had few variables of type object. soap-xml was not able to handle it well, however, I can see that array of object types (object[]) were getting passed without any issues. Only a simple object type was not getting parsed by soap. This could be one more reason why the services throw the above error.
My problem was our own collection class, which was flagged with [DataContract]. From my point of view, this was a clean approach and it worked fine with XmlSerializer but for the WCF endpoint it was breaking and we had to remove it. XmlSerializer still works without.
Not working
[DataContract]
public class AttributeCollection : List<KeyValuePairSerializable<string, string>>
Working
public class AttributeCollection : List<KeyValuePairSerializable<string, string>>
I was getting same error while using WebServiceTemplate spring ws
[err] org.springframework.ws.client.WebServiceTransportException: Cannot process the message because the content type 'text/xml; charset=utf-8' was not the expected type 'application/soap+xml; charset=utf-8'. [415]
[err] at org.springframework.ws.client.core.WebServiceTemplate.handleError(WebServiceTemplate.java:665).
The WSDL which i was using has soap1.2 protocol and by default the protocol is soap1.1
.
When i changed the protocol using below code, it was working
MessageFactory msgFactory = MessageFactory.newInstance(javax.xml.soap.SOAPConstants.SOAP_1_2_PROTOCOL);
SaajSoapMessageFactory saajSoapMessageFactory = new SaajSoapMessageFactory(msgFactory);
saajSoapMessageFactory.setSoapVersion(SoapVersion.SOAP_12);
getWebServiceTemplate().setMessageFactory(saajSoapMessageFactory);
I had the same problem and solved it by using EnumMemberAttribute for enum member's attribute. If you are using enum type as data contract and its members attributed with DataMemberAttribute, same error occurs. You must use EnumMemberAttribute for members of enum
I also came across the same problem. In my case, I was using transfermode = streaming with Mtom. As it turns out, I had named one of my variables (for a structure), "HEADER". This conflicted with the message element [http://tempuri.org/:HEADER] as part of the http service download. Clearly, one must avoid using "reserved" words as parameter name.
I had to add the ?wsdl parameter to the end of the url.
For example: http://localhost:8745/YourServiceName/?wsdl
check the client config file that identified to the web.config on the binding section

WCF programmatically set endpoint address: No elements matching the key were found in the configuration element collection

I'm performing what I believed was a pretty basic task. We have an environment with multiple servers (DEV, TEST, PRODUCTION) and I'd like to programmatically change the service endpoint. To do this I am creating a new EndPointAddress and instantiating the client as:
BasicHttpBinding binding = new BasicHttpBinding("BasicHttpBinding_IMyService");
EndpointAddress endpoint = new EndpointAddress(new Uri("http://domain.name/myservice.svc"));
MyService.MyServiceClient client = new MyService.MyServiceClient(binding, endpoint);
I am receiving the following error.
No elements matching the key 'BasicHttpBinding_IMyService' were found in the configuration element collection.
I have included my app.config below but, as you can see, I do have the binding defined.
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IMyService" >
<... removed directives for ease of reading ...>
</binding>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://domain.name/MyService.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IMyService"
contract="MyService.IMyService" name="BasicHttpBinding_IMyService" />
</client>
</system.serviceModel>
I'm sorry if this is a simple question but I haven't been able to identify the problem. I'll call it the 'late-Friday brain fog', and maybe you can call it 'easy points'?
Thanks!
The bindings in the Web.config of the WCF application and the app.config of the client application must match

What is the bindingConfiguration attribute responsible for in a BasicHttpBinding endpoint config?

So I am working with configuring endpoints for a WCF service. I have almost no experience with services as a whole, but have been plopped in the middle of a project that uses them. I roughly understand what each attribute in the endpoint is doing except for one. "bindingConfiguration".
Here's an obscured version of my code (actual information is proprietary):
<endpoint address="http://localhost/SomeService.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ISomeService"
contract="SomeService.ICoreService" name="BasicHttpBinding_ISomeService" />
Here's MSDN's take on it (as in they don't specifically address it).
Microsoft's incomplete MSDN Entry
Of course Stackoverflow has a few questions containing a string match for "bindingConfiguration" but none explicetely address my question:
Most relative (I think) Stackoverflow question
Any ideas on what this is used for?
In the interest of learning I am willing to take a stab and be wrong here. I think it has something to with authentication or security. On Inspection of the Interface I notice nothing pertaining to this either.
Any help would be great!
Cheers
Matt
In your bindings section, you can have multiple "configurations" for the same binding type (in your case, basicHttpBinding). The binding configuration chooses among them which one to use.
In MSDN, you should try to find the reference for <endpoint> (since bindingConfiguration is is attribute), that will have a definition of what the attribute is supposed to do.
In the example below, the service defines two endpoints, both using basicHttpBinding. One of them is exposed over "normal" HTTP, the other is exposed over HTTPS. The bindingconfiguration attribute is the one which tells WCF which configuration to use.
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="SimpleBasic">
<security mode="None"/>
</binding>
<binding name="BasicOverHttps">
<security mode="Transport"/>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name="MyNamespace.MyService">
<endpoint address="ep"
binding="basicHttpBinding"
bindingConfiguration="SimpleBasic"
contract="MyNamespace.IService" />
<endpoint address="secure"
binding="basicHttpBinding"
bindingConfiguration="BasicOverHttps"
contract="MyNamespace.IService" />
</service>
</services>
</system.serviceModel>

WSHttp binding and ReliableSession / MaxRetryCount

When using a WSHttpBinding in WCF with reliableSessions enabled, my service reference updates itself to:
<reliableSession ordered="true" inactivityTimeout="00:10:00" enabled="true">
</reliableSession>
I cannot add the maxRetryCount attribute to the reliableSession as long as the binding is configured as a WSHttpBinding.
Now my question: what is the value of maxRetryCount when using a WSHttpBinding, and is there any way to change this in config; without the use of a CustomBinding?
You cannot set the maxRetryCount on a standard wsHttpBinding configuration. In order to set that value, you need to create a separate custom binding and then reference that from your service or client config:
<system.serviceModel>
<bindings>
<customBinding>
<binding name="wsCustomBinding">
<reliableSession maxRetryCount="15"/>
<textMessageEncoding/>
<httpTransport />
</binding>
</customBinding>
</bindings>
<services>
<service name="MyService">
<endpoint address="http://localhost:7878/MyServoce"
binding="customBinding"
bindingConfiguration="wsCustomBinding"
contract="IMyService" />
</service>
</services>
</system.serviceModel>
Defining a custom binding isn't hard - but you need to make sure you specify the elements that make up the binding in the right order - see the MSDN docs on custom bindings for a reference.
If you want to share the custom binding configuration between server and client, you could also put that <bindings> section into a separate bindings.config file, and then reference that external file from your web.config/app.config:
<system.serviceModel>
<bindings configSource="bindings.config">
Visual Studio will complain about this and show red squiggly underlines - but trust me - the technique works, I use it in production every day (the Visual Studio XML schema describing the config stuff isn't complete and accurate).
Marc