I'm wondering about the address="" section in the web.config file
<services>
<service behaviorConfiguration="MyServiceTypeBehaviors" name="user">
<endpoint address="" behaviorConfiguration="ptUserAspNetAjaxBehavior" binding="webHttpBinding" contract="IUser" />
</service>
</services>
<services>
<service behaviorConfiguration="MyServiceTypeBehaviors" name="controller">
<endpoint address="" behaviorConfiguration="ptUserAspNetAjaxBehavior" binding="webHttpBinding" contract="Icontroller" />
</service>
</services>
I'm adding a second service that I will be calling via jQuery. My first service worked great. As you can see the endpoint address is blank. I'm adding the second service and I'm wondering first if I'm doing it correctly? Can I create a new service tag using the same behaviorConfiguration, and binding but with a different contract?
This spawned another question about the address in the web.config file.
Why does it work when it is = "" and why would I want to use an address?
It will work with address="" when
you host your service in IIS and basically IIS's virtual directory dictates the URL of your service (the vdir where your *.svc file exists). Thus if you have two separate services, with two separate *.svc files, then each entry in the configuration can have an address="" setting. But you cannot have two endpoints for the same service and both have the empty address attribute
or:
you have a base address defined for your service in your config and thus that endpoint will use that base address for its service address
Related
I have an existing Windows service (so no IIS) which hosts a WCF-service.
At this moment it is listening one address: http://xxx/service.svc.
And now I want it to ALSO listen to a second address: http://yyy/service.svc.
I can only modify the configuration, not the sources. The service is running under .NET Framework 4.5.2.
My configuration:
<services>
<service behaviorConfiguration="All" name="MyNamespace.MyService">
<endpoint address="" binding="basicHttpBinding" bindingConfiguration="myBindingConfig" contract="MyNamespace.IMyService"/>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
<host>
<baseAddresses>
<add baseAddress="http://xxx/service.svc"/>
</baseAddresses>
</host>
</service>
</services>
What I have tried so far:
Added an extra base address. Then I get an exception: This collection already contains an address with scheme http.
Duplicated the service-element and modify the base address. Exception: A child element named 'service' with same key already exists at the same configuration scope.
If I change the name of both services: Service 'MyNamespace.MyService' has zero application (non-infrastructure) endpoints.
If have read about and tried serviceHostingEnvironment (as suggested in WCF service startup error "This collection already contains an address with scheme http") but only adding that snippet in, does not help. Maybe that is a half step forward, but then I need the second half of that solution.
I host a WCF service in IIS and want to expose multiple endpoints (with different enpoint behaviours). The base address is determined by the IIS virtual directory and the .svc file name as I understand. I use the address attribute on the endpoints to distinguish them. For one endpoint I leave the address blank, because this is the default endpoint that is already in use by applications. On the other endpoint I set an address.
Is it possible that the order of endpoint tags in the config file does matter?
For the first configuration always the endpoint with the blank address kicks in, no matter it is addressed from the client with /Test or not:
<endpoint binding="basicHttpBinding" bindingConfiguration="myBindingCfg" contract="myContract" address="" behaviorConfiguration="myBehaviorCfg" />
<endpoint binding="basicHttpBinding" bindingConfiguration="myBindingCfg" contract="myContract" address="Test" />
For the second configuration everything works fine:
<endpoint binding="basicHttpBinding" bindingConfiguration="myBindingCfg" contract="myContract" address="Test" />
<endpoint binding="basicHttpBinding" bindingConfiguration="myBindingCfg" contract="myContract" address="" behaviorConfiguration="myBehaviorCfg" />
I have very specific question..
If i create one WCF Service and it has multiple endpoints with the name how can i access that using browser ?
Also How can i access that in my client application via Add Service Reference ?
like my config code:
<services>
<service name="MultipleEndpoint.SampleService" behaviorConfiguration="MultipleEndpoint.SampleService">
<host>
<baseAddresses>
<add baseAddress="http://localhost:55052/SampleService.svc"/>
</baseAddresses>
</host>
<endpoint address="/basic" binding="basicHttpBinding" contract="MultipleEndpoint.ISampleService" bindingConfiguration="basicBinding" >
</endpoint>
<endpoint address="/wsHttp" binding="wsHttpBinding" contract="MultipleEndpoint.ISampleService" bindingConfiguration="wsBinding" >
</endpoint>
<endpoint address="/webHttp" binding="webHttpBinding" contract="MultipleEndpoint.ISampleService" behaviorConfiguration="REST">
</endpoint>
</service>
</services>
Now, when i tried to access that using
http://localhost:55052/SampleService.svc/basic or
http://localhost:55052/SampleService.svc/wsHttp
it gives me page/ resource not found IE Standard Error Message...
Same time i like to know how would i add this type of url as a service reference in my client application ?
Those service addresses are different and they are not strictly needs to be brow-sable, means you can't browse a service for an endpoint like http://localhost:55052/SampleService.svc/basic. Those addresses are used to distinguish endpoints in communication.
If you see the wsdl of the service all the addresses of those endpoints are specified there.
If you create the proxy of the service through "Add Service Reference" all the endpoints are created in the configuration separately like..
<client>
<endpoint address="http://localhost:54671/Service1.svc/basic"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_IService1"
contract="ServiceReference1.IService1" name="BasicHttpBinding_IService1" />
<endpoint address="http://localhost:54671/Service1.svc/ws" binding="wsHttpBinding"
bindingConfiguration="WSHttpBinding_IService1" contract="ServiceReference1.IService1"
name="WSHttpBinding_IService1">
</endpoint>
...
</client>
Say if you want to talk to the service using the basic http endpoint then you can create the proxy for that by passing the corresponding endpoint configuration name in the ctor.
Ex.
// this will uses the basic http endpoint.
Service1Client client = new Service1Client("BasicHttpBinding_IService1");
Is it possible to host 2 WCF services of the same type and contract on the same AppDomain?
In the configuration below, I am configuring a single service of type Service.SomeService that implements contract ISomeService. what I want to do is be able to host 2 services of this type, of course with different URIs.
<system.serviceModel>
<services>
<service name="Service.SomeService">
<endpoint address="net.tcp://localhost:8000/SomeService"
binding="netTcpBinding"
contract="Service.ISomeService" />
</service>
</services>
I am also self hosting these services in a windows service.
Thanks.
Yes, a Windows Service can host Multiple WCF Services. Each WCF service must have a unique address however. When you add endpoints to a ServiceHost instance, you must specify a unique address for each end point, which means you must vary atleast one of the scheme (net.tcp, net.pipe, http, etc), domain, port or path.
So basically I should be able to do this by adding multiple endpoints to a service:
<services>
<service name="Service.SomeService">
<endpoint address="net.tcp://localhost:8000/SomeService1"
binding="netTcpBinding"
contract="Service.ISomeService" />
<endpoint address="net.tcp://localhost:8000/SomeService2"
binding="netTcpBinding"
contract="Service.ISomeService" />
</service>
I appears that service type and contract in the configuration file should be unique. But is it possible to instead add 2 services of the same type and contract instead of adding 2 endpoints to the same service?
I appears that service type and
contract in the configuration file
should be unique.
Why? They don't have to be unique - no way. What has to be unique is the address (the complete one) for the service endpoint - of course, how else would WCF know where to send certain requests?
But is it possible to instead add 2
services of the same type and contract
instead of adding 2 endpoints to the
same service?
Sure, no problem:
<services>
<service name="Service.SomeService">
<endpoint address="net.tcp://localhost:8000/SomeService1"
binding="netTcpBinding"
contract="Service.ISomeService" />
</service>
<service name="Service.SomeOtherService">
<endpoint address="net.tcp://localhost:8000/SomeService2"
binding="netTcpBinding"
contract="Service.ISomeOtherService" />
</service>
</services>
I have been told that wsHttpBinding does not support older clients that still need to use older version of SOAP. I want to add a BasicHttpBinding endpoint in the same WCF Service Application so that clients can use either endpoint depending on their technology they are running. I am confused as to what the address to use for each of them. The default wsHttpBinding has no address set. What should the address be for BasicHttpBinding endpoint? Shouldn't the address for the wsHttpBinding be (for my example) http://localhost/WcfService1/Service1.svc ?
There's two things you need to consider here:
if your hosting in IIS (or WAS as part of IIS7), you cannot set a base address - the base address for your service will be the virtual directory where the MyService.svc file lives. You can still set relative addresses, though
if you self-host, you typically will add base addresses in your config, so you can spare yourself having to spell out the entire address all the time (but you can - if you wish to do so).
So if you have your MyService.svc inside a virtual directory called MyApp on your localhost machine, and then use this config:
<service name="MyService" behaviorConfiguration="Default">
<endpoint
address="wsHttp"
binding="wsHttpBinding"
contract="IMyService" />
<endpoint
address="basic"
binding="basicHttpBinding"
contract="IMyService" />
</service>
then your "old-style" basicHttp service will be reachable at:
http://localhost/MyApp/MyService.svc/basic
and your new wsHttp driven service will be reachable at:
http://localhost/MyApp/MyService.svc/wsHttp
You can name those relative addresses (anything after .../MyApp/MyService.svc) anything you like - just make sure they're different from one another.
Hosting in IIS --> location (virtual directory) of your *.svc file becomes your base address.
If you self-host your service inside a console app or a Windows NT Service, you get to set your base addresses yourself:
<services>
<service name="MyService" behaviorConfiguration="Default">
<host>
<baseAddresses>
<add baseAddress="http://localhost:8185/Services/" />
</baseAddresses>
</host>
</service>
</services>
Now in this case, your "old-style" basicHttp service will be reachable at:
http://localhost:8185/Services/basic
and your new wsHttp driven service will be reachable at:
http://localhost:8185/Services/wsHttp
You can define a base address for each of the transports, e.g. one for http://, one for net.tcp:// and so on.
And of course, if you really must, you can also define your complete addresses inside your <endpoint> element for each of the service endpoints - this gives you total flexibility (but only works in self-hosting scenarios).
Marc
In WCF you have a base address and an enpoint address, in your case you can do something like this:
<service name="WcfEndpoints.Service1" behaviorConfiguration="WcfEndpoints.Service1Behavior">
<!-- Service Endpoints -->
<endpoint address="new" binding="wsHttpBinding" contract="WcfEndpoints.IService1" />
<endpoint address="old" binding="basicHttpBinding" contract="WcfEndpoints.IService1" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
Note you will need additional work for the basicHttpBinding endpoint to work with older (asmx) clients
http://msdn.microsoft.com/en-us/library/ms751433.aspx