I have a WCF service exposing some 34 methods. Up until today metadata exchanging using MetadataExchangeClient was working just fine, but suddenly I started getting the following exception:
Metadata contains a reference that cannot be resolved: http://localhost:1150/service.svc?wsdl=wsdl0
The most "interesting" thing is that if I comment out some of the methods (no matter which ones) in the service contract so that the service exposes less methods I can get metadata just right. The web.config settings reads
<system.serviceModel>
<services>
<service name="(...)" serviceBehavior="(...)">
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="(...)"><serviceMetadata httpGetEnabled="True"></behavior>
<serviceBehaviors>
</behaviors>
All names are namespace-qualified and everything works well while exposing, say, 15 methods. Whenever I try to expose more, and no matter which ones, I get that exception. What am I doing wrong?
I bet the added methods make the message size greater than the default max. Do you have an inner exception saying "The maximum message size quota for incoming messages (65536) has been exceeded"?
If so increase your mex binding's MaxReceivedMessageSize:
<services>
<service>
<endpoint contract="IMetadataExchange" binding="wsHttpBinding" bindingConfiguration="mexBinding" address="mex" />
</service>
</services>
<bindings>
<wsHttpBinding>
<binding name="mexBinding" maxReceivedMessageSize="5000000">
<security mode="None"/>
</binding>
</wsHttpBinding>
</bindings>
Note that the endpoint binding is not standard "mexHttpBinding". I'm copying from a complete example posted on http://www.dasblonde.net.
Related
I have a simple test purpose WCF service. I'm trying to host it under IIS 7.5 ( Windows 7 ) but no luck so far. I'm getting error
Cannot obtain Metadata from net.tcp://localhost/TestApp2/MyService
I have a web site TestApp2 under Default Web Site, I enabled tcp on Default Web Site and TestApp2. Here is my web.config file, while I realize that this error simply states that I didn't have endpoint for metadata exchange, I can't see what's the problem because I included endpoint for metadata exchange.
<system.serviceModel>
<services>
<service behaviorConfiguration="ServiceBehavior" name="MyService">
<endpoint address="net.tcp://localhost/TestApp2/MyService"
binding="netTcpBinding"
bindingConfiguration="PortSharingBinding"
contract="II7WcfService.IService1" />
<endpoint address="MEX"
binding="mexTcpBinding"
contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="net.tcp://localhost/TestApp2/MyService" />
</baseAddresses>
</host>
</service>
</services>
<bindings>
<netTcpBinding>
<binding name="PortSharingBinding" portSharingEnabled="true">
<security mode="None"/>
</binding>
</netTcpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceBehavior">
<serviceMetadata httpGetEnabled="False" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
Thanks.
My guess is your service isn't actually called MyService but rather it is in a namespace. This means your declared endpoints are not getting picked up, and the default ones (which doesn't include IMetadataExchange) are being used instead.
Add the name of your namespace to the attribute in the config and it should work.
I have a wcf restful service up and running. I can issue Get/Post with no issues if I start a webservice using WebServiceHost. I tried moving the wcf service to IIS 7.5 on my local box and I can't seem to get it going.
I keep getting the following error anything I try to call anything from from the wcf service: (http://wp9dbytr1k1:8081/service.svc/AnythingHereForGETorPUT). I've tried in virtual directory/Appliances and I get the same issue.
The message with Action '' cannot be processed at the receiver, due to a ContractFilter mismatch at the EndpointDispatcher. This may be because of either a contract mismatch (mismatched Actions between sender and receiver) or a binding/security mismatch between the sender and the receiver. Check that sender and receiver have the same contract and the same binding (including security requirements, e.g. Message, Transport, None).
if I call the svc file directly (http://wp9dbytr1k1:8081/service.svc), its happy and tells me
"You have created a service.
To test this service, you will need to create a client and use it to call the service. You can do this using the svcutil.exe tool from the command line with the following syntax:
svcutil.exe http://wp9dbytr1k1:8081/FUU/service.svc?wsdl"
The strack trace from Trace viewer hasn't help: Sorry have to add a link, not allowed to post images yet. (ImageLink)
Here's my web.config
<system.serviceModel>
<bindings>
<mexHttpsBinding>
<binding name="NewBinding0" />
</mexHttpsBinding>
<webHttpBinding>
<binding name="WebBinding">
<readerQuotas maxDepth="524288" maxStringContentLength="524288"
maxArrayLength="524288" maxBytesPerRead="524288" maxNameTableCharCount="524288" />
<security mode="None">
<transport clientCredentialType="None" proxyCredentialType="None" />
</security>
</binding>
</webHttpBinding>
</bindings>
<services>
<service behaviorConfiguration="StoredProcBehaviors" name="StoredProcService.DataRetreivalService">
<endpoint address="" binding="webHttpBinding" bindingConfiguration="WebBinding"
contract="StoredProcService.IDataRetreivalService">
<identity>
<dns value="locahost" />
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" bindingConfiguration=""
contract="StoredProcService.IDataRetreivalService" />
<host>
<baseAddresses>
<add baseAddress="http://WP9DBYTR1K1:8081/" />
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="StoredProcBehaviors">
<serviceMetadata httpGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
For obvious reasons, this feels like IIS setup since it works with WebServiceHost. I've googled the errors/tutorials on how to set this up and everything seems good to me.
Any suggestions?
Thanks
To create a REST endpoint in WCF, you need, in addition to using the WebHttpBinding, to have an endpoint behavior with on it.
<system.serviceModel>
<services>
<service behaviorConfiguration="StoredProcBehaviors" name="StoredProcService.DataRetreivalService">
<endpoint address="" binding="webHttpBinding" bindingConfiguration="WebBinding" behaviorConfiguration="REST"
contract="StoredProcService.IDataRetreivalService">
<identity>
<dns value="locahost" />
</identity>
</endpoint>
</service>
</services>
<behaviors>
<endpointBehaviors>
<behavior name="REST">
<webHttp/>
</behavior>
<endpointBehaviors>
</behaviors>
</system.serviceModel>
Another option is to use the WebServiceHostFactory in the .svc file, which works like the WebServiceHost. In this case you don't even need the system.serviceModel section in web.config.
<% #ServiceHost Service="StoredProcService.DataRetreivalService" Factory="System.ServiceModel.Activation.WebServiceHostFactory" Language="C#" debug="true" %>
I've written a WCF web service for consumption by a Silverlight app. Initially, the service only required a basic http binding. We now need to be able to deploy the service for use under both http and https. I've found some settings for web.config that allow me to do this as follows:
<system.serviceModel>
<behaviors>
<endpointBehaviors>
<behavior name="SilverlightFaultBehavior">
<silverlightFaults />
</behavior>
</endpointBehaviors>
<serviceBehaviors>
<behavior name="CxtMappingWebService.CxtMappingWebServiceBehavior">
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="True" />
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<basicHttpBinding>
<binding name="SecureHttpBinding">
<security mode="Transport" />
</binding>
<binding name="BasicHttpBinding">
<security mode="None" />
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name="CxtMappingWebService.CxtMappingWebService" behaviorConfiguration="CxtMappingWebService.CxtMappingWebServiceBehavior">
<endpoint address="" bindingConfiguration="SecureHttpBinding" binding="basicHttpBinding" contract="CxtMappingWebService.ICxtMappingWebService" behaviorConfiguration="SilverlightFaultBehavior" />
<endpoint address="" bindingConfiguration="BasicHttpBinding" binding="basicHttpBinding" contract="CxtMappingWebService.ICxtMappingWebService" behaviorConfiguration="SilverlightFaultBehavior" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
</system.serviceModel>
Unfortunately, however, there's a problem with this.
This web service needs to be deployed to hundreds of our customers' servers, and not all of them will be using https. Deploying it to a server that doesn't have an https binding set up in IIS causes it to fail. Is there a way to have both of these bindings in the web.config by default without it dying if there's not an https binding set up in IIS?
We've got a possible solution for this problem, but it doesn't really fit well with our deployment requirements.
Has anybody else encountered anything like this before, and how did you resolve it?
The accepted answer on this page is not of much use if you don't use an installer.
The correct answer lies in a later edit by the OP himself, all one needs to do is bind both http and https ports in IIS and then use the configuration below.
<service name="CxtMappingWebService.CxtMappingWebService" behaviorConfiguration="CxtMappingWebService.CxtMappingWebServiceBehavior">
<endpoint address="" bindingConfiguration="SecureHttpBinding" binding="basicHttpBinding" contract="CxtMappingWebService.ICxtMappingWebService" behaviorConfiguration="SilverlightFaultBehavior" />
<endpoint address="" bindingConfiguration="BasicHttpBinding" binding="basicHttpBinding" contract="CxtMappingWebService.ICxtMappingWebService" behaviorConfiguration="SilverlightFaultBehavior" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
That worked just fine for me!
In the end, we decided to go with external files using the configSource attribute for the bindings, behaviors, and services sections of the web.config, like so:
<bindings configSource="bindings.config" />
<behaviors configSource="behaviors.config" />
<services configSource="services.config" />
This way, we deploy it by default with those external files set up for http access only, and give the customer instructions (or assist them) on how to edit the external files to set up for https access. This also allows us to deploy future changes to the web.config itself without overwriting the external config files.
This would be handled by the installer you use to deploy the service. It should be a prerequisite (or at least leave an option in the installer) to deploy the both endpoints or only the http one.
Two of your endpoints have the same URI. This is not permitted in WCF. You should be able to specify endpoints with different bindings, but the URI's must be different (i.e. different port number or different contract).
I decided to migrate my legacy web service over to a WCF service called ServiceZ.svc. While moving things over went off without any issues and the application compiles AND I have other WCF TCP services running on my development machine, I cannot get this HTTP WCF service to load. I keep getting 404 errors no matter what I try - can somebody please review the included web.config section and help me figure out what is wrong? Thanks!
<system.serviceModel>
<services>
<service name="ServiceZ">
<endpoint address="http://localhost/Website/ServiceZ" binding="basicHttpBinding"
name="MainHttpPoint" contract="IServiceZ" />
<endpoint address="mex" binding="mexHttpBinding" name="MexEP"
contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://localhost/Website/ServiceZ" />
</baseAddresses>
</host>
</service>
</services>
<bindings>
<basicHttpBinding>
<binding openTimeout="0:10:00" sendTimeout="00:10:00" />
</basicHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior>
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
Depending how you want to configure this, you can take the following approach:
1) In the serviceBehaviors I tend to add the following within the behavior: (completely optional)
<useRequestHeadersForMetaAddress>
<defaultPorts>
<add scheme="http" port="__PORT__" />
</defaultPorts>
</useRequestHeadersForMetaAddress>
This makes the service accessible with either a query using localhost, localserver1, www.webserver2.com, or fully.qualified.domain.com. (Makes for less headaches IMHO).
2) The endpoint addresses are relative to the baseAddress. That as to say you can use address="" for your default binding and address="mex" for your mexHttpBinding, given that baseAddress="http://localhost:__PORT__/Website/ServiceZ"
Most likely your WSDL problem is due to a mix of the two problems (basically, the service is saying all markup can be found on localhost (as specified by the endpoint address)--which is true when you run it locally, however when it's on a remote server this is no longer the case)
I have a the following server side app.config for a WCF service:
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="default" maxReceivedMessageSize="5000000">
<readerQuotas maxStringContentLength="5000000" maxArrayLength="5000000" />
</binding>
</wsHttpBinding>
</bindings>
<services>
<service behaviorConfiguration="Core.TOAService.Service1Behavior"
name="Core.TOAService.TOAService">
<endpoint address="" binding="wsHttpBinding" contract="Core.TOAService.ITOAService">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://localhost:8732/Design_Time_Addresses/Core.TOAService/TOAService/" />
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="Core.TOAService.Service1Behavior">
<!-- 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 faults for debugging purposes,
set the value below to true. Set to false before deployment
to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
When I try and pass this service a largish file (only ~250KB), I get an exception logged in the svclog file:
The maximum message size quota for
incoming messages (65536) has been
exceeded. To increase the quota, use
the MaxReceivedMessageSize property on
the appropriate binding element.
As you can see from the binding section at the top of the config, I have tried to set the maxReceivedMessageSize to 5000000 but the service still thinks it is set to the default 65536. Any ideas as to what is wrong or which is the "appropriate" binding element?
There's more settings :-) Try "maxBufferPoolSize" and "maxBufferSize" on the <binding> tag.
But the biggest problem is: your endpoint does not reference that binding configuration!
<endpoint address=""
binding="wsHttpBinding" contract="Core.TOAService.ITOAService">
You need to add a reference to it so that it gets useful - just calling it "default" doesn't work.....
<endpoint address=""
binding="wsHttpBinding"
bindingConfiguration="default"
contract="Core.TOAService.ITOAService">
You're ahead of your times ;-) In WCF 4 (with .NET 4.0 - sometime later this year 2009), you'll be able to define "default binding configurations" without having to explicitly name and reference them - but for now, you need to create a link between your endpoint and its binding and any binding (or behavior) configuration you have!
Marc
If you're still getting this error message while using the WCF Test Client, it's because the client has a separate MaxBufferSize setting.
To correct the issue:
Right-Click on the Config File node at the bottom of the tree
Select Edit with SvcConfigEditor
A list of editable settings will appear, including MaxBufferSize.
Note: Auto-generated proxy clients also set MaxBufferSize to 65536 by default.
There are several places that you need to set the size. In your case I think that you need to add read quotas. Here is an example:
<basicHttpBinding>
<binding name="httpBasicBinding_Service" closeTimeout="00:03:00"
openTimeout="00:03:00" receiveTimeout="00:10:00" sendTimeout="00:03:00"
maxBufferSize="2000001"
maxBufferPoolSize="2000001" maxReceivedMessageSize="2000001">
<readerQuotas maxDepth="2000001" maxStringContentLength="2000001"
maxArrayLength="2000001" maxBytesPerRead="2000001" maxNameTableCharCount="2000001" />
</binding>
</basicHttpBinding>