views:

150

answers:

3

I've been having major problems with WCF, which are not amenable to any wisdom I can find. I've tried basicHttpBinding, wsHttpBinding, netTcpBinding (with the Net.Tcp service running on both machines). The behaviour can be boiled down to:

  • works on same machine, when running in debugger, standalone (non-service) process, Windows service
  • cannot be accessed from other machine, unless I'm running the service in the debugger

I must confess to being baffled by the plethora of options for bindings/security/etc. I must also confess to being ignorant of the restrictions on running as a Windows service, although I'm sure I've read somewhere that the SYSTEM account does not have network credentials. I've tried running the service under my own credentials, with the same results.

I'm up against a deadline in a few hours, and at the moment I'm going to have to resort to running as a standalone process, which is pretty embarassing.

I'm sure I've made some simple but crucial mistake in my understanding, and would be happy to be enlightened. But for now I'd be happy if someone knows a quick and dirty way to run WCF between two machines on the same Windows network without any security necessary, where one is a windows service and the other is a Windows GUI app.

+1  A: 

This calls for the NetNamedPipe binding (on-machine communication)!

Your config would have to look something like:

  <system.serviceModel>
    <bindings>
      <netNamedPipeBinding>
        <binding name="NoSecurityIPC">
          <security mode="None" />
        </binding>
      </netNamedPipeBinding>
    </bindings>
    <client>
      <endpoint name="internal"
                address="channel1"
                binding="netNamedPipeBinding"
                bindingConfiguration="NoSecurityIPC"
                contract="IYourService" />
    </client>
    <services>
      <service name="Namespace.YourService">
        <host>
          <baseAddresses>
            <add baseAddress="net.pipe://localhost/" />
          </baseAddresses>
        </host>
        <endpoint
            address="channel1"
            binding="netNamedPipeBinding" 
            bindingConfiguration="NoSecurityIPC"
            contract="IYourService" />
      </service>
    </services>
  </system.serviceModel>

Marc

marc_s
+1  A: 

Is it a Windows Firewall issue? BasicHttpBinding defaults to security mode "none", and setting it on netTcp for client and service is as simple as putting a security mode="none" element under the root binding element in both the client and server config. Seems like the firewall on the server would be the only thing that'd keep you from connecting if the security mode is set to none.

nitzmahone
+1  A: 

1) as well as opening the firewall, you almost certainly need to explicitly permit binding the serving port via the APIs on HTTP.SYS. This can be done by the built in netsh http add command on Vista or later, via the downloadable httpcfg tool on earlier systems, or by directly P/Invoking against the HTTP APIs with administrative privilege as a set-up step.

2) if you have multiple services, getting them to share the address space on a given port is far easier if they talk HTTP than net.tcp

3) as a default, a service that talks across the network should be run with Network Service identity, ideally as a service-specific SID : even if the data are not sensitive, exposing a high privilege user like System on the network is not good practice.

Steve Gilham