Consuming a WCF Service that is hosted in a Windows Service from outside solution

Question

I've set up a WCF Library hosted in a Windows Service using the following walk-through:

http://msdn.microsoft.com/en-us/library/ff649818.aspx

The consumer winforms is in the same solution, which is located locally on my work PC's C: drive.

The walk-through works ie the winforms button gives me the correct answer.

If I create a new Solution on the C-Drive with a single Windows Forms project in it I cannot successfully add a service reference to this running service, i get the following message:

The detailed message says the following:

The URI prefix is not recognized. Metadata contains a reference that cannot be resolved: 'net.tcp://localhost:8526/Service1'. Could not connect to net.tcp://localhost:8526/Service1. The connection attempt lasted for a time span of 00:00:02.0020000. TCP error code 10061: No connection could be made because the target machine actively refused it 127.0.0.1:8526. No connection could be made because the target machine actively refused it 127.0.0.1:8526 If the service is defined in the current solution, try building the solution and adding the service reference again.

Why can I add this Service Reference ok to a project within the same Solution as the Service but not from a project in a different solution?

---

EDIT

My colleague found an error in the MSDN article - I have detailed his find HERE

Answer 1

The step by step walkthrough article at MSDN ends unfortunately where it gets interesting, so let's continue here. Because there are many possibilities which may cause the error, I've described several options (= scencarios which may cause the issue) below, which should help troubleshooting:

1st option: Try to specify

  net.tcp://localhost:8526/Service1/mex

when you add the service reference to your new client - ensure that the service is installed and running before you do that.

Explanation: The suffix "mex" stands for "metadata exchange" and allows Visual Studio to download details of the WCF contract. This suffix is also used in the walk-through example, it was added automatically (you will see it in the Address field if re-open the added service reference by right-clicking on "Configure Service-Reference...").

---

2nd option: What I noticed when I tested the walk-through is that it helps sometimes to right-click on the service reference and select in the contect menu "Update Service-Reference".

After a while in the systray you can see the balloon message "Your service(s) have been hosted." , after which you can start the client within the same solution. In this case, the service has been temporarily created but is not deployed permanently - which means, if you stop debugging, it is removed. As a result, you can't use this service from a remote PC, it is just visible within the solution in Visual Studio. Visual Studio internally invokes the tool

WcfSvcHost.Exe /Service:<Service1Binary> /Configuration:<Service1Config> 

supporting it with the right parameters to register the service properly (you can find this tool in Visual Studio's Common7\\IDE subdirectory, and there is also WcfTestClient.Exe available - a tool which acts as a client, very useful to debug WCF).

For instance, if you have stopped debugging, and launch the client.exe from Windows Explorer outside of Visual Studio, then it does not find the service and you're getting exactly the error message you have described in your question.

There are two interesting links regarding this matter at Microsoft: Problem with Metadata Exchange and Publishing Metadata

Note that this is different from deploying it as described in the 3rd option.

---

3rd option: Have you used InstallUtil to deploy the service? In this case it can happen that you have accidently removed the [...]/bin/Debug subdirectory and the service fails to start, because the .EXE file is missing.

Note: This can be avoided if you're using a ServiceInstaller project, which copies the binaries before the service is registered. Or - if you want to use InstallUtil for simplicity - you can copy the service binaries to a target directory (including the .config files and .dlls) before you register it.

---

4th option: If you run the service on a remote computer , you need to specify the proper host name or IP address of the host instead of localhost , and you need to ensure that the personal firewall (windows firewall or 3rd party) doesn't block the port 8526 (the port number which was used in the example). Specify an exception to allow this port for incoming and outgoing traffic.

---

5th and final option (UPDATE): Naming conflict - Service1 is the service but also the class name in the Wcf library. Either fully qualify the class name you're using from the WCF library in the service, ie WcfServiceLibrary1.Service1 or rename the class. Whytheq has found it himself with a colleague and as posted it here .

---

More reading: Check out this article, which I've found recently: " WCF: a few tips ". It explains very well troubleshooting WCF. The only change I would made to the console hosting example is to replace the using statement by a

ServiceHost host = new ServiceHost(typeof(Service));
try
{
    host.Open();

    Console.WriteLine("WCF Service is ready for requests." +  
    "Press any key to close the service.");
    Console.WriteLine();
    Console.Read();

    Console.WriteLine("Closing service...");
}
finally
{
    if (host!=null) {
            host.Close();
            host=null;
    }
}

If you want to know more about the reason why, check out this article: " Proxy open and close ".

Answer 2

You can get round this as follows:

• Browse the service's WSDL URL and save the WSDL to a local file.
• Then make the following changes to the file:
• Remove the namespace prefix from the name used for the wsdl:binding ie change name="wb:wsclocks-inboundSoapBinding" to be name="wsclocks-inboundSoapBinding"
• Change the binding attribute of the wsdl:port attribute to match, and also remove the namespace prefix from the value of the name attribute, so it is just wsclocks-inbound.

Then run svcutil /o:Client\\WBServices /noConfig