I'm having some trouble with a WCF Service. When I host it in IIS, it runs fine, but I figure there is a problem somewhere.
When I run my WCF Service in Visual Studio 2010, it brings up the WCF Service Host.
It names the host, then the status is 'Error'.
The error it gave is this:
System.ServiceModel.AddressAlreadyInUseException: HTTP could not register URL http://+:8732/Design_Time_Addresses/EvalServiceLibrary/Service1/. Another application has already registered this URL with HTTP.SYS. ---> System.Net.HttpListenerException: Failed to listen on prefix 'http://+:8732/Design_Time_Addresses/EvalServiceLibrary/Service1/' because it conflicts with an existing registration on the machine.
I don't know if this has affected the service deployed in IIS, since that tells me I have created a service if I browse it through IIS.
Any ideas?
It's pretty clear, the address is already in use.
Does the service in IIS run on the same port? Change it, or change your port for the development.
Related
I have hosted Flask Web application on Windows Server on AWS, I have done followings
hosted it on IIS and add new bindings(port 8090) to web site
Created inbound rule for the port(8090) given in bindings
And it works fine on the server, but when i'm trying to access it on my PC's web browser says
it cannot reach took too long to respond
What else i need to do ?
In your vm, different provider has their security policy. For aws even you have set inbound port rule, it will not work. You also need to set inbound rules in their potal.
👉(1) Open Windows firewall, Create an Inbound Port Rule.
👉(2) Directly in Amazon Web Service console, exactly in security groups/inbound.
I need help.
I am getting SocketException: Cannot assign requested address. It happens when i try to access serviceA by serviceB via Refit. If run one of the services on IIS or in Visual studio debugger everything works fine. But when i run them both in docker containers, system throw that error.
It also happens when use Ocelot. If the gateway service is on IIS or run in debugger (separate from other services) it works, but when I put it in container with the other services i get the error.
What could it be?
WIN 10
VS 2019/VS Code
Docker desktop
WEB API CORE 3
Refit - https://github.com/reactiveui/refit
Ocelot - https://github.com/ThreeMammals/Ocelot
Thank you
Actually the question is kind of duplication of the following one Unable to access a locally hosted wcf service over the internet but with only difference that the service is hosted by a windows service on Azure Virtual Machine.
I can access the service on the machine and I have added an endpoint to the service port at Azure Configuration console, but still cannot access the service over the Internet.
The error message that is not possible to set up connection.
Is my scenario technical possible on azure? if yes - what is done wrong?
The answer to my question was pretty straightforward. Although I opened my endpoint in Azure Management Console the port was blocked by the virtual machine firewall (windows firewall). After setting in- and out- tcp port rule, the problem had gone.
My setup is as following:
Domain A: Visual Studio 20120 on my local workstation, pointing to my controller via an IP address
Workgroup (non-Domain): Visual Studio 20120 test controller in Amazon's EC2 cloud
When trying to connect my Visual Studio to the controller I received the following error "Cannot connect with controller ... The server has rejected the client credentials. The logon attempt failed"
To deal with that issue, I've created, on my workstation, a new local (non-domain) user with the same name and password as the user/password combination on the cloud.
Once I did that, I started an instance of Visual Studio as that user (using "Run as") and tried again. That gave out a different error message:
"the requested name is valid but no data of the requested type was found"
Turns out that what Visual Studio is actually complaining about (in a very obscure way) is that it is able to connect to the controller by the IP address, but it is unable to connect to its via its hostname.
To resolve it, I had to connect to my controller computer and get its hostname. Then I went to my hosts file (C:\Windows\System32\drivers\etc) and added the hostname as well as the ip address.
With that done, Visual Studio successfully connected to the controller.
I had a similar issue. I've notice some weird quirks when having the test controller in the domain, and the agents outside my network in workgroup computers. The controller seems to try to connect back to the agents using their netbios name, so you need to add that hostname to your hostfile with the public IP address if it isn't in your internal DNS. The agent seems to try to connect to the controller using the FQDN (active directory domain, not internet domain) of the controller, so that needs to go in the host file of the agent. You need to have the same account name and password for the agents and controller. If your controller is on a separate computer from your test manager, you need to have the controller service account be a domain account with the same username/password as the local service account on the agents. I have a complete walkthrough of what I did to make it work at http://nerdsknowbest.blogspot.com/2013/10/how-to-setup-visual-studio-tfs-test-agents-cloud.html if it helps you, or anybody else. Also, if you have anything in the hosts file that points to 127.0.0.1, comment it out.
I have a windows service that is making a call out to an IIS hosted WCF on the same server. This worked fine up until our virtual server crashed and had to be rebuilt. Ever since then I have been getting a "tcp error code 10060" error when the windows service tries to call this WCF service.
The IP that it gives does not exist, it is an old IP address. The IP address is not specified anywhere in code or in a config file. I can launch the WCF service from IE from that machine and any other machine that I call it from. I am told that DNS is fine.
Is there something else that I am missing somewhere?
This turned out to be a DNS issue where we had 2 entries in DNS.