On our build server, we have a service that calls another service on the same box via net.pipe, but it is failing saying that there is no endpoint listening to net.pipe. IIS does have Net.pipe set for both the calling and called service.
<endpoint address="net.pipe://build.QQQQQ.com/QQQ/QQQ.svc"
binding="netNamedPipeBinding" bindingConfiguration="NetNamedPipeBinding_IMembershipService"
contract="QQQ.IMembershipService" name="NetNamedPipeBinding_IMembershipService">
<identity>
<servicePrincipalName value="host/ABCDF.XX.net" />
</identity>
</endpoint>
Note: build.QQQ.com is actually ABCDF.XX.net. is that the problem, do they need to match even though they are the same.
IMO - they should much.
I'd try to remove last "/QQQ.svc" from address.
Related
I have a wcf service (not self hosted).
When I deleted the section from web.config
<services>
<service name="Namespace.A">
<endpoint address="" binding="basicHttpBinding" name="A_EndpointBinding" contract="A" />
</service>
</services>
it works.
How could that be possible ? Does it occur any problem without that ?
If you can successfully connect and use the service (Namespace.A) using HTTP, then you should have nothing to worry about!
What's happening is either the above is misconfigured or its interfering with other settings and/or hard-coded functionality.
My WCF service has two endpoints(Normal and REST, one for Silverlight client and other for HTML5 client) and my Silverlight client application works perfectly without any issues. When I open my service in the IE, I am getting HTTP 400 bad request. It looks like REST part of my service has some issue. I have given both end points below. Appreciate any help!
Normal end point
<endpoint address="" binding="basicHttpBinding" contract="Test.Service1"
bindingConfiguration="BasicHttpBinding_Config"
behaviorConfiguration="MessageInspectorEndpointBehavior">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
WCF end point
<endpoint address="rest" binding="webHttpBinding" contract="Test.Service1"
behaviorConfiguration="web">
</endpoint>
The request should be made to .../WCF/Test/Service1.svc/rest, since this is the address for the REST endpoint you added in config.
I have a WCF service that uses MSMQ communication, when i run the service on my local netwrok, i configure the service endpoints in the client config files to point to the host computer, for example if the endpoint specified on the service host is:
<endpoint address="net.msmq://localhost/private/MsmqService/MyMsmqService"
binding="netMsmqBinding" bindingConfiguration="test" contract="MsmqService.IMyMsmqService">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
I configure my client to send messages to this endpoint:
<endpoint address="net.msmq://192.168.1.5/private/MsmqService/MyMsmqService"
binding="netMsmqBinding" bindingConfiguration="test" contract="MsmqService.IMyMsmqService">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
Obviously 192.168.1.5 is the IP of the host computer, this works like a charm. I host my service in IIS 7, I activate the MSMQ listener on IIS, give appropriate access right etc (Pretty much everything in Tom Hollanders article) and I can even access my service over http in my browser, but when I create clients of my service which is hosted in IIS and configure the endpoints in the client App.config, naturally I configure my clients to this:
<endpoint address="net.msmq://ServiceHostPublicIP/private/MsmqService/MyMsmqService"
binding="netMsmqBinding" bindingConfiguration="test" contract="MsmqService.IMyMsmqService">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
That's where things go wrong. The messages I send keep getting queued in an outgoing queue on the client machine: DIRECT=OS:[ServiceHostPublicIP]\private$\MsmqService\MyMsmqService
and the state of the queue is always: 'Waiting to Connect'. I've tried setting the queue transfer protocol to SRMP, my queue name is the same as my service name as is required by IIS, and I've given appropriate permissions on the queue. Has anybody recently encountered this problem before? Any Ideas? It'd be great if somebody could share a working sample of MSMQ over HTTP if they had one.
Any help would be greatly appreciated. Thanks in advance.
I managed to fix this, my messages were getting stuck in an outgoing queue on the client machine, "DIRECT=TCP:HOSTSERVERIP\private$\MsmqService/MyMsmqService.svc" the state of the queue was 'Waiting to connect' and the next hop was the destination servers public IP, so the client couldn't connect to the destination queue even though it could ping the destination servers public IP, turned out the port 1801 which is used by MSMQ to listen to incoming traffic was not open on the router of the network on which the service host machine resided, after opening port 1801 everything is working like a charm. It's such a fundamental issue that i guess many didn't bother mentioning it in their articles/tutorials. Hope this helps somebody later on.
I go and setup a service reference to something like
http://localhost/myService/test.svc
However, it apparently does some magic and in the *.disco file (and elsewhere) it ends up with
http://mymachine.mydomain.com/myService/test.svc
I'm trying to understand why this happens.
Update: It seems they're trying to "help" but the IDE continues to give you the impression that you're connecting to localhost. In 99.9% of cases, it probably works out fine. In my case, I'm connecting to a service which checks its licenses against the domain name. Running against "localhost" is to be used for dev and test purposes.
The relevant portion of the *.config file ends up like this:
<system.serviceModel>
<client>
<endpoint address="http://mymachine.mydomain.com/myService/test.svc/Account"
binding="wsHttpBinding"
bindingConfiguration="WSHttpBinding_IAccount"
contract="ServiceReference1.IAccount"
name="WSHttpBinding_IAccount">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
</client>
</system.serviceModel>
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