In my web.config file I have the following service defined:
<services>
<service name="ShareYourWage.Service.WageService" behaviorConfiguration ="metadataBehavior">
<endpoint>
binding="basicHttpBinding"
contract="ShareYourWage.Service.IWageService">
</endpoint>
</service>
</services>
Yet, when I debug the service, the test client throws the following error:
Failed to add a service. Service metadata may not be accessible. Make sure your service is running and exposing metadata.
and digging into the specific error points to the endpoint section shows the following error:
The configuration section cannot contain a CDATA or text element.
I've Googled this error and the MSDN site and have used their examples and still have this problem. A 2nd pair of eyes would be big help, thanks!
You accidentally closed your endpoint tag before the binding and contract attributes.
Remove the '>' at the end of <endpoint>.
You want it to be like this:
<endpoint
binding="basicHttpBinding"
contract="ShareYourWage.Service.IWageService">
</endpoint>
If you're using Visual Studio or some other XML-aware text editor to modify the config files, the syntax highlighting can be helpful for spotting these kinds of problems.
Related
I'm having some issues adding a WCF service reference on a project which is not set as the "StartUp Project". I keep getting "Could not find default endpoint element that references contract ....". and I tried adding the same WCF service reference on my StartUp project and it works fine.
Here's the current app.config client configuration that I use:
<client>
<endpoint address="http://host:8080/library"
binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_ILibrary"
contract="ServiceReference.ILibrary" name="WSHttpBinding_IAccountAccess">
</endpoint>
</client>
not really sure what I'm missing or doing wrong and I already tried entering the complete namespace of the project as the contract.
Thanks,
I have a simple Webserivce (WCF) hosted in a Windows Service(Selfhost). The declaration of the service looks like this :
<service behaviorConfiguration="MyApp.ServiceImplementation.MyAppIntegration_Behavior" name="MyApp.ServiceImplementation.MyAppIntegration">
<endpoint binding="basicHttpBinding" bindingConfiguration="BasicMyAppIntegration" bindingNamespace="MyApp.ServiceImplementation" contract="MyApp.ServiceContracts.IMyAppIntegration"/>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
<host>
<baseAddresses>
<add baseAddress="http://localhost:8008/MyAppServiceutv/Integration"/>
</baseAddresses>
</host>
</service>
I can brows the WSDL with this URL :
http://localhost:8008/MyAppServiceutv/Integration?wsdl
When adding the service reference in Visual Studio 2012 I get this exception :
Exception
The document was understood, but it could not be processed.
The WSDL document contains links that could not be resolved.
There was an error downloading 'http://localhost:8008/MyAppServiceutv/Integration?xsd=xsd0'.
Unable to connect to the remote server
Metadata contains a reference that cannot be resolved: 'http://MyComputer:8008/MyAppServiceutv/Integration?wsdl'.
Content Type application/soap+xml; charset=utf-8 was not supported by service http://MyComputer:8008/MyAppServiceutv/Integration?wsdl. 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'..
If the service is defined in the current solution, try building the solution and adding the service reference again.
Moving to Dev Environment
When moving the service to a dev computer everything works just great? Why whould I get the above problems in just one environment? Could this be due to strong security restrictions?
It sounds like your VS2012 instance is off box from your service host machine. Try changing your config like this...
<service behaviorConfiguration="MyApp.ServiceImplementation.MyAppIntegration_Behavior" name="MyApp.ServiceImplementation.MyAppIntegration">
<endpoint binding="basicHttpBinding" bindingConfiguration="BasicMyAppIntegration" bindingNamespace="MyApp.ServiceImplementation" contract="MyApp.ServiceContracts.IMyAppIntegration"/>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
<host>
<baseAddresses>
<add baseAddress="http://{my fully qualified domain name}:8008/MyAppServiceutv/Integration"/>
</baseAddresses>
</host>
</service>
Okay. Now I have confirmed the problem...an explanation. .net 4.0 or less WCF produces multi-file WSDL files. The base WSDL file links to various files. The link that is in your WDSL file links to the other files using absolute URIs as opposed to relative URIs. So when your Visual Studio tries to find the other WDSL files it fails to find it on "localhost".
With .net 4.5 WCF can generate SINGLE FILE WSDL which will also solve your problem. But overall in my opinion WCF 4.0 is broken when dealing with WSDL proxy generation.
In a WCF service hosted in IIS, I'm trying to set up multiple endpoints. One for SOAP and one for SOAP12. Per the MSDN documentation, I've edited Web.config like:
<services>
<service name="MyNamespace.MyClass">
<endpoint address="" binding="basicHttpBinding" contract="IContract" />
<endpoint address="Endpoint2" binding="wsHttpBinding" contract="IContract" />
</service>
</services>
This doesn't seem to have any effect. There is no answer on URL:
http://localhost:51454/MyClass.svc/Endpoint2
If I change IContract to IContract2, I get the error:
The service '/MyClass.svc' cannot be activated due to an exception during
compilation.
So the Web.config I'm editing is the one being used.
Changing the binding for the default address from basicHttpBinding to wsHttpBinding doesn't have any effect. The WSDL stays the same.
The WSDL includes this bit, which seems to suggest that it's running using a generated binding:
<wsdl:service name="TapasSim">
<wsdl:port name="BasicHttpBinding_IContract"
binding="i0:BasicHttpBinding_IContract">
<soap:address location="http://localhost:51454/MyClass.svc"/>
</wsdl:port>
</wsdl:service>
Why does the WCF service not use the configuration from Web.config?
Why does WCF not listen on /Endpoint2 with the SOAP12 binding?
Why does the default endpoint not change from basicHttpBinding to wsHttpBinding?
Try adling a base adress for the endpoint:
<service name="namespace.Service">
<host>
<baseAddresses>
<add baseAddress="http://localhost:51454/myclass.svc"/>
</baseAddresses>
</host>
// endpoint omnited
Or try adding a slash before the address:
endpoint address="/Endpoint2" binding="wsHttpBinding" contract="IContract"
The MSDN article is correct and there is nothing wrong in your configuration. I created a WCF client using VS and was able to successfully call using
http://localhost:51454/MyClass.svc/Endpoint2
Apparently, it does not appear as a valid url from browser. try consuming from a client using the second url and it should work
The problem was the service name:
<service name="MyNamespace.MyClass">
The class name was wrong. When you enter a wrong contract interface, WCF throws an error. But a wrong class name is silently ignored. That explains why it fell back on the default configuration.
I got this error when trying to access a Service
The type 'WebRole1.RestServices.RegisterService', provided as the Service attribute value in the ServiceHost directive, or provided in the configuration element system.serviceModel/serviceHostingEnvironment/serviceActivations could not be found.
This is linked to the definition on the Web.config file
I defined my service like this:
<!-- Service Authenticate -->
<service name="System.Web.ApplicationServices.AuthenticationService" behaviorConfiguration="AuthenticationServiceBehaviors">
<endpoint contract="System.Web.ApplicationServices.AuthenticationService" binding="basicHttpBinding" />
</service>
<!-- Service Register -->
<service name="WebRole1.RestServices.RegisterService" behaviorConfiguration="RegisterServiceBehaviors">
<endpoint contract="WebRole1.RestServices.IRegisterService" binding="basicHttpBinding" />
</service>
The definition working for the Authenticate Service but not for the Register Service.
I am not sure about the name i should put for the service but WebRole1.RestServices is the namespace for the RegisterService.svc
I am sure the error is from the Web.config file. Anyone has an idea how to correct this.
Thx.
Follow these steps from within Visual Studio:
Right click your service file
Select the View Markup option
Change the value of the Service
attribute to reflect the fully
qualified path of the underlying
service type.
Make sure the CodeFile attribute value is also correct
This happens because when you rename the service type in code it doesn't automatically update the service mark-up directive values appropriately, or at all for that matter.
My employers website has multiple hostnames that all hit the same server and we just show different skins for branding purposes.
Unfortunately WCF doesn't seem to work well in this situation.
I've tried overriding the default host with a custom host factory.
That's not an acceptable solution because it needs to work from all hosts, not just 1.
I've also looked at this blog post but either I couldn't get it to work or it wasn't meant to solve my problem.
The error I'm getting is "This collection already contains an address with scheme http"
There's got to be a way to configure this, please help :)
If you don't put an address in the endpoint then it should resolve to whatever server hits the service. I use this code and it resolves both to my .local address and to my .com address from IIS.
<system.serviceModel>
<services>
<service name="ServiceName" behaviorConfiguration="ServiceName.Service1Behavior">
<endpoint address="" binding="wsHttpBinding" contract="iServiceName">
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="ServiceName.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>
I don't think that the host base addresses solution posted above will work for IIS-hosted websites (the OP did mention that this was for his employer's website).
See this blog post
Also, the other answer further up by thaBadDawg won't work where multiple host headers are specified - you'll just get the errors that the OP mentions ("This collection already contains an address with scheme http".)
I don't think any of the solutions mentioned so far will work, because it doesn't look like WCF allows a single service to be accessible for a single site with multiple host headers from all of the sites. The only workaround I could find for .Net 3.5 (and under) is to create a different contract for each of the host headers, and use the custom ServiceHostFactory to use the correct host header based on which contract is specified. This isn't at all practical. Apparently .Net 4.0 will resolve this issue.
I met this problem several days ago. Actually I have the same situation that Ryu described originally in his question. We have one virtual directory for many customers but each of them has his own binding. Like "http://company1.product.com", "http://company2.product.com" etc.
Solution described here works. But what is the price! We should change web.config each time when we need to add new binding. And also web.config should contain absolute path prefix
like <add prefix=”http://company1.product.com”/>.
It is possible to bypass first problem. I wrote my own CustomHostFactory for WCF service, where I dynamically add endpoints. And this endpoints I retrieve from IIS bindings(there is a way to get information from IIS).
Here is sample code :
protected override ServiceHost CreateServiceHost(Type serviceType, Uri[] baseAddresses)
{
var serviceHost = base.CreateServiceHost(serviceType, baseAddresses);
var webHttpBinding = new WebHttpBinding();
var serviceEndpoint1 = serviceHost.AddServiceEndpoint(typeof(IService), webHttpBinding,
"http://company2.product.com/WCFService/Service.svc");
var serviceEndpoint2 = serviceHost.AddServiceEndpoint(typeof(IService), webHttpBinding,
"http://company1.product.com/WCFService/Service.svc");
var webHttpBehavior = new WebHttpBehavior();
serviceEndpoint1.Behaviors.Add(webHttpBehavior);
serviceEndpoint2.Behaviors.Add(webHttpBehavior);
return serviceHost;
}
And instead of hardcoding endpoint urls, you sould retrieve them from IIS.
But ServiceHost is created once when application starts. So if you need to add new binding, you should restart IIS. It is not a solution for us.
That is why we decided to move to asmx (like is described here).
And wait until Framework 4.0 release, where multiple bindings should be supported.
A simple workaround that doesn't involve any code or config changes is to create yet another website in IIS which points to the same physical directory, and the same app pool, but with a different host-header binding. This can be done for as many different host names as you have.
I'm sure you've figured it out by now, but just for fun I'll post here anyway.
I've had this exact problem and spent forever trying to figure it out. The best solution is to put the host base addresses in your service definition, which allows the service to operate under these multiple addresses. For this solution to work, you still need the ServiceHostFactory to be overridden. Since you've already done that, just leave it in there.
<service behaviorConfiguration="ServiceBehaviour" name="Api.Service">
<endpoint address="soap" binding="basicHttpBinding" contract="Api.IService" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
<host>
<baseAddresses>
<add baseAddress="http://host1.com/Api" />
<add baseAddress="http://host2.com/Api" />
</baseAddresses>
</host>
</service>