Net.Tcp WCF requires clientaccesspolicy.xml be available from IP, not hostname

Testing a new Net.Tcp WCF service, I got the following error:

"Could not connect to net.tcp://X:4502/XService. The connection attempt lasted for a time span of 00:00:00.4270427. TCP error code 10013: An attempt was made to access a socket in a way forbidden by its access permissions.. This could be due to attempting to access a service in a cross-domain way while the service is not configured for cross-domain access. You may need to contact the owner of the service to expose a sockets cross-domain policy over HTTP and host the service in the allowed sockets port range 4502-4534."

Although this is a very common error, in our case, it was not fixed by the obvious solutions:

1. clientaccesspolicy.xml was already available. I verified that through the browser.
2. clientaccesspolicy.xml already had the correct contents allowing port 4502.

It turned out that while clientaccesspolicy.xml was available via our server hostname, it was NOT available via the server IP address.

Even if the Silverlight client is configured to access a net.tcp WCF service using a valid DNS name, it still uses the IP address of that DNS name to load the clientaccesspolicy.

This happens EVEN IF it has already loaded the very same clientaccesspolicy.xml through the DNS name.

In our case at least, IIS7 by default does not allows access by IP for a site that has already been configured for for a DNS name.

So I added a new site in IIS Manager, bound to the IP address, pointing to the same folder already containing our clientaccesspolicy.xml file.

But, this new site must be bound to the internal IP (e.g. 192.168.1.xxx), NOT the external IP (e.g. 88.77.66.55).


After I discovered the problem I found this:

http://blogs.msdn.com/b/silverlightws/archive/2010/04/09/policy-file-for-nettcp.aspx

Net.Tcp WCF service requires 'Integrated' managed pipeline mode, not 'classic' mode

We built and successfully tested a Net.Tcp WCF service. But when deploying it to an off-site server for further testing, we discovered the IIS worker process was crashing.

In the event log, we got plenty of these:


Source: ASP.NET 4.0.30319.0
EventID: 1088
Description: 0x8000ffff Catastrophic failure


and some of these:


Faulting application name: w3wp.exe, version: 7.5.7600.16385, time stamp: 0x4a5bcd2b
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x00000000
Faulting process id: 0xfe8
Faulting application start time: 0x01cb429f60c2c986
Faulting application path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
Faulting module path: unknown
Report Id: f85bf6d3-ae92-11df-a403-00219b00a9ca


We had to issue an 'iisreset' command from command line to bring it back.

It turns out, the offsite servers were running our application using a 'Classic' mode app-pool. But during development, we used 'Integrated' managed pipeline mode.

Changing the offsite servers to 'Integtated' seemed to fix the problem.

ExecuteReader: Connection property not initialized

This is an inaccurate error message!!

Despite what the error message says, the following error can be caused by not setting the 'CommandText' property of the SqlCommand object:

System.InvalidOperationException: ExecuteReader: Connection property has not been initialized.

I noticed this while working with transactions.

In my case it was NOT caused by the 'Connection' property