I was working on WCF service with an endpoint binding of netTcpBinding, hosted in a console application.
These are the configuration settings:
<system.serviceModel>
<services>
<service name="FullTimePartTime_EmpWCFServiceAppl.EmployeeService"
behaviorConfiguration="mexBehaviour" >
<endpoint
address="EmployeeService"
binding="netTcpBinding"
contract="FullTimePartTime_EmpWCFServiceAppl.IEmployeeService">
</endpoint>
<endpoint
address="mex"
binding="mexTcpBinding"
contract="IMetadataExchange">
</endpoint>
<host>
<baseAddresses>
<add baseAddress="net.tcp://localhost:7090/"/>
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="mexBehaviour">
<serviceMetadata httpGetEnabled="false" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
The console application executes fine. WPF is client app which should consume the WCF service, but when I tried to add a service reference, this error occurred:
Service Reference Error
Can anyone help me to fix this issue & let me know the mistake I made?
Thanks in advance.
Always the metadata discovery is through http.So you need to have one more base address for the http which publishes the metdata via http.
<host>
<baseAddresses>
<add baseAddress="http://localhost:7091/"/>
<add baseAddress="net.tcp://localhost:7090/"/>
</baseAddresses>
</host>
First try to browse the metadata through http://localhost:7091/?wsdl. Now try to generate proxy class using the service reference address http://localhost:7091/.
Related
I follow this blog CONFIGURING WCF SERVICE WITH NETTCPBINDING step by step, when I add service reference from VS 2013, I got below error.
The URI prefix is not recognized.
Metadata contains a reference that cannot be resolved: 'net.tcp://localhost/WCFNetTcp/WCFNetTcpService.svc/mex'.
You have tried to create a channel to a service that does not support .Net Framing. It is possible that you are encountering an HTTP endpoint.
Expected record type 'PreambleAck', found '72'.
My Service configure file is below:
<system.serviceModel>
<services>
<service behaviorConfiguration="netTcpb" name="WCFNetTcp.WCFNetTcpService">
<endpoint address="" binding="netTcpBinding" bindingConfiguration="portSharingBinding" contract="WCFNetTcp.IWCFNetTcpService" />
<endpoint address="mex" binding="mexTcpBinding" bindingConfiguration="" contract="IMetadataExchange" />
<!--<endpoint address="mexHttp" binding="mexHttpBinding" contract="IMetadataExchange" />-->
<host>
<baseAddresses>
<!--<add baseAddress="net.tcp://localhost:6666/WCFNetTcpService/"/>-->
<add baseAddress="net.tcp://localhost:808/WCFNetTcp/WCFNetTcpService.svc" />
<!--<add baseAddress="http://local/WCFNetTcp"/>-->
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="netTcpb">
<serviceMetadata httpGetEnabled="false"/>
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<netTcpBinding>
<binding name="portSharingBinding" portSharingEnabled="true"/>
</netTcpBinding>
</bindings>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true">
<baseAddressPrefixFilters>
<add prefix="net.tcp://localhost:808"/>
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
</system.serviceModel>
I tried any net.tcp URL what I could think out, but all of them do not work. It seems that basic address did not work when the service is hosted in IIS, it depends on the url in IIS. If I create a service which is hosted in console application with below configuration file, it works.
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior>
<serviceMetadata httpGetEnabled="false"/>
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service name="WCFNETTCP.Service1">
<endpoint address="" binding="netTcpBinding" contract="WCFNETTCP.IService1">
</endpoint>
<!--comment out after you add service reference-->
<endpoint address="mex" binding="mexTcpBinding" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="net.tcp://xxx:6666/WCFNETTCP/" />
<add baseAddress="http://xxx:6667/WCFNETTCIP"/>
</baseAddresses>
</host>
</service>
</services>
</system.serviceModel>
It would be appreciated if you could share us how to make it work under IIS.
It seems there is something wrong in my IIS. I resolved this issue by below steps.
reinstall IIS
reinstall WCF Non-HTTP Activation in Windows features
reregister asp.net in iis by this command
C:\Windows\Microsoft.NET\Framework64\v4.0.30319>dism /online /enable-feature /featurename:IIS-ASPNET45
Check the settings in IIS which there is no change at my side.
Rebuild my WCF Service, and add service reference successfully.
Hope it will be work for you.
I have created a service host with following configuration.
<?xml version="1.0"?>
<configuration>
<system.serviceModel>
<services>
<service name="MathServiceLib.MathService" behaviorConfiguration="myMathServiceBehave">
<host>
<baseAddresses>
<add baseAddress="http://localhost:9001/MathService"/>
<add baseAddress="net.tcp://localhost:9002/MathService"/>
</baseAddresses>
</host>
<endpoint address="http://localhost:9001/MathService" binding="basicHttpBinding" contract="MathServiceLib.IMathService"/>
<endpoint address ="net.tcp://localhost:9002/MathService" binding ="netTcpBinding" contract="MathServiceLib.IMathService"/>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
<!--<endpoint address="mex" binding="mexTcpBinding" contract="IMetadataExchange"/>-->
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="myMathServiceBehave">
<!--<serviceMetadata httpGetEnabled="true"/>-->
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
I don't want to use serviceMetadata httpGetEnabled="true" property instead I want to use MEX binding for proxy creation.
Now when I start my service using
svcHost = new ServiceHost(typeof(MathServiceLib.MathService));
svcHost.Open();
I get following error, please help.
The contract name 'IMetadataExchange' could not be found in the list of contracts implemented by the service MathService. Add a ServiceMetadataBehavior to the configuration file or to the ServiceHost directly to enable support for this contract.
Based on my experience, you need to specify
<serviceMetadata httpGetEnabled="true"/>
if you want to use
<endpoint address="mex" binding="mexTcpBinding" contract="IMetadataExchange"/>
The following articles provide comprehensive information and examples:
http://msdn.microsoft.com/en-us/library/ms734765(v=vs.110).aspx
http://www.c-sharpcorner.com/UploadFile/81a718/wcf-service-faqs-part-2/
Below is my WCF service configuration. I use 2 ServiceHost to host 2 service types. They use the same base address, but they use different relative addresses for their endpoints.
But I got this error, why?
Service cannot be started. System.InvalidOperationException: The ChannelDispatcher at 'http://earth:1111/' with contract(s) '"IHttpGetHelpPageAndMetadataContract"' is unable to open its IChannelListener. ---> System.InvalidOperationException: A registration already exists for URI 'http://earth:1111/'.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="serviceBehavior">
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="serviceBehavior" name="Distributed.Troubleshooting.System.IIS.IISServiceType">
<endpoint address="iis" binding="basicHttpBinding" name="iis"
contract="Distributed.Troubleshooting.System.IIS.IISServiceContract" />
<endpoint address="iismex" binding="mexHttpBinding" bindingConfiguration=""
name="iismex" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://Earth:1111/" />
</baseAddresses>
</host>
</service>
<service behaviorConfiguration="serviceBehavior" name="Distributed.Troubleshooting.System.SQL.SQLServiceType">
<endpoint address="sql" binding="basicHttpBinding" name="sql"
contract="Distributed.Troubleshooting.System.SQL.SQLServiceContract" />
<endpoint address="sqlmex" binding="mexHttpBinding" bindingConfiguration=""
name="sqlmex" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://Earth:1111/" />
</baseAddresses>
</host>
</service>
</services>
</system.serviceModel>
</configuration>
Some even more ridiculous findings:
I changed my configuration to this:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="serviceBehavior">
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="serviceBehavior" name="Distributed.Troubleshooting.System.IIS.IISServiceType">
<endpoint address="http://Earth:1111/iis" binding="basicHttpBinding" name="iis"
contract="Distributed.Troubleshooting.System.IIS.IISServiceContract" />
<endpoint address="http://Earth:1111/iismex" binding="mexHttpBinding" bindingConfiguration=""
name="iismex" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://Earth:1111/iis" />
</baseAddresses>
</host>
</service>
<service behaviorConfiguration="serviceBehavior" name="Distributed.Troubleshooting.System.SQL.SQLServiceType">
<endpoint address="http://Earth:1111/sql" binding="basicHttpBinding" name="sql"
contract="Distributed.Troubleshooting.System.SQL.SQLServiceContract" />
<endpoint address="http://Earth:1111/sqlmex" binding="mexHttpBinding" bindingConfiguration=""
name="sqlmex" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://Earth:1111/sql" />
</baseAddresses>
</host>
</service>
</services>
</system.serviceModel>
</configuration>
Then I found I can use "Add Service Reference" in Visual Studio with the following addresses:
http://Earth:1111/iis
http://Earth:1111/iismex
http://Earth:1111/sql
http://Earth:1111/sqlmex
It is possible to host more than one Service with the same base address. Set the HttpHelpPageEnabled and the HttpsHelpPageEnabled properties of all ServiceDebugBehaviors to false, then it should work.
Atention: By default, there's always a ServiceDebugBehavior registered in the behavior's description collection of a host even if it is not specified explicitely (I tried it only with programatic configration and the ServiceHost class, not via XML config). So, you should add an explicit ServiceDebugBehavior and set the mentioned properties. The IncludeExceptionDetailInFaults property can be true.
Have you tried removing one of the Service blocks and combining the endpoints into one?
I cant see any reason why you have them seperated.
Make sure the baseaddress + endpoint address are unique.
You can't host two services with the same base address.
You need to host the other one on a different port or address.
Something like
http://Earth:1111/Service1
and
http://Earth:1111/Service2
I don't really know why this is the case but one solution is to leave the service with no base address and to specify the full address for the endpoints. This doesn't change the address of the different endpoints, nor the addresses unicity. I could not find any relevant reference for this on MSDN.
From my own experience, the problem appears with http and not with net.tcp. I am not using service metadata. I thought the "IHttpGetHelpPageAndMetadataContract" has to do with metadata but found no way to disable it.
You'll also get this error if you accidentally start the same service twice rather than start the two different services.
I know this has been asked many times, and answered many times, but, all the provided samples that should be working don't seem to want to work for me today.
When I try to start the host, I keep getting the following error:
"The contract name 'IMetadataExchange' could not be found in the list of contracts implemented by the service TraceService. Add a ServiceMetadataBehavior to the configuration file or to the ServiceHost directly to enable support for this contract."
My service is being hosted in a managed windows service host as per Microsoft's example: http://msdn.microsoft.com/en-us/library/ms733069%28v=vs.90%29.aspx
And here is my nice and simple config:
<system.serviceModel>
<services>
<service name="Daff.Lae.Service.TraceService">
<endpoint address="" binding="wsHttpBinding" name="TraceService" contract="Contracts.Service.ITraceService">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
<host>
<baseAddresses>
<add baseAddress="http://localhost:8080/TraceService" />
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="DefaultBehavior">
<serviceDebug includeExceptionDetailInFaults="true"/>
<serviceMetadata httpGetEnabled="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
Of course, the problem becomes more interesting when there are no errors if I remove this line:
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
Any help would be very very very greatly appreciated :)
Be sure to specify a behaviorConfiguration in the service element of your configuration in order to allow either httpGet or httpsGet.
I see that you have already defined a serviceBehavior named DefaultBehavior - now all you need to do is add behaviorConfiguration="DefaultBehavior" to the service element, so that line becomes:
<service name="Daff.Lae.Service.TraceService" behaviorConfiguration="DefaultBehavior">
If you don't explicitly specify a behavior for your service, both HTTP GETs and HTTPS GETs are disallowed by default, and your metadata will not be exposed.
As you're using WS-Http you are binding to an HTTPS protocol, so you need to use the correct MEX binding;
<endpoint address="mex" binding="mexHttpsBinding" contract="IMetadataExchange" />
and change the baseaddress to a https one.
Or (the other way around) convert your wsHttp binding to a basicHttp binding and things will start working for you.
`<services>
<service name="MyService.Service1" behaviorConfiguration="Service1" >
</services>
`
where MyService is the application name , Service1 is the default implementation class for IService1
`
<protocolMapping>
//Remove any http or https bindings provided
</protocolMapping>
`
It should help when you use WCF Application Project
I am trying hard to develop a duplex wcf service to be consumed by silverlight clients. Now for adventure sake, I decided to use nettcpbinding. I understand that the concept of PolicyServer to be running on port 943 is obselete now and it should be served from root of the service.
given Below is config section for the service
<behaviors>
<serviceBehaviors>
<behavior name="WcfServer.WcfServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
<endpointBehaviors>
<behavior name="CrossDomainServiceBehavior">
<webHttp/>
</behavior>
</endpointBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="WcfServer.WcfServiceBehavior"
name="WcfServer.MainService">
<endpoint address="" binding="netTcpBinding" bindingConfiguration="TCPBinding" contract="WCFWebFrontCommunication.IMainService">
</endpoint>
<endpoint address="mex" binding="mexTcpBinding" contract="IMetadataExchange" />
<endpoint address="" binding="webHttpBinding" behaviorConfiguration="CrossDomainServiceBehavior" contract="WCFWebFrontCommunication.IClientAccessPolicy" />
<host>
<baseAddresses>
<!--<add baseAddress= "http://192.168.0.101:943/WcfServer/MainService" />-->
<!--<add baseAddress= "http://localhost:943/WcfServer/MainService" />-->
<add baseAddress= "net.tcp://localhost:4502/WcfServer/MainService" />
<add baseAddress="http://localhost:4502"/>
</baseAddresses>
</host>
</service>
</services>
</system.serviceModel>
now at runtime I get an exception HTTP could not register URL http://+:4502/ because TCP port 4502 is being used by another application. when Open Method is called.
Am I doing something silly here .., although http exception was there with basicHttpBinding as well
As Troubleshooting:
checked for open port using Netstat -aon
There were some post regarding HTTP configuration followed them nothing happened
Thanks for reading.
You're trying to host a clientaccesspolicy.xml file over HTTP, and use net.tcp on the same port number, that's not going to work. While both of these protocols build on TCP/IP, they are incompatible.
As far as I understand (see also this article), port 943 is still used for this type of thing.