When I run my WCF in normal mode it works, but when I run through the Azure Computer Emulator on my local PC, the port numbers are different. For instance, the WCF page opens up in under the address: http://localhost:81/ServiceName1.svc, but the WSDL address says
You can also access the service description as a single file:
http://pc-name1:82/ServiceName1.svc?singleWsdl
When I try to connect using WCF test client, it is not working when I try to fetch the address http://localhost:81/ServiceName1.svc or the address http://pc-name1:82/ServiceName1.svc
Do you know what might be happening? Has anyone noticed this when using the Azure emulator?
Have you gone through the Hosting WCF within Windows Azure exercise? This behaviour is explained. You need an update to the WCF - KB981002- WCF: Hotfix rollup update, which will add a special behavior for your WCF services:
7.About the System.ServiceModel configuration above:
For this example we are exposing a metadata exchange (MEX) endpoint in addition to the service main endpoint. This will expose
the service metadata and thus allow service references to be added to
this service in Visual Studio.
The useRequestHeadersForMetadataAddress behavior is a special behavior that is defined in KB981002- WCF: Hotfix rollup update. It
allows WCF to serve correct metadata behind load balancers. Windows
Azure web roles are load balanced between one or more physical
servers.
Related
This has to be a pretty simple task. I have an Azure Cloud Service that works just fine with HTTP and HTTPS. Now I want to create a net.tcp connection to the cloud service. The first thing I discover is that net.tcp is not supported by IIS Express. That's fine. So I try switching to regular IIS and all I get when I try to run the application is a 404 error. If I was building an WCF Web Application, I would get a form that allows me to select (and build) the virtual directory for the application, but there's no analog for this in the Cloud Service.
I can take a fresh 'Cloud Service' project build using visual studio, make no changes to it except change IIS Express to IIS. When I launch it, I get a 404 error in the web browser.
Does anyone have a working example of tcp.net (with IIS Express or standard IIS) in a Cloud Service?
This video by the Azure team is a great overview and cleared up a lot of conceptual issues I had. An Azure Cloud Service is a container around one or more virtual machines. The virtual machines basically come in two flavors: Web Role and Worker Role. What threw me is the description that the Worker Role was intended for background processes: not true. A Web Role is basically a VM with IIS, a Worker Role is basically a VM without IIS. Since the off-the-shelf IIS doesn't have net.tcp installed, you have to jump through hoops in order to get the protocol installed. Instead, the Worker Role can be used as a self-hosted web service. If you want the performance and throughput of TCP, this appears to be the direction to go.
Summary:
Does anybody know if there are known issues or configuration gotchas with an IIS service connecting to an Azure based service?
Scenario:
I currently have a scenario that requires me to host two web-services, one in Azure, and one on a server running IIS. The IIS hosted service (a WCF service) connects to the Azure hosted service (actually the Azure storage API) in order to fetch certain information. This information is manipulated and returned to the client.
Client -> IIS Service -> Azure Storage Service
Issue:
I'm running into issues with the IIS service connecting to the Azure Service. The hostname cannot be resolved. I'm using the Azure Storage client from my code, but have actually tried this using the azure API calls, and they also do not work from IIS. I captured the requests using Fiddler (on a different machine), they match the azure REST API calls, as expected. These requests, when made outside of IIS on the host machine execute properly. It is only when they are issued by the IIS service that they fail.
In my research other people have been running into this issue when there's a firewall problem, but since I can hit the service properly from the machine, that doesn't seem to fit the bill. My hunch is that there's a configuration issue I need to sort out in IIS, but I've failed to find anything useful with my searches.
Does anyone have any information on why this might be occuring (known bugs, gotchas etc)? Any workarounds? From a SOA perspective, this seems fairly critical to understand.
Any assitance anyone has would be helpful. Thank you.
Sounds like a proxy configuration issue. Check how your IIS server connected to Internet. If you are using some sort of proxy to get to Internet, that connection has to be configured correctly.
Specifically, if your proxy servers are Microsoft ISA server, or Microsoft Forefront TMG, then you need to check two things:
ISA server client or Forefront TMG client software is installed on the server
The account used by IIS application pool is domain user. ISA Server/TMG are designed to work only with user account, not service account. Alternative workaround for this limitation is using "defaultProxy" configuration in web.config, however it only wokrs for HTTP/HTTPS.
If you use different proxy server, then other issues might be involved, for example proxy might require authentication.
I have an app with a self-hosted WCF service.
My WCF service gets published under the URI "net.tcp://localhost:8004/DocumentService". When I run the service on a remote machine and try to discover the service with the new .NET 4 class DiscoveryClient, the found services all have the URI "net.tcp://localhost:8004/DocumentService" too without any information about the actual machine where the service is hosted.
Obviously this is useless if I want to access the service on the remote machine. But I can't find any reference to the actual remote machine (IP address or server name) in the arguments passed to FindProgressChanged.
Is there a way to get the information about the remote machine or do I have to publish my service with the machine name of the remote machine? Or is DiscoveryClient just broken?
I hope this make sense.
I spent a lot of time investigating this problem. Building base addresses in the code was not acceptable for me, as it implies hardcoding transport scheme and port (the latter, of course, can be stored in a separate config section, but then why not just to use the existing section?). I wanted to have an ability to just configure the base address in config as usual. And it turns out that a base address like <add baseAddress="net.tcp://*:8731/"/> will perfectly work. I think the same is true for programmatic configuration.
I've got a WCF service on a server on one side of a firewall. I need to access the service from many workstations on the other side of the firewall. The network guys insist that all holes through the firewall are one-to-one so at the mo, I'll have to set up every workstation one by one. There could be loads and it'll get tedious and be prone to errors.
Is it possible to set up a WCF server on this side of the firewall that can in some clever way just act as a proxy to the 'real' WCF service on the other side of the firewall? If so, could you point me to some reference material?
There is a new concept of a WCF Relay service being developed for the Windows Azure "cloud" computing space. That would allow you to create your scenario fairly easily - just host some bits of your service out in the cloud.
See these links for more information:
WCF services hosted on Windows Azure
Software in the cloud: the Relay service
.NET ServiceBus: Hands-On with Relays
or search Google for "WCF Relay Service". There are also a number of new bindings specifically for these WCF scenarios.
Hope this helps.
Marc
UPDATE:
WCF v4 - to be released with .NET 4.0 later this year (2009) will include a RoutingService class which can be used in scenarios like this.
See more info about the WCF4 routing service here:
Content based routing in WCF 4
Routing messages in WCF 4.0
A developer's introduction to WCF .NET 4 Beta 1
I have a few suggestions, maybe one would work in your case:
Place the WCF service outside the firewall. If the WCF service needs to talk to the database, open the database port for the IP address of the machine running the WCF service.
Program or use code generation to create a WCF service that is simply a pass through layer
There may be some functionality in your firewall that allows you to publish an end point
I am inexperienced in WCF so this question may be real basic...
I have a WCF service hosted in IIS of a server named "Server1". This server is aliased and visible from the open Internet as ServerAlias.mydomain.com.
While developing the consumer application, I add a service reference to the service in Server1 and deploy it. When executing it remotely, the app looks for the service on "Server1.mydomain.com" but it can only be accessed through "ServerAlias.mydomain.com".
Is there a way that I can reference the service in Server1 in design-time, and in run-time the application looks in "ServerAlias"?
Thanks!
When you make the reference, it should create entries in your .config file which indicate the remote endpoint. All you have to do is change the remote endpoint to point to the other server and it should work.