I am new to wcf programming and I have been working on a small project and am having problems with net.tcp port sharing. I am using .net framework 4 and iis 7.
I have two wcf services (serviceA and serviceB) being hosted on our server in separate websites on IIS. Each website has its own .svc file, web.config and bin. If I have each of these services on different net.tcp ports then there is no problem and I can add the service reference to each of them from visual studio on my pc. The services run fine.
However we will soon be starting a project with many more services and we wish to avoid having to open a tcp port for each one so I have been trying to get serviceA and serviceB to port share. If I set them up on the same port then I can access the first service I add but when when I try to access the second service added to the same port i get the following error:
Metadata contains a reference that cannot be resolved:
'net.tcp://myserver/serviceB.svc'. The socket connection was aborted. This
could be caused by an error processing your message or a receive
timeout being exceeded by the remote host, or an underlying network
resource issue. Local socket timeout was **. An
existing connection was forcibly closed by the remote host If the
service is defined in the current solution, try building the solution
and adding the service reference again.
I can not work out what is going wrong. I have done a lot of searching on the subject and I have made sure that the following services are running:
Windows Process Activation Service
Net.Tcp Port Sharing Service
Net.Tcp Listener Adaptor
In addition net.tcp is an enabled protocol in the website's advanced settings. My current best guess is that it might have something to do with how I have defined the net.tcp bindings in IIS manager. Both of my websites running their independant services have the following: 808:*(net.tcp) is this correct?
As i said earlier the tcp services run fine if set up on two separate ports so the issue must be related to the port sharing. Very grateful for any advice
OK I found the problem I was having. In IIS I had set up each service as its own website and was trying to get those different websites to port share. This would not work.
However I found that if I set up just one website and then added my services as seaprate applications under the website then the port sharing will work. This approach lets me have multiple services as applications under one website.
Check this.
This can be helpful to you.
http://himanshudesai.wordpress.com/2011/06/03/multiple-wcf-services-on-a-single-port/
Hope this helps.
Related
I want to use my webservice on internet. I opened my port which is 4501 an I disabled firewall on modem and on windows. I can write my global ip and I can open modem control inteface. But I want to connect to iis which address is xx.xx.xx.xx:4501/Products.svc
It works on localhost (http://localhost:4501/Product.svc) But I cant connect to svc on internet ..
I dont know where is problem.
When I add my svc link addres as adding reference service I got this error
There was an error downloading 'http://xx.xx.xx.xx:4501/Products.svc'.
Unable to connect to the remote server
Hedef makine etkin olarak reddettiğinden bağlantı kurulamadı xx.xx.xx.xx:4501
Metadata contains a reference that cannot be resolved: 'http://xx.xx.xx.xx:4501/Products.svc'.
There was no endpoint listening at http://xx.xx.xx.xx:4501/Products.svc that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
Unable to connect to the remote server
Hedef makine etkin olarak reddettiğinden bağlantı kurulamadı xx.xx.xx.xx:4501
If the service is defined in the current solution, try building the solution and adding the service reference again.
And One point more,
If I start to IIS, wcf service doesnt work even in localhost. If I start it in Visual Studio (I mean asp.net development service works) it works..
IIS version is 7.5.7600 and I added application pool as Asp.net 4.0
Is there any specific reason you use port 4501 for HTTP in IIS?
Visual Studio 2010 WebDev WebServer (Cassini) uses random port number (4501 in your case) to simplify configuration. It assumes that port 80 can be occupied by its big brother IIS or any other software.
That is fine for development in local machine but there is no need to use the same port in production.
Default HTTP port is 80 and it is usually the most open open port in networks.
Use port 80 for HTTP traffic in IIS and your life will be much easier.
P.S. Did you try http://xx.xx.xx.xx/Products.svc? Port number is part of web service configuration and it is not copied when you move app to IIS. It is possible that IIS already uses default HTTP port.
I just implemented a simple WCF server using net.tcp.
First, I use 127.0.0.1 as server address and client able to connect the WCF service.
Everything is Ok. But when I try to use the internal IP 192.x.x.x I get an error:
No connection could be made because the target machine actively refused it
Any idea what may cause this?
Best Wishes
PS: I disabled auth on WCF. Even turn off firewall all...Not worked...
Well, I got this error message when I forgot to install necessary components. see link Configuring WCF Service with netTcpBinding
(summary of steps)...
Go to "Programs and Features" (usually in control panel)
Go to "Turn Windows features on or off"
(assuming VS2012) Go to ".NET Framework 4.5 Advanced Services"->"WCF Services"
Enable "TCP Activation"
Do you use 192.x.x.x on both client and server? I remember seeing an issue a while back in which for TCP the client and server names needed to match (something related to one of the message properties), so if you define the service with "localhost" and the client with <machine name> there would be a problem.
The physical client and service addresses can differ if the logical address is the same and the server endpoint has been configured with a "listenUri" and the client behaviour is configured to use a <clientVia> address. In our case, this is required in for our proxy/firewall configuration. In effect, the client calls the firewall and the server listens locally for a forwarded request.
For an IIS-hosted service, check the following:
The Application pool is started and looks correct (.NET 4 etc/security)
For NET.TCP, ensure the "Allowed Protocols" in the Web Site/Application (via advanced settings) are configured correctly: e.g. http,net.tcp
For a non-IIS hosted service, you may need to configure a Namespace Reservation (URLACL). http://msdn.microsoft.com/en-us/library/ms733768.aspx
Also ensure the appropriate Windows Services are running, e.g. Net.Tcp listener.
If you're running from within visual studio in debug mode, ensure your solution port numbers match. I have seen several instances where I had Properties>Web>Auto-Assign Port - selected and the endpoint from, in this case my silverlight app, didn't match the port auto generated. I usually change the port to 1318 in my .web.
Today I found out that this error will also show up if you have a circular reference in your WCF Service Class. I had a method that was calling itself infinitely and causing this error message, which led me here.
So if none of the other suggestions work, check your code to see if you're doing any recursive functionality and make sure you're not caught in an infinite loop.
I resolved this issue by either commenting this setting in the application configuration:
<defaultProxy>
<proxy bypassonlocal="False" usesystemdefault="True" proxyaddress="http://127.0.0.1:8888" />
</defaultProxy>
or, running Fiddler which would take the WCF call at 127.0.0.1 and then forward it.
The complete scenario is, I encountered the same issue with WCF calls made to one of the service. The calls would fail with top level error message "There was no endpoint listening at http://LinuxIP:Port/...", and service trace viewer log showing inner exception to be "No connection could be made because the target machine actively refused it 127.0.0.1:8888
".
The reason was that I had put this configuration in my application to capture the outgoing traffic in Fiddler. If this configuration is in place then the Fiddler needs to be running for the WCF calls to make it to the intended destination. If Fiddler is not running this error will be there. Comment this setting in such scenarios, and the WCF call will go to the destination.
I am hosting 3 WCF services inside windows services.Each WCF service contains Multiple endpoints. Right now, i am host all my endpoints thru TCP binding on different ports.
Is there any way to host all these end points from different wcf services on same port?
Sure is! You can use the Net.TCP Port Sharing service.
Net.TCP Port Sharing on MSDN
I just looked into that, out of curiosity. The behavior I discovered seems so strange that I almost don't want to put it here. But it worked in my case, so maybe it's doing the same for you:
I am getting the AddressAlreadyInUseException when I'm trying to host 2 services (i.e., 2 separate ServiceHost instances) on the same net.tcp port with portSharingEnabled="True" set on the netTcpBinding for both. That happens with or without the Net.Tcp Port Sharing Service running. The exception is thrown even if I only start one of the services (and I verified via netstat that there was no other listener on that same port on the machine, plus, I ran the app with elevated privileges).
Now, the funny thing is, the AddressAlreadyInUseException is not thrown when I set PortSharingEnabled = False, and yet both services are fully working!! Once again, with or without the Port Sharing Service running. I could even successfully connect to those services from a different machine.
An important note to make, however, is that the above only applies if the services are hosted within the SAME PROCESS! It does blow up if I try to start another instance of the app that's listening on the same port, but a different base address. But I'm assuming you're hosting those 3 WCF services inside the same Windows Service?
So, even though it doesn't seem right, my answer would be to disable PortSharingEnabled and see if it works with different BaseAddresses on the same port (provided they're all inside the same process).
As far as I know you not only have to enable port sharing on the configuration (or via code), you also have to manually start the Windows Port Sharing service.
That's the reason why I (having similar problem) didn't want to use port sharing, to make it easier for deployment rather than having to mess with other things the user may or may not know.
I am consuming a web service in .NET application with WCF client.
The Endpoint's address of the service is over port 4338, and it is over HTTPS, secured with WS-Security standard.
So the address is something like :
https://[servername]:4338/[servicename]/
I was not able to communicate to the service with just running the application.
it gave me the following error :
Could not connect to [servername]:4338
TCP error code 10060: A connection
attempt failed because the connected
party did not properly respond after a
period of time, or established
connection failed because connected
host has failed to respond
[servername]:4338
But when I run Fiddler to investigate the http communication, the application start to work, and I will be able to communicate to the service.
As well, I want to add that I have a different service on the same web server that hosts the first service, and that second service's address is hosted on port 8080, and I am able to communicate with it with WCF client (without running Fiddler).
So, I googled and I found that it might be related to the proxy settings. Do you know what the problem is, and how can I solve it?
Thanks
Fiddler acts as an Internet proxy server. In general, any symptom of the form: "it works when I use Fiddler" means "it works when there's a (different) proxy server".
Check your proxy server settings. In particular, as empi suggested, try it in a browser. If it works there, it could be due to the fact that the browser has the proxy settings configured, and that you do not have them configured for WCF.
If you have proxy set in Internet Explorer, it may cause the problem. What happens when you open https://[servername]:4338/[servicename]/ in Internet Explorer?
Thanks empi for the reply.
I found the answer.
Actually in our company we have a proxy settings through "Automatic configuration script"
and depends on the web sites we are targeting internally, the script will point us to the proper proxy.
So, from the script I got the proper proxy address.
and in my .NET application I added this code
WebRequest.DefaultWebProxy = new WebProxy("http://xx.xx.xx.xx:8080");
and that fixed the problem
So WCF client was not detecting the setting of the automatic script.
and this is the reason it worked when I run Fiddler, because Fiddler listen to the http communication, and send it again through the settings.
Here's the scenario: A client machine has connected to the 'Work network' via VPN (Cisco VPN Client). The work network hosts a machine that has a WCF service with nettcp binding. The client tries to connect to this service and gets an exception as follows:
Could not connect to
net.tcp://workMachine:2010/SomeService.
The connection attempt lasted for a
time span of 00:00:01.3180754. TCP
error code 10061: No connection could
be made because the target machine
actively refused it workMachine:2010.
Things I tried:
Changed the Workgroup of the client
machine to the work network
workgroup
Added domain/username/password for the Windows Networking Password vault, so that it can be used to connect
Changed the wcf service path with an IP address instead of the workMachine name
Checked client machine firewalls and added to allow the wcf client through it
All above failed and didn't work.
Has anyone encountered similar issues?
The client machine is on Windows 7
SecurityMode of the WCF service is set to NONE - so that shouldn't be an issue.
Any insights will be helpful
You may need to supply client credentials explicitly through your proxy object.
Assume that the proxy object in the code below implements one of the ClientBase interfaces.
proxy.ClientCredentials.Windows.ClientCredential.UserName = "clientaccount";
proxy.ClientCredentials.Windows.ClientCredential.Password = "S3cr3t1337Pwd";
Could you - just for testing purposes - expose the same service on the same machine using a HTTP endpoint, and try to connect to that one from your VPN client?
NetTcp is an excellent choice behind the corporate firewall - just don't know how the Cisco VPN client might cause troubles here, that might not show up when using an http-based protocol. Just a wild guess for now, but if you have nothing else to go on, give it a try!
Marc
Just another thought to assist with debugging of these kind of issues, using CMD execute "netstat -a" (you can append the -o switch and find the related process id also) and see if the port in question is currently open, if it isn't you may have an issue with the SMSvcHost.exe (this is the Windows process for managing an IIS hosted TCP Service).
I've had this issue before and rectified it by restarting the following services (obviously you'll need to carefully consider this if you are dealing with a live production system):
NetTcpActivator (Net. Tcp Listening Adapter)
NetTcpPortSharing (Net. Tcp Port Sharing Service)
and possibly if relevant:
NetMsmqActivator (Net. Pipe Listener Adapter)
NetPipeActivator (Net. Pipe Listener Adapter)
Hope this helps someone!
J.