I've been trying to have my Silverlight application work with a WCF net.tcp binding the whole day and couldn't make it, even though it seems to me I've done everything right, including after some googling...
I had a WCF service with a basicHttpBinding endpoint which worked perfectly, and as my WCF service and my Silverlight application are on the same network, told myself "why not trying something else than HTTP ?"
So I began googling to see what had to be done, and here's the list of what I did :
Server
Checked that Net.Tcp Listener Adapter service was running
IIS
Enabled net.tcp binding on my website, with binding information set to "4502:*"
Added net.tcp protocol to the Application that hosts my WCF service
Added a policy in the clientaccesspolicy.xml file to allow socket connection on ports 4502-4536
WCF Service
Added a net.tcp binding with Security set to None
Added an endpoint with this binding for my service, keeping the regular HTTP one
After doing all this, I can use my WCF service with WcfTestClient, it sees the two endpoints (HTPP and net.tcp), and both of them work like a charm.
In my Silverlight application, I can update my service reference (which I added with the HTTP address of my service, not the TCP one), and it also sees the two endpoints because it added the TCP endpoint in the ServiceReferences.ClientConfig. As I saw when googling, netTcpBinding is not supported in Silverlight, thus it describes the binding as a custom binding with a and a element.
I saw on the different tutorials I followed that, as for the HTTP binding, Silverlight asks for a socket policy file to check if the client has access to the WCF service. In SL4 Beta, this file was requested by TCP on port 943. As of SL4 RC and RTM, it's requested by HTTP on port 80, as it is for the HTTP bindings.
The thing is, when I launch my application with the proxy set to use the net.tcp binding, I checked with Fiddler, the clientaccesspolicy.xml is NOT requested at any time, and I get the classic error when the socket policy file is not present : TCP error code 10013: An attempt was made to access a socket in a way forbidden by its access permissions.
After googling, I found out that SL looks for this file with the IP address of the server, not its name, but trying http://IP_OF_MY_SERVER/clientaccesspolicy.xml in a browser on my client machine serves the file as expected...
So I'm a bit lost here, I would really like to have it working to see something else than HTTP with WCF...
Someone has any bit of a clue to guess what happens ???
As the service works as expected with WcfTestCLient with the net.tcp binding, I'm guessing this has something to do specifically with SL...
Thanks for reading :-)
Related
I would like to create a web site in IIS that hosts a WCF service using net.tcp binding. Since there is no need for the http binding, I would like to remove this. However, if I remove the http binding (and leave only the net.tcp binding) from the IIS manager, the site appears with a red X on top of it, and there are no longer an option to Start/Stop the site in the context menu.
If I try using the PowerShell cmdlets Start-Website or Stop-website I get the error message: "The object identifier does not represent a valid object. (Exception from HRESULT: 0x800710D8)".
Is it not possible to have a site with only a net.tcp binding in IIS? Do I really need to reserve a port for http, even though it won't be used, or is there some configuration option I am missing here?
As you may know, IIS 6+ can share port 80 with other HTTP applications running in different processes.
However my self-hosted WCF service seems to take IIS offline. When the WCF service is running, all HTTP requests go to the service. When I stop the service, all HTTP requests go to IIS. This is despite the fact that the two applications are using very unique URI paths. What's the deal? How do I get them to play together nicely?
EDIT:
My WCF service uses a custom binding with an HttpTransportBindingElement
Sorry if this belongs on serverfault. I'm not sure if it's a configuration issue or code issue.
After a lot more experimentation, I've come to a conclusion.
It looks like the problem is caused when the endpoint base address of the WCF service is the same as the base address of IIS. In other words if an endpoint exists at http://localhost/, it will take over and handle all incoming HTTP requests.
So even if your WCF subpaths are different from IIS, the base endpoint address has to be something other than http://localhost/.
situation:
my website (which contains the WCF service) is hosted in IISExpres port number 58366 (http://localhost:58366/myapp)
I have a winforms client which connects to the wcf service using BasicHttpBinding
I want to debug my wcf calls using fiddler, but can't seem find how to redirect wcf calls through fiddler.
IISExpress idiotically binds to the hostname "localhost", not just to the port, so conventional workarounds as with adding a dot to the hostname don't work. Solution seems to be here. Note the last part of the selected answer: Use "localhost.fiddler" and Fiddler will emit "localhost" when proxying.
Rick Strahl has a good article on this here: http://www.west-wind.com/weblog/posts/2009/Jan/14/Monitoring-HTTP-Output-with-Fiddler-in-NET-HTTP-Clients-and-WCF-Proxies
Pretty sure a winforms app will usually pick up the default system proxy as set by fiddler. Are you operating on localhost? Try connecting to your machine name.
I'm using IE8 and can't connect to my WCF service using net.tcp. I'm able to access the same service with http binding just fine. I got two binding enabled in app.config (net.tcp, http). Can anyone tell me if there is a settings that I need to set/play with for viewing service using net.tcp in IE.
You cannot connect to a WCF service using the netTcpBinding through IE.
What you need is a "real" WCF client app, or something like WCF Test Client which is shipped with WCF in the box - just find it and start using it!
Make sure you have a HTTP base address, for your service and a mexTcpBinding endpoint.
Is anybody familiar with setting up WCF-nettcp adapters for BTS?
When I create a WCF-netTcp adapter for a Receive location, I am unsure how/when BTS will open up port 808 to listen on the address URI specified. It appears to only happen if I restart the entire BizTalk application. If it closes for some reason, I do not see any way of reconfiguring and reopening the port.
Furthermore, since that is only the net.tcp binding, there is no mex endpoint exposed. I believe client applications that wish to use that exposed WCF service needs mex metadata initially. Accessing that endpoint direct from a Visual Studio project would just yield
Metadata contains a reference that cannot be resolved: 'net.tcp://biztalkserver/PostReceiveLocation_TCP/PostReceiveService.svc'.
Metadata contains a reference that cannot be resolved: 'net.tcp://biztalkserver/PostReceiveLocation_TCP/PostReceiveService.svc'.
If the service is defined in the current solution, try building the solution and adding the service reference again.
Cannot tell for such how to properly expose a mex endpoint to the service. the BizTalk WCF Service Publishing Wizard is confusing me; I cannot get it to reference the WCF adapter/Receive location I setup. I find no document that teaches what one ought to do for netTcp services; it is all about Http.
Funny, it took the walkthrough about publshing Net-Msmq WCF service to nudge me thinking how the WCF Service Publishing Wizard really works.
The issue is this: When I manually created the WCF-netTcp Receive location, it has its endpoint URI e.g. net.tcp://biztalkserver/PostReceiveLocation_TCP/PostReceiveService.svc. When selecting the option to publish just an mex endpoint in the WCF Service Publishing Wizard, it will eventually ask for the WCF Service Location, which i confused to be the actual service location. Since it would accept nothing but Http URLs, it appeared to only support Http-based WCF endpoints.
But for that textbox, one is supposed to place the Http URL that for just the mex endpoint, not the actual net.tcp WCF endpoint. That is the location in IIS where the wizard will create the necessary meta-data files. Once finished, that location, hosting a mex endpoint will inform clients of the real service located at the net.tcp endpoint.