I am using Visual Studio 2008. I created a WCF application and when I ran the service for the first time from VS IDE (not hosted on IIS), the service opened in the web browser with the address localhost:1927/. Every time I run this service from VS IDE, it runs in the same port, i.e 1927
I wanted to change the port number (for some reason), so I gave specific address localhost:1928 in the web.config file. When I run the web service in IDE after this change, I keep getting the following error.
No protocol binding matches the given address 'localhost:1928/'. Protocol bindings are configured at the Site level in IIS or WAS configuration.
Following is the <service> section from the web.config file.
<service name="EMS.ServiceImplementation.EmployeeService"
behaviorConfiguration="EM.EmployeeServiceBehavior" >
<endpoint name="httpEndPoint"
address="http://localhost:1928/"
binding="basicHttpBinding" bindingConfiguration=""
contract="EMS.ServiceContracts.IEmployeeService" />
<endpoint name="MEXEndPoint"
address="mex"
binding="mexHttpBinding" bindingConfiguration=""
contract="IMetadataExchange" />
</service>
My specific questions are:
How does VS IDE run the service always on the same port which it picked in the first run? Where is this information stored? (I looked through all files in the solution but I couldn't find port 1927 mentioned anywhere).
How can I make the service run on a different port?
(Please note that, I have seen similar threads in Stackoverflow, but they relate to service hosted in IIS)`
Just leave the address attribute empty and it is solved.
You can control this in the Solution Explorer under the Project Properties. There's a tab called Web where you can tell Visual Studio whether to use the default auto-assigned port, or a specific fixed port of your choosing:
Any non-standard settings will be stored into your YourProject.csproj file.
Related
I read all over the msdn where it says to enable port sharing : The port sharing service should be started and my net.tcp binding should specify 'portSharingEnabled = True'.
I also see that net.tcp binding documentation shows the default value for portsharing as false.
But in my VS 2013, WIN 7 machine, I have a console app hositing many services and I am able to run it from VS without any issues. My servichost is able to host more than 10 services with the same port. What am I missing to understand ? Any ideas ?
I use this endpoint followed by servicename for all my services:
<service name="Lookup" behaviorConfiguration="">
<host>
<baseAddresses>
<add baseAddress="net.tcp://localhost:8000/"/>
</baseAddresses>
</host>
<endpoint
name="IEntitiesLookup"
binding="netTcpBinding"
address="LookupService"
contract="ILookup" />
</service>
I managed to clear my understanding on port sharing to an extent. But would be happy for more thoughts on this.
I managed to find the reason behind the above scenario. Within a process, I am able to host several endpoints which shares the same port. This does not need port sharing to be enabled. But if I have another process which tries to host some services with same port numbers, then an exception for 'ports already in use' happens. In this case, we then need to enable port sharing in the binding of all the endpoints in both the service host processes and start the PortSharing service.
I believe this boils down to the understanding that in the transport layer, the port numbers are tied to the process.
I have a domain/website(HTTR.abc.com) hosted in inetmgr in IIS in production servers.
I want to host a WCF service under the domain HTTR.abc.com
The web.config of my WCF service is as follows
<services>
<service behaviorConfiguration="HTTR.Business.HTTRContextServiceBehavior" name="HTTR.Business.HTTRContextService">
<endpoint address="http://machinename:83/GTYEBus/abcService.svc" binding="wsHttpBinding" contract="HTTR.Business.IHTTRContextService">
</endpoint>
</service>
</services>
When i run the URL
"http://HTTR.abc.com/GTYEBus/abcService.svc" the page shows properly but it is showing
WSDL file pointing to "http://machinename:83/GTYEBus/abcService.svc?WSDL"
I would want the page to show the WSDL with the same path as the .svc path, that is it should show as "http://HTTR.abc.com/GTYEBus/abcService.svc?WSDL" instead of
"http://machinename:83/GTYEBus/abcService.svc?WSDL"
I came across this one while tring to find a resolution to the same issue.
This ended up being a issue with the site not having a host name.
In IIS7.5, simply add in the host name into the host header on the binding. If it is https, the host header may be protected. You'll need to make the certificate become a pseudo wildcard cert by putting a * as the start of the certificates friendly name. Then the host name will be editable.
This link has a good description of the resolution in IIS6
In the serviceMetadata section of the web.config you can include the attribute externalMetadataLocation and refer it to the "http://httr.abc.com/GTYEBus/abcService.svc?wsdl" location. Example:
<serviceMetadata externalMetadataLocation="http://httr.abc.com/GTYEBus/abcService.svc?wsdl" />
Here is the MSDN reference on the serviceMetaData config section: http://msdn.microsoft.com/en-us/library/ms731317.aspx.
This does not require any additional IIS configuration and is much more scalable.
Hope this helps.
I hope this is a quick question. I have a WCF service running on IIS port 4040. I have added the following headers to this service
4040 (non load balanced domain)
4040 localhost
So locally I can reference this service as http://localhost:4040/service.svc and also by the fully qualified domain name. This is no problem for all the services on this machine, I can reference everything by localhost:4040
The issue comes when I try to access it from another server (as we have other apps that need to consume the service)
I get a 404 error, and was wondering whether the service is defaulting to being exposed on localhost loopback (127.0.0.1) therefore cannot be accessed.
The endpoint is defined as such:
<service behaviorConfiguration="ClaimChaseBehavior"
name="Modules.EClaims.ClaimChase">
<endpoint address=""
binding="basicHttpBinding"
contract="Domain.EClaims.DataInterfaces.IClaimChase" />
<endpoint address="mex" binding="mexHttpBinding"
contract="IMetadataExchange" />
</service>
Notice I don't define an address. The reason for this is to allow us to have a common config file (we are trying to get around defining machine domains/addresses and thus multiple configs)
Is there a way to make the WCF default to the machine IP instead of the loopback connector without defining the actual domain name
Hope this makes sense
Regards
Richard
When you're hosting your service in IIS, the address of the service is defined and controlled by the location of your *.svc file - you cannot override that by defining base addresses or explicit address on your service endpoints.
The service address will always be:
http://machinename/VirtualDirectory/YourService.svc
Marc
Check your web config. Have you spesified that the address of the service is localhost?
EDIT:
On second thoughts, it looks like a firewall problem, is port 4040 blocked by a local firewall?
We have a WCF service deployed on a Windows 2003 server that is exhibiting some problems. The configuration is using wsHttpBinding and we are specifying the IP address. The services is being hosted by a Windows Service.
When we start the service up, most of the time it grabs the wrong IP address. A few times it bound to the correct address only to drop that binding and go to the other address (there are 2) bound to the NIC after processing for a short while.
It is currently using port 80 (we've configured IIS to bind to only 1 address via httpcfg) although we have tried it using different ports with the same results.
When the Windows Service starts hosting the WCF service, the properties show that it is being bound to the correct address; however, tcpview shows that it is indeed listening on the incorrect address.
Here is the portion of the config that sets up tehe baseAddress. The one that gets bound to ends up being .4 instead of .9
<services>
<service name="Service.MyService"
behaviorConfiguration="serviceBehavior">
<host>
<baseAddresses>
<add baseAddress="http://xx.xx.xx.9:80/" />
</baseAddresses>
</host>
<endpoint address="MyService"
binding="wsHttpBinding"
bindingConfiguration="WSHttpBinding_IMyService"
contract="Service.IMyService" />
<endpoint address="mex"
binding="mexHttpBinding"
contract="IMetadataExchange" />
</service>
</services>
Is there some other configuration that needs to be set?
Is there a tool that can help track down where this is getting bound to the wrong address?
Your WCF configuration looks OK to me. This might be an issue with the binding order of your NIC cards. Make sure that the NIC with correct address is first. Here is an article that discuss how to set and view nic binding orders:
http://theregime.wordpress.com/2008/03/04/how-to-setview-the-nic-bind-order-in-windows/
The issue seems to be ISS related. Here is the description about the error your getting from http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/ddf72ae0-aa1e-48c9-88d1-10bae1e87e4f.mspx?mfr=true
This error is logged to the event log when HTTP.sys parses the IP inclusion list and finds that all of the entries in the list are invalid. If this happens, as the description in Table 11.15 notes, HTTP.sys listens to all IP addresses.
You can also check the following thread which talks about a similiar issue
http://www.webhostingtalk.com/showthread.php?t=534174
Hope this helps.
We had the same issue and this feature helped us to solve our problem :
http://msdn.microsoft.com/en-us/library/system.servicemodel.hostnamecomparisonmode.aspx
Hope this help.
More information: I removed the xx.xx.xx.4 IP address from the NIC altogether and turned off IIS. Now when I try to start the service it fails and I find this in the System event log.
Description:
Unable to bind to the underlying transport for xx.xx.xx.4:80. The IP Listen-Only list may contain a reference to an interface which may not exist on this machine. The data field contains the error number.
My configuration file still has the xx.xx.xx.9 baseAddress setting.
One more piece of informatoin. If we change the binding to use NetTcp instead of WsHttp it binds to the correct address on port 80. Changing it back to WsHttp it goes back to the incorrect IP address.
BaseAddress is ignored. You need to set a host header under IIS.
From what I've seen the tag is ignored when hosting a WCF service in IIS. I understand that when self-hosting this is required but is this harmful or even used when operating under IIS?
ex.
<system.serviceModel>
<service blah blah blah>
<host>
<baseAddresses>
<add baseAddress="http://localhost/blah" />
</baseAddresses>
</host>
</service>
</system.serviceModel>
From what I've seen you can take a config file describing a service from one machine and use that on a completely different machine and it works fine. It looks as if IIS completely ignores this section.
Thanks,
kyle
As you have guessed, the baseAddresses element is completely ignored when hosting in IIS. The service's base address is determined by the web site & virtual directory into which your wcf service is placed.
Even when self-hosting, baseAddresses is not required. It is merely a convenience that avoids you having to enter a full address for each endpoint. If it is present, the endpoints can have relative addresses (relative to the base address, that is).
base address required for selfhosting. IIS/WAS hosts ignores the base address.
According to the MSDN Microsoft documentation in the below link, midway through the page in the Note section states, "Services hosted under Internet Information Services (IIS) or Windows Process Activation Service (WAS) use the virtual directory as their base address."
http://msdn.microsoft.com/en-us/library/ee358768(v=vs.110).aspx