After following the tutorial, I've succeeded running it on localhost:8534/simpleprime/api/values/* having the same result as the tut.
Later publishing the solution to a remote cloud cluster, I couldn't access it using www.clusterurl:8534/api/values, timing out each time. Even though I got reassuring event diagnostics from Visual Studio during the deploy.
I've also tried each of the nodes seperetly, going to
http://node_ip:8543/simpleprime/api/values, without any luck
simpleprime is the appRoot
If you want to access your service with OWIN listener on Azure, you should define ports that will be used by your application for the LoadBalancer during cluster creation.
If you for some reason forgot you can do it later by:
SERVICE PART
Go to PackageRoot/ServiceManifest.xml of your service with OWIN Listener
Define your endpoint directly (so SF will use your definied port number) (in my example 8081)
Re-publish application to Azure.
AZURE PART
Go to Azure Portal
Find the Load Balancer that is assigned to your SF (LB-nameofyourSF-namofNodeSet)
In LoadBalancer settings go to Probes and add new probe like on the image below with your Port defined in ServiceManifest.xml (on my example 8081) and Protocol TCP
Add new Load balancing rule with your port and probe defined earlier and the correct port mapping (in my example 8081):
Save and now you should be able to access your service on Azure via browser.
Finally solved it, inside the service port config (a.k.a ServiceManifest.xml) there is a port setting. After changing it to 19080 - the default http port my cluster was listening to, everything started working.
Related
I wrote a WCF service in visual studio 2017. I then added this service to IIS (not the express version but the full fledge IIS). It is added as an application under the default created website. I can access my service end-point without any issues at http://localhost/<websitename>/MyService.svc/test/123. /test/123 is just a simple GET endpoint.
The default website is already configured for port 80.
However, when I changed the port from 80 to say, 1234, it does not work. It merely returns me "Service Unavailable. HTTP Error 503." when I hit the /test/123 endpoint.
I have already executed the console command to add the port to ACL netsh http add urlacl url=http://+:1234/ user=everyone.
Does anyone know how can I get another port (non 80) to work?
Edit:
I am aware that there is an answer How to run WCF service on a specific port which explains how to bind to another port. However, the accepted answer uses the net.tcp protocol. I would like to use the HTTP protocol.
Is there any way to do it with HTTP protocol? If it cannot be done, then I guess ill have to redesign and swap over to net.tcp protocol.
I am extremely new to .NET development and WCF, so hopefully somebody with experience can point me in the right direction.
As it turns out, the problem had nothing to do with the so-called linked answer.
Prior to running my WCF service in IIS, I was trying to deploy it as a WAS and then Console application. In my process of getting those 2 implementations to work, I had to execute the command netsh http add urlacl url=http://+:1234/ user=everyone so that the port could be accessed.
By sheer luck, i stumbled upon this link:
https://serverfault.com/questions/666976/service-unavailable-if-i-try-to-access-iis-website-via-ip-address-works-fine-vi
Although it didnt have an accepted answer, the comments held the answer. My problem was caused exactly because I executed the netsh command. What happens is that the command causes that ip/port to be reserved, and thus, IIS cannot attach to the ip/port and therefore the Service Unavailable error. I assumed that if the WAS and Console version needed that command to be executed, then the IIS version needed it as well.
As for letting an IIS WCF Service be available on any other port, the process is super simple. Within IIS itself (Execute "inetmgr" in Run to launch), in the default or custom website you created, edit the binding and change the HTTP port to whatever port that you want. After that, its done. You should be able to access your application/website from that port via HTTP.
Eg:
http://localhost:<some port>/<websitename>/MyService.svc/test/123
My WCF Service config was a standard config that allowed for HTTP access.
If you would like to access it from another computer or from the internet, then you will need to configure your router to port forward your selected port (if needed) and ensure that your firewall allows data flow for that port.
Many "thanks" to the downvoters who assume this was some duplicate. Your "help" contributed in finding a solution to the problem.
I have 3 self hosted WCF windows services communicating with each other over http port 80 using basic http binding. On the same machine I have a website (also running on default port 80) hosted in IIS which also manages and communicates with one of those services. Everything works fine within this windows 10 hosting machine i.e. the website can talk to the services and the services can talk to each other.
When I try to access the website from another PC on the network I get a message in the browser saying 'server DNS address could not be found'. I can't even access the WCF service metadata url.
This looks like a firewall issue on the host machine so I added inbound and outbound rules for TCP port 80 and made sure the rules 'World Wide Web Services (HTTP Traffic-In)' and 'World Wide Web Services (HTTPS Traffic-In)' are enabled. None of these changes worked so I removed the TCP rules I added.
Finally I disabled the firewall completely and I was able to access the website from another PC. However, when I re-enabled the firewall, the website continued to work and all of a sudden my WCF metadata is also accessible!
I don't understand why this is happening. I have successfully recreated the problem several times.
Can anyone offer an explanation or suggest any other firewall rules to try?
My end goal is to package up the services and website into an installer so I don't want my end users to have to mess around with the firewall. They may not even be able to turn it off and on again.
Many Thanks
How about outbound rules on port 80 for http?
Finally figured it out. The url I was using to access the hosting machine used the machines name. In order for the machine to respond to a name lookup was to enable the firewall rule called 'Network Discovery (NB-Name-In)' for the public profile. This rule allows traffic on UDP port 137. Once the name lookup has been cached the url will be properly routed. This explains why it worked after I disabled then enabled the firewall again.
I'm running an Azure webjob alongside an Azure webapp. The job runs periodically and the result of the job is needed in the webapp. How do I get the result there?
I tried with a WCF netNamedPipeBinding but since there are no startup tasks for Azure webapps I cannot add a net.pipe binding to the IIS website nor can I enable the net.pipe protocol.
I have it working now with a basicHttpBinding but this binding is exposed to the entire internet which I absolutely do not want. I simply want machine-local communication between a webjob and webapp running on the same machine.
CORRECTION: I thought I had it working on Azure but that is not the case. When running on Azure I get an error from the webjob: An attempt was made to access a socket in a way forbidden by its access permissions 127.0.0.1:80 (using basicHttpBinding). Probably the webapp has an internal port number I don't know.
You have a few options:
Use the file system to pass messages
Use Azure Storage Queues to pass messages between the two
Use Azure Service Bus Queue to pass messages
Use any shared storage (database, Azure Storage, etc) to pass messages
The benefit of all these approaches is that it makes your message passing async and thus more resilient to one of the two services (web app or web job) going down for some time.
You can use the file-system to communicate between the WebJob and the Websites.
It is shared between them and between all of your instances.
Simply write a file from the WebJob and use a file system watcher in your webapp to recognize when a file is created or changed.
Note you cannot communicate through localhost in Azure Websites (or WebJobs) and cannot listen on a port that is not 80/443.
You can use azure service bus queue, then point your service (web app) to consume messages from queue.
The closest answer is to set WEBSITE_DISABLE_SCM_SEPARATION=true in App Settings. This will enable WebApp and SCM processes work in same sandbox. Unfortunately this option is deprecated by Azure and no longer supported. Thanks all for attempting the answer. More information can be found here.
We have a WCF application with multiple bindings running on Windows Services, the application is working as expected on an intranet environment however when we deployed our solution to windows azure VM, it seems all our services are running fine except those that uses wsdualhttpbinding binding !!!
Our services are running on port 8099 therefore we created an endpoint on VM with public and private ports set to 8099, we also disabled the firewall for the time being. we even try to use Azure network to establish a point to site VPN but none of them worked.
we set the base address as http://XXX.cloudapp.net:8099/MYSvc but again same issue...
This solution is working fine if I run the client application on the same machine that hosts the services on azure however if I try to use another machine it fails. I even tried to create another VM on the same subnet and run the client app from within azure network to replicate an Intranet environment, again no success...
There is no error to copy here, it seems when the client app reaches a duplex service, it keeps waiting for a response and does not allow user to do anything!
Is it because of traffic routing or .... any suggestion? are we missing something?
We prefer to use wsdualhttpbinding unless there is no solution...
Since nobody answered the question and due to the fact I found a solution, I like to share it here in case somebody need it.
On azure wsdualhttpbinding cannot find the client address just because of routing issues, so even if you use VPN the issue persists.
The solution is to use ClientBaseAddress as for your wsdualhttpbinding binding like so:
WSDualHttpBinding dualBinding = new WSDualHttpBinding();
EndpointAddress endptadr = new EndpointAddress("http://XXX:12000/DuplexTestUsingCode/Server");
dualBinding.ClientBaseAddress = new Uri("http://XXX:8000/DuplexTestUsingCode/Client/");
refer to this link
http://msdn.microsoft.com/en-us/library/system.servicemodel.wsdualhttpbinding.clientbaseaddress(v=vs.110).aspx
and aslo here:
http://social.msdn.microsoft.com/Forums/vstudio/en-US/e5fca7a5-9a90-48de-a81c-ec2e18b7ae6a/wsdualhttpbinding-and-clients-on-remote-machines
You have to bear in mind that the load balancer closes any idle connections after one minute. You can't turn off this behavior on Azure, so if your process takes more than a minutes, the callback channel will be closed by load balancer and you get timeout exception.
I have a web service that I created in C# and a test harness that was provided by my client. Unfortunately my web service doesn't seem to be parsing the objects created by the test harness. I believe the problem lies with serializing the soap packet.
Using TCPTrace I was able to get the soap packet passed to the web service but only on a remote machine so I can't debug it there. Is there a way of calling my local webservice with the soap packet generated rather than my current test harness where I manually create objects and call the web service through a web reference?
[edit] The machine that I got the soap packet was on a vm so I can't link it to my machine. I suppose I'm looking for a tool that I can paste the soap packet into and it will in turn call my web service
A somewhat manual process would be to use the Poster add-in for Firefox. There is also a java utility called SoapUI that has some discovery based automated templates that you can then modify and run against your service.
By default, .Net will not allow you to connect a packet analyzer like TCPTrace or Fiddler (which I prefer) to localhost or 127.0.0.1 connections (for reasons that I forget now..)
Best way would be to reference your web services via a full IP address or FQDN where possible. That will allow you to trace the calls in the tool of your choice.
Same as palehorse, use soapUI or directly the specific component for that feature: TCPMon.
Just did this the other day with TCPTrace on the local machine. I mapped the remote host in the hosts file to 127.0.0.1. Ran the local web server on 8080, TcpTrace on 80 pointing to 127.0.0.1:8080. Probably your issue is trying to run both at port 80 which won't work.