0
votes

I have an application that is moving over from WCF Http to named pipes since everything is on the same machine. Those in charge have decided not to reference the DLLs directly, so that's not an alternative. I'm okay moving over to a tcp connection instead, though I don't know that it gives us any direct performance benefits over http on the same machine. The production host is going to be a IIS 7 server, not a WAS or other service. My machine has IIS 5.1, Cassini, and IIS Express.

I've tried the following:

  • Virtual Box running windows 7 on my XP machine. The installer craps out.
  • Named Pipes on Cassini, not supported.
  • Named Pipes on IIS Express, not supported.
  • Googling the hell out of the solution, nothing useful found.

What is the best/recommended way to develop WCF NetNamedPipes on XP that does not have IIS 7?

1
Why named pipes shouldn't be supported on IIS? They're unrelated, n.p. are a feature offered by the operating system. - Adriano Repetti
Running under IIS I suspect your issue with named pipes may be security privileges for the user IIS is running on. - kenny
IIS 7 supports it, but the IIS 5.1 on XP doesn't, nor does IIS Express for Cassini (to the best of my knowledge). I'm looking for how to host the named pipes on my local machine that DOES NOT have IIS 7. - Thinking Sites
As pointed by @kenny it may be a security issue, named pipes are not provided by IIS but by the operating system itself!!! - Adriano Repetti
It's a WCF NetNamedPipe, which I think are somehow different than regular named pipes. The error I get is "The protocol 'net.pipe' is not supported." when trying to access it on my IIS Express instance. If it were a security issue, I'd be receiving a different error. - Thinking Sites

1 Answers

2
votes

On XP, the WCF binding to named pipes works well for a service which is custom-hosted in a Windows Service process. But if you don't want to build a custom host you are out of luck: the only protocol supported for hosting in IIS5/6 is HTTP.

WCF service hosting in IIS for protocols other than HTTP depends on WAS, which requires IIS7. This constraint applies equally to the TCP binding, so that is not a workaround as you suggest.

It sounds as if your application is intended to be IIS-hosted in production. If this is a given, I think you have no alternative but to change to a new development platform which supports the target environment.