I have 3 projects in a solution as following:
WCF Service Library "ServiceLib"(contract ICalculator and its implementation Calculator1).
Console Application "ServiceHost" to host WCF Service Library(and another ICalculator implementation Calculator2);
add Calculator1 & Calculator2 into an instance of ServiceHost using method AddServiceEndpoint(typeof(ICalculator), new WSHttpBinding(), "Calculator1"),
AddServiceEndpoint(typeof(ICalculator), new WSHttpBinding(), "Calculator2")
Add Service Reference to "ServiceHost" to my client application(type of Console Application);
an app.config(auto-generated) within this project
question is: How to consume these two Calculators(different logic) from client app side, does it necessary to create two different types of client proxy or other way to do that?
thanks for your hand!
<endpoint address="http://localhost:8000/Calculator" binding="wsHttpBinding"
bindingConfiguration="WSHttpBinding_ICalculator" contract="Services_BaseAddress.ICalculator"
name="WSHttpBinding_ICalculator">
</endpoint>
<endpoint address="http://localhost:8000/DoubleCalculator" binding="wsHttpBinding"
bindingConfiguration="WSHttpBinding_ICalculator1" contract="Services_BaseAddress.ICalculator"
name="WSHttpBinding_ICalculator1">
</endpoint>
Due to some certain requirement, I've got to use a single svc for multiple service versions. I've separated the interface contract for each version using different namespaces. I have only one class (partial) implementing all the service versions.
My code is as below:
namespace Application.V1
{
[ServiceContract(Namespace = "http://google.com/ApplicationService/v1.0", Name = "IMathService")]
public interface IMathService
}
namespace Application.V2
{
[ServiceContract(Namespace = "http://google.com/ApplicationService/v2.0", Name = "IMathService")]
public interface IMathService
}
The Application/MathServiceV1.cs file:
public partial class MathService : V1.IMathService { }
The Application/MathServiceV2.cs file:
public partial class MathService : V2.IMathService { }
The Application/MathService.cs file:
public partial class MathService {}
I've added the following in the service web.config:
<service behaviorConfiguration="ServiceBehavior" name="Application.MathService">
<endpoint address="V1" binding="wsHttpBinding" contract="Application.V1.IMathService" />
<endpoint address="V2" binding="wsHttpBinding" contract="Application.V2.IMathService" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
I have a file MathService.svc with the following:
<%# ServiceHost Service="Application.MathService, Application"
Factory="Autofac.Integration.Wcf.AutofacServiceHostFactory, Autofac.Integration.Wcf"%>
If I generate a proxy with the address http://localhost:8000/MathService.svc the client endpoints are generated as below:
<client>
<endpoint address="http://localhost:8000/MathService.svc/V1"
binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IMathService"
contract="MathService.IMathService" name="WSHttpBinding_IMathService">
</endpoint>
<endpoint address="http://localhost:8000/MathService.svc/V2"
binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IMathService1"
contract="MathService.IMathService1" name="WSHttpBinding_IMathService1">
</endpoint>
</client>
My concern is that the client endpoint address is generated with MathService.svc/V1 but I'd like to see V1/MathService.svc.
If i browse the service with the address http://localhost:8000/MathService.svc/V1 i am getting HTTP 400 Bad Request error.
Any suggestions?
Regarding your 400 bad request error - you probably dont have MEX enabled, so making a request without a payload makes no sense to the service.
Here is a question about enabling MEX:
WCF How to enable metadata?
Either enable MEX - or use a proper service consumer to call your service.
Regarding your addressing - you cannot do what you want to do with WCF alone. Because you are using IIS hosted WCF (I assume this because you are using an SVC file), your HTTP request must be directed to the location of your SVC file, and anything after that (/V1 for example) is used to locate the appropriate endpoint. This is just how it works in IIS. Putting the /v1/ BEFORE the file name (MathService.asmx) tells IIS to look for a folder called /v1/ before attempting to locate a file named MathService.asmx - obviously it wont find anything there!
However, you may be able to install a URL rewriter in your Web.config to redirect your preferred URI to the one mentioned above.
Here is some documentation on Url rewriting in asp.net:
http://www.iis.net/learn/extensions/url-rewrite-module/iis-url-rewriting-and-aspnet-routing
I have a problem with a WCF service.
I have a console application and I need to consume the service without using app.config, so I had to set the endpoint, etc. by code.
I do have a service reference to the svc, but I can't use the app.config.
Here's my code:
BasicHttpBinding binding = new BasicHttpBinding();
EndpointAddress address = new EndpointAddress("http://localhost:8731/WcfServicio/MiServicio");
MiServicioClient svc = new MiServicioClient(binding, address);
object ob = svc.PaisesObtener();
At the last line when I do svc.PaisesObtener() I get the error:
Content Type text/xml; charset=utf-8 was not supported by service
http://localhost:8731/WcfServicio/MiServicio. The client and service bindings may be mismatched.
First Google hit says:
this is usually a mismatch in the client/server bindings, where the message version in the service uses SOAP 1.2 (which expects application/soap+xml) and the version in the client uses SOAP 1.1 (which sends text/xml). WSHttpBinding uses SOAP 1.2, BasicHttpBinding uses SOAP 1.1.
It usually seems to be a wsHttpBinding on one side and a basicHttpBinding on the other.
Do not forget check the bindings-related code too.
So if you wrote:
BasicHttpBinding binding = new BasicHttpBinding();
Be sure that all your app.config files contains
<endpoint address="..."
binding="basicHttpBinding" ...
not the
<endpoint address="..."
binding="wsHttpBinding" ...
or so.
I've seen this behavior today when the
<service name="A.B.C.D" behaviorConfiguration="returnFaults">
<endpoint contract="A.B.C.ID" binding="basicHttpBinding" address=""/>
</service>
was missing from the web.config. The service.svc file was there and got served. It took a while to realize that the problem was not in the binding configuration it self...
I saw this problem today when trying to create a WCF service proxy, both using VS2010 and svcutil.
Everything I'm doing is with basicHttpBinding (so no issue with wsHttpBinding).
For the first time in my recollection MSDN actually provided me with the solution, at the following link How to: Publish Metadata for a Service Using a Configuration File. The line I needed to change was inside the behavior element inside the MEX service behavior element inside my service app.config file. I changed it from
<serviceMetadata httpGetEnabled="true"/>
to
<serviceMetadata httpGetEnabled="true" policyVersion="Policy15"/>
and like magic the error went away and I was able to create the service proxy. Note that there is a corresponding MSDN entry for using code instead of a config file: How to: Publish Metadata for a Service Using Code.
(Of course, Policy15 - how could I possibly have overlooked that???)
One more "gotcha": my service needs to expose 3 different endpoints, each supporting a different contract. For each proxy that I needed to build, I had to comment out the other 2 endpoints, otherwise svcutil would complain that it could not resolve the base URL address.
I was facing the similar issue when using the Channel Factory. it was actually due to wrong Contract specified in the endpoint.
For anyone who lands here by searching:
content type 'application/json; charset=utf-8' was not the expected type 'text/xml; charset=utf-8
or some subset of that error:
A similar error was caused in my case by building and running a service without proper attributes. I got this error message when I tried to update the service reference in my client application. It was resolved when I correctly applied [DataContract] and [DataMember] attributes to my custom classes.
This would most likely be applicable if your service was set up and working and then it broke after you edited it.
I was also facing the same problem recently. after struggling a couple of hours,finally a solution came out by addition to
Factory="System.ServiceModel.Activation.WebServiceHostFactory"
to your SVC markup file. e.g.
ServiceHost Language="C#" Debug="true" Service="QuiznetOnline.Web.UI.WebServices.LogService"
Factory="System.ServiceModel.Activation.WebServiceHostFactory"
and now you can compile & run your application successfully.
Again, I stress that namespace, svc name and contract must be correctly specified in web.config file:
<service name="NAMESPACE.SvcFileName">
<endpoint contract="NAMESPACE.IContractName" />
</service>
Example:
<service name="MyNameSpace.FileService">
<endpoint contract="MyNameSpace.IFileService" />
</service>
(Unrelevant tags ommited in these samples)
In my case, I had to specify messageEncoding to Mtom in app.config of the client application like that:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1" />
</startup>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="IntegrationServiceSoap" messageEncoding="Mtom"/>
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://localhost:29495/IntegrationService.asmx"
binding="basicHttpBinding" bindingConfiguration="IntegrationServiceSoap"
contract="IntegrationService.IntegrationServiceSoap" name="IntegrationServiceSoap" />
</client>
</system.serviceModel>
</configuration>
Both my client and server use basicHttpBinding.
I hope this helps the others :)
I had this error and all the configurations mentioned above were correct however I was still getting "The client and service bindings may be mismatched" error.
What resolved my error, was matching the messageEncoding attribute values in the following node of service and client config files. They were different in mine, service was Text and client Mtom. Changing service to Mtom to match client's, resolved the issue.
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="BasicHttpBinding_IMySevice" ... messageEncoding="Mtom">
...
</binding>
</basicHttpBinding>
</bindings>
</system.serviceModel>
</configuration>
I had this problem in .net 6.0
The problem was the Soap Version, the BasicHttpBinding targets Soap 1.1 by default, but the service uses Soap 1.2.
The solution was to create a custom binding that targets Soap 1.2:
private Binding GetBindingConfiguration()
{
var textBindingElement = new TextMessageEncodingBindingElement()
{
MessageVersion = MessageVersion.CreateVersion(EnvelopeVersion.Soap12, AddressingVersion.None)
};
var httpsBindingElement = new HttpsTransportBindingElement()
{
MaxReceivedMessageSize = int.MaxValue,
RequireClientCertificate = true //my service require certificate
};
return new CustomBinding(textBindingElement, httpsBindingElement);
}
var binding = GetBindingConfiguration();
var address = new EndpointAddress("https://nfe.sefa.pr.gov.br/nfe/NFeAutorizacao4"); //Brazil NF-e endpoint that I had to consume.
var svc = new MyService(binding, address);
//my service requires certificate
svc.ClientCredentials.ClientCertificate.Certificate = certificado;
object ob = svc.PaisesObtener(); //call the method
My WCF service exposes an https AND an http endpoint. Apart from the SSL they are identical. They map to the same code.
The ultimate intention is for external users to connect via https, internal users to use http.
In development this gives me a problem. Cassini, the development web server packaged in VS, hates SSL.
I'm wondering if I can configure the service from code, so when running under Cassini, I would not configure https.
Hence the question - How do I configure the service from code if it is IIS hosted? I'd be very happy with alternative answers on how I can persuade Cassini to NOT complain about the https part of the configuration.
"IIS will take care of spinning up the necessary ServiceHost based on your *.svc file - not a whole lot you can do about that, really."
Not too close to the truth. Exactly in the SVC file of your service there is attribute named Factory. Where you can specify the the class and the assebly where the class is located. This class may be your own descendant of Web|DataServiceHostFactory
So your svc markup would look like this
<%# ServiceHost
Language="C#"
Debug="true"
Service="name.space.myService"
CodeBehind="name.space.myService.svc.sc"
Factory = "name.space.WebServiceHostFactoryEx, assembly.name"
%>
The WebServiceHostFactory will be created for every service hit and will recreate your host the way you want it.
You will also need to inherith WebServiceHost and create it the way you need it with certain endpoins, behaviors, addresses, etc settings - whatever you like.
There is very nice post from Michele Bustamante here
EDIT: I figured out the above link is not working anymore, so here it is another one.
I am using this in IIS hosted enviroment for couple of services that are initialized same way.
When you're hosting in IIS, you're leaving a lot of care taking into the realm of IIS - you cannot really grab a hold of your service in this case.
IIS will take care of spinning up the necessary ServiceHost based on your *.svc file - not a whole lot you can do about that, really.
My solution would be different - externalize the <service> tag in your configuration file (web.config):
<system.serviceModel>
<services>
<service configSource="service.dev.config" />
</services>
</system.serviceModel>
In your dev environment, only expose the http endpoint - so your service.dev.config would look something like this:
<service name=".....">
<endpoint name="default"
address="....."
binding="basicHttpBinding" bindingConfiguration="insecure"
contract="......" />
</service>
Create a second service.prod.config which then contains both endpoints - http and https:
<service name=".....">
<endpoint name="default"
address="....."
binding="basicHttpBinding" bindingConfiguration="insecure"
contract="......" />
<endpoint name="secure"
address="....."
binding="basicHttpBinding" bindingConfiguration="secure"
contract="......" />
</service>
and reference that in your web.config on the deployment server.
i got a webservicedefinition like this:
[OperationContract]
[FaultContract(typeof(Exception))]
[WebInvoke(ResponseFormat = WebMessageFormat.Xml,
BodyStyle = WebMessageBodyStyle.Wrapped,
RequestFormat = WebMessageFormat.Xml)]
SearchResponse SearchXML(SearchRequest req);
and a Service config like this:
<service name="SearchEngine.SearchService" behaviorConfiguration="HTTPGetBehavior">
<endpoint address="SearchEngine.SearchService" behaviorConfiguration="ajaxBehavior" binding="webHttpBinding" contract="SearchEngine.ISearchInterface" />
<endpoint contract="IMetadataExchange" binding="mexHttpBinding" address="mex" />
<host>
<baseAddresses>
<add baseAddress="http://localhost:8800/SearchService" />
</baseAddresses>
</host>
</service>
and i want to get the WSDL file, which should be possible with a HTTP-GET request like this:
http://localhost:8800/SearchService?wsdl
But all iam getting is a "method not allowed message by the wcf-service"
What am i doing wrong? I want the WSDL information to show the structure of request and response to an external client ( so that he can prepare his function calls )
Thanks
Well, if I read the binding correctly, you're using the "webHttpBinding" which is a REST interface.
REST does not have anything like the WSDL file - that's a SOAP thing.
REST is considered easier to use and simpler to understand - but it doesn't have the amount of metadata that a typical SOAP web service will have.
So basically, if you stick with REST (webHttpBinding), you can't have a WSDL - you have to find another way to communicate your service methods exposed and the possible parameters they expect.
There seem to be efforts under way to come up with something similar to a WSDL for REST called Web Application Description Language (WADL) but I don't know how far that effort has come, and as far as I know, the WCF REST starter kit doesn't support any of that just yet.
Check out some links for WADL:
Sun Web Application Description Language Spec
WADL REST API description language getting some attention
Do we need WADL?
Does REST need a WSDL?
Marc