WCF - IIS 6 vs. IIS 7 - wcf

I have created a WCF service on my local machine. My local machine uses Windows 7 RC1, thus the web server is IIS 7. However, my production machine is a Windows Server 2003 using IIS 6.
When I attempt to reference the service in my local environment, everything works fine. However, when I promote my service to my production machine, and try to reference the service, I receive an error. The error says:
Error: Cannot obtain Metadata from
http://www.thedomain.com/theService.svc?wsdl
If this is a Windows (R) Communication
Foundation service to which you have
access, please check that you have
enabled metadata publishing at the
specified address. For help enabling
metadata publishing, please refer to
the MSDN documentation at
http://go.microsoft.com/fwlink/?LinkId=65455.
WS-Metadata Exchange Error URI:
http://www.thedomain.com/theService.svc?wsdl
Metadata contains a reference that
cannot be resolved:
'http://www.thedomain.com/theService.svc?wsdl'.
Content Type application/soap+xml;
charset=utf-8 was not supported by
service
http://www.mydomain.com/myService.svc?wsdl.
The client and service bindings may be
mismatched.
The remote server returned an error:
(415) Cannot process the message
because the content type
'application/soap+xml; charset=utf-8'
was not the expected type 'text/xml;
charset=utf-8'..
Is there something I need to do in IIS 6 to get a WCF service to work? I'm really confused as to why it works fine locally, but not fine in production.
Thank you!

There are 4 possibilities I can think of:
Some security setting that is blocking access the the service. Check you IIS log for access denied
That the configuration of the services web.config has not been transfered to production
That metadata exchange is not configured with http get allowed
That you are using a newer binding that is not supported on IIS 6
The bindings that are supported by IIS 6 are basicHttpBinding and wsHttpBinding. See:
http://msdn.microsoft.com/en-us/library/cc949086.aspx
Hope this helps

You have locked onto the obvious difference between the two environments - one is running IIS 6 and the other is running IIS 7. That may be a difference, but not the difference that is causing the problem.
Have you compared the web.config files in the two environments?
Judging from the error messages, it looks like WCF is running on the production machine, but that there's a problem with getting the metadata. Have you tried running the service in production? It's possible that running it will work, even if metadata retrieval does not work.
Also, if you don't mind me getting a little philosophical here, you've just found the reason for staging servers. The fact is that there's a much greater difference between "1" and "2" than there is between "2" and "3". Moving from the development environment directly to production, you're encountering issues with "multiple environments" for the first time. This is similar to the difference between singular and plural.
You're also encountering issues with "different environments" for the first time. this is similar to the difference between "same one" and "different ones".
Adding a staging system in the middle gives you the chance to get all these issues out of the way ahead of time, so that when you move from staging to production, you may still have the issue of "difference", but you will not have the issues of "singular vs. plural" again - you will already have resolved them.

Related

Event ID 36887, A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 40

This is resulting from an outbound connection to Equifax's new TLS 1.2-enabled URL.
Background:
Servers: Windows 2012 R2, .NET 4.6.2, all TLS 1.x Enabled in Test, Stage and Production tiers per this. IIS configurations match between servers (app pools/code except tier-specific configurations/IIS settings.)
Servers are load balanced via Citrix Netscaler, but this site uses Port 80/HTTP, no HTTPS configuration.
Both tiers use the same Equifax URL, but with tier-specific credentials.
The Situation:
Prod will not communicate with their site, we get the opening error.
Our stage environment has no problem communicating.
What we have done:
- Validated TLS reg settings match
- Swapped the prod web.config to the Stage server and the communication worked, so it seems unlikely that it is a web.config issue in production.
- Validated .NET versions
- Checked LSA fips reg setting (set to 0)
- checked for wonky updates known to cause issues
We are going to setup a network trace, but for the moment we are at a bit of a loss. I would appreciate any insights as to what I might be missing.
Developers had to do the following:
Added the specification of using 4.6 per Microsoft recommendations.
Updated some other .NET references in the web.config to point specifically to 4.6.2
They made some changes in some older code pieces to make them 4.6.2-compliant.

Can connect to WCF from certain windows users and not from others

We currently use a solution with WCF web services with Windows Identity Foundation for security.
It works fine for three years now, but it seems we have certain users (I mean windows users) which cannot connect to WCF.
From the same machine with four different Users, Two can connect to the application and two cannot.
Everybody see the server part (the first call was a wsHttpBinding call to check if server exist, if failed a message is provided else we display the login window) but it failed with services with Authentication(ws2007FederationHttpBinding). It seems to be a problem from Windows User...
Has anybody already encounter this type of problem? Any idea to solve it?
We do not have physically access to the machine (client machine) and cannot make some debug to see where it comes from.
the returned exception is:
Could not start session - Exception: SOAP security negotiation with "My service complete address"
for target "My service complete address" failed.

Unable to host WCF REST Service 40(CS) on IIS 7

I have created WCF REST service in vs2010(4.0) with WCF REST Service Template 40(CS). It works fine on localhost and local IIS (7.5), without giving me any errors. But while I am trying to deploy it on server, it gives me 500 Internal server error. I have deployed same way I did on locl IIS. It is not giving me more details about the error. When I checked the server log, it says service.svc - file does not exist. While I have not created .svc file, I did directly with given template.
Can any one please help me to find the solution to this...
Thanks in advance...
I am using template, so there is no .svc file. In this we can directly access the uri without .svc with the filename.
Chrome is just displaying me 500 Internal server error. It is not displaying any related information about error.
-
Satyen Pandya
finally I found the thing that causes error in my service. I have used MySQL database and for that reference to MySql.Data.dll file of older version, and when I upgraded that dll with newer version, my entire project was not responding. It was replaced my newer version and when I tested with older version, service is running fine.
And for hosting it on WCF, Normal procedure of hosting the site on IIS worked for me after solving above problem... And I better opt for going with .net 3.5 WCF Rest Service with .svc extension available.
Thanks all for reviewing my problem..
Take a look at similar post...
# hosting .net 4.0 REST WCF service in IIS 6

WebScriptServiceHostFactory wcf service in IIS 6

I am implementing wcf service using the config-less available with WebScriptServiceHostFactory in dotNet 4. On my local development server the web service returns appropriate content in the response body. I tested the same on my local machine IIS 7 and it works great.
But, now I have moved the service on IIS 6 with SSL enabled. The service when invoked calls the web-method as usual, with no server exceptions. The response body is missing its contents.
The web-service is of the following format:
https:///qa/AjaxService.svc/MyMethod
I have verified the following:
1. Wild-card mapping set to aspnet_isapi.dll [Check file exists - unchecked]
2. Anonymous Authentication enabled
I would appreciated some input, if some has already experienced such a weird behavior.
Thanks
Well I resolved my issue by using WebServiceHostFactory instead. I still don't know what caused issues with WebScriptServiceHostFactory on IIS 6 and .NET 4.0.
I am still looking for any input/resolution with "WebScriptServiceHostFactory on IIS 6 and .NET 4.0"

How does System.Net.Sockets perform its DNS lookups in the context of finding a WCF service?

I have a Web application and a WCF service hosted on the same Windows 2003 development server. They each have their own IIS website node responding to drs.displayscreen.web and drs.displayscreen.service host headers respectively. The hosts file contains entries for both headers pointing back to 127.0.0.1. The web site has a service reference to drs.displayscreen.service.
Both applications work perfectly when their application pool uses the 'Network Service' account.
I need to perform some COM processing under the hood on the service so I want to run the applications under a customised identity. Both sites run on a new application pool.
When I change the application pool identity to use a new windows account created for the purpose, I get the following (inner) exception:
[EndpointNotFoundException: Could not connect to http://drs.displayscreen.service/Handler.svc. TCP error code 10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 192.168.98.2:8080. ]
192.168.98.2:8080 is the address of a DNS server that is no longer in use. It is not referenced anywhere in the solution. It is not referenced by ipconfig at all.
I have made sure that the new account is a member of IIS_WPG and I have run aspnet_regiis -ga . I have also given the account explicit permission to read the hosts file.
Why does the application attempt to use the defunct DNS server to resolve the temporary url (drs.displayscreen.service) instead of the hosts file entry? It has to be a permission of some sort because it does not have this problem when running under the network service account. Help!!
Well, it appears that the answer might involve a bug in the .Net framework. I found a blog posting that clued me in to the fact that the MS .Net implementation of SocketCache.GetSocket might cache invalid sockets and another one that suggests a workaround/hack in the form of an explicit don't-use-proxies configuration setting.
We don't actually use a proxy server in the environment where this problem cropped up but it appears that SocketCache.GetSocket is overridden or behaves differently when the don't-use-proxies setting is in place. Strangely, removing the setting causes the problem to come back so obviously the SocketCache is not repaired when a valid ip/hostname is discovered and successfully used. According to the author of the first post mentioned above, the bug does not exist in Mono. :)