I have a WCF service hosted on IIS. I have a smartclient application which calls this WCF service through endpoints defined in app.config file.
Now when i publish this application using this configuration, IT throws an exception saying that no endpoint is listening at localhost.
How can i make it dynamic. By dynamic I mean IF i update the endpoint in app.config file the application should pick up that url instead of the url with which the application was published with.
I remember i could do it in webservices. Please help.
Your app.config would most likely contain something like:
<client>
<endpoint name="...."
address="........"
Check the address - that's the URL you're trying to connect to. You need to provide the server's address and port and path - no localhost, of course.
<client>
<endpoint name="...."
address="http://yourserver/yourVirtualDir/YourService.svc"
That should do the trick.
Marc
Related
I have a web service in the Production network. The scenario is that I have set the base address of my WCF Service - http://public-ip:2000/Service.svc
The Public IP is internally mapped to server with private network address.
Assume, the service internally is hosted on a server with hostname say internalserver in domain mydomain.com
Now when I browse the service on the internet, the url path of WSDL file is
svcutil.exe http://internalserver.mydomain.com:2000/Service.svc?wsdl
This link will never be resolved from the internet as it is internal/private. When I replace the above url with one below
http://public-ip:2000/Service.svc?wsdl
the WSDL file is returned correctly.
Another setting is
<identity>
<dns value="localhost"/>
</identity>
So I don't really understand when I am not refering the internalserver.mydomain.com in base address / endpoint address, how is it still appearing in the URL when I try to browse the service?
How to resolve this issue? Am I missing some configuration when I am publishing the WCF project?
Kindly suggest something on the issue.
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.
My WCF service exposes an https AND an http endpoint. Apart from the SSL they are identical. They map to the same code.
The ultimate intention is for external users to connect via https, internal users to use http.
In development this gives me a problem. Cassini, the development web server packaged in VS, hates SSL.
I'm wondering if I can configure the service from code, so when running under Cassini, I would not configure https.
Hence the question - How do I configure the service from code if it is IIS hosted? I'd be very happy with alternative answers on how I can persuade Cassini to NOT complain about the https part of the configuration.
"IIS will take care of spinning up the necessary ServiceHost based on your *.svc file - not a whole lot you can do about that, really."
Not too close to the truth. Exactly in the SVC file of your service there is attribute named Factory. Where you can specify the the class and the assebly where the class is located. This class may be your own descendant of Web|DataServiceHostFactory
So your svc markup would look like this
<%# ServiceHost
Language="C#"
Debug="true"
Service="name.space.myService"
CodeBehind="name.space.myService.svc.sc"
Factory = "name.space.WebServiceHostFactoryEx, assembly.name"
%>
The WebServiceHostFactory will be created for every service hit and will recreate your host the way you want it.
You will also need to inherith WebServiceHost and create it the way you need it with certain endpoins, behaviors, addresses, etc settings - whatever you like.
There is very nice post from Michele Bustamante here
EDIT: I figured out the above link is not working anymore, so here it is another one.
I am using this in IIS hosted enviroment for couple of services that are initialized same way.
When you're hosting in IIS, you're leaving a lot of care taking into the realm of IIS - you cannot really grab a hold of your service in this case.
IIS will take care of spinning up the necessary ServiceHost based on your *.svc file - not a whole lot you can do about that, really.
My solution would be different - externalize the <service> tag in your configuration file (web.config):
<system.serviceModel>
<services>
<service configSource="service.dev.config" />
</services>
</system.serviceModel>
In your dev environment, only expose the http endpoint - so your service.dev.config would look something like this:
<service name=".....">
<endpoint name="default"
address="....."
binding="basicHttpBinding" bindingConfiguration="insecure"
contract="......" />
</service>
Create a second service.prod.config which then contains both endpoints - http and https:
<service name=".....">
<endpoint name="default"
address="....."
binding="basicHttpBinding" bindingConfiguration="insecure"
contract="......" />
<endpoint name="secure"
address="....."
binding="basicHttpBinding" bindingConfiguration="secure"
contract="......" />
</service>
and reference that in your web.config on the deployment server.
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?
I'm connecting a WCF client to a group of services all implementing the same contract and all at the same host. I was hoping that there would be a way to combine the endpoint definitions to cut down on configuration clutter. I also would rather not do it programmaticly - just by configuration. Right now, my config has this repeated many times:
<endpoint address="http://hostname/ServiceA.svc"
binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_MyBinding"
contract="ServiceReference.ISearchService" name="ServiceA">
</endpoint>
<endpoint address="http://hostname/ServiceB.svc"
binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_MyBinding"
contract="ServiceReference.ISearchService" name="ServiceB">
</endpoint>
// continued for ServiceC, ServiceD, etc
For server configurations, there is some notion of "baseAddressPrefixFilters" that can be used for this purpose - is there anything for client configuration?
There is the concept of a base address in WCF - unfortunately, that only works if you self-host, e.g. host your service in a console app or NT service. However, that only works on the server side - there's nothing similar on the client side. On the client side, you always have to define the complete, full service address your endpoint should connect to.
If you host in IIS, your service address is determined by the server name, the virtual directory (and possibly subdirectories under that) and the name of the *.svc file used to host the service in IIS. This is a fixed system convention and you cannot influence it, unfortunately (.NET 4 will bring some remedy to that).