As Microsoft released a Visual Studio 2008, I can hardly see any reasons why someone who is up to developing a distributed network application might choose anything different. New Studio even has a project template for WCF services, what makes network servers and clients development as easy as can be… But, of course, that would only work if no other platform except Windows is considered. Which is not uncommon.

So, what options are there if we need to build a client for existing WCF service that would work where .NET framework is not installed (because it is not available for that platform)? There is one way offered by Microsoft (using sproxy.exe) and some could use it. Other way involves writing “moniker” in .NET and then use it via COM. They both would work on windows platform only, moreover, I couldn’t make sproxy.exe to work with WCF service at all, so I had to look for the third option, which was gSOAP. And this worked.

Of course, you’ll need to download and install (and, probably, build before installing) gSoap, what, I hope, will not be a big problem. Then let’s assume we have a WCF service with following service contract running (this is just an example, I can hardly imagine a need in remote string concatenation service):

namespace SimpleServer
{
[ServiceContract]
public interface iStringService    {
[OperationContract]
/**
* <summary>
* String concatenation
* </summary>
* */
string Concat(string first, string second);
}
}

Writing, compiling and hosting the service is out of the scope of this article, however, I need to note that the only binding type I could make to work with gSoap with the service was Basic Http – keep it in mind when hosting your service.
Then is a step where a controversial feature of VS 2008 I have already written about (wcfsvchost.exe) really helps us – we need to get the service hosted and running before start using gSOAP. Run the project and have service hosted.

gSoap comes with two tools that make all stubs and bindings to programming language, which could be either C or C++, however, I was only interested in writing application in C++, which turned to be pretty straightforward.

At first, you’ll need to use wsdl2h.exe and the WCF service I mentioned above hosted and running. Assume that service entry point is http://localhost:8080/MyService/, and service WSDL is available on URL http://localhost:8080/MyService/metadata/?wsdl. This means that service endpoints’ configuration looks like the following:

    
      
        name="SimpleServer.Service1">
        
          binding="basicHttpBinding" bindingConfiguration="HttpBase" bindingNamespace=""
          contract="SimpleServer.iSimpleService">
          
            
          
        
        
          contract="IMetadataExchange" />
        
          
            
          
        
      ;

Note – Visual Studio can generate metadata endpoint for you with some URL like “http://localhost:8978/Design_Time_Addresses…“, which can be used as well.

Execute the following:

wsdl2h.exe -o myService.h http://localhost:8080/MyService/metadata/?wsdl

It will create a file myService.h contains some basic bindings enough to write SOAP client in C. As I wanted to use C++, I had to move a little bit further and take a next step:

soapcpp2 -i -I ..\gsoap\import -x -C myService.h

Option -i tells compiler to derive SOAP proxies from soap struct. This is not necessary, but I noticed the code looks less messy this way.
Option -I specifies path to import directory in gSOAP distribution.
Option -C enables client-side code generation only
and -x is needed if you don’t need to have any sample XML message files.

This will generate proxies for all service’s binding types that were configured, but we are only interested in ones that start with “soapBasicHttpBinding_” (in my case, the full file names were soapBasicHttpBinding_USCOREiStringServiceProxy.h and soapBasicHttpBinding_USCOREiStringServiceProxy.cpp) because others do not usually work (I failed with net.tcp and did not try wsHttpbinding at all).

Now let’s use this proxy:

#include  "soapBasicHttpBinding_USCOREiStringServiceProxy.h"
#include "soapBasicHttpBinding_USCOREiStringServiceProxy.h"
#include "BasicHttpBinding_USCOREiStringService.nsmap"
#include <iostream>

int main(int argc, _TCHAR* argv[])
{
    BasicHttpBinding_USCOREiStringServiceProxy MyProxy;
    /* Uncomment two following strings and modify path to the
    service according to your network configuration */
    // static const char* const pszEndPoint="http://localhost:8080/MyService/";
    // MyProxy.soap_endpoint=pszEndPoint;
    std::string s1("First string");
    std::string s2("Second string");
    // Note this:
    _ns1__Concat Param;
    _ns1__ConcatResponse Response;
    Param.first = &s1;
    Param.second = &s2;
    if (MyProxy.Concat(&Param,&Response)==SOAP_OK)
    {
     std::cout
           << "Service responded: "
           << (*Response.ConcatResult)
     ;
    }
    else
    {
    std::cout
         << "SOAP service call error"
         ;
    }
}

This still looks a little messy but gives an idea. If you look at BasicHttpBinding_USCOREiStringServiceProxy class implementation, you will see that each method of WCF service has corresponding method in that class, but signature is different. Method Concat has two parameters, first for input values and second for output, what explains what generated _ns1__Concat and _ns1__ConcatResponse structures are used for.

That’s it – this little example worked. Of course, you’ll need to add generated files into your project as well as stdsoap2.cpp (which can be found in main directory of gSOAP) and pay attention to *.nsmap file.

Of course, this does not cover all possible questions that may arise, but it gives a good starting point. From my point of view, gSOAP would be a good solution when there is a need to write a client for existing WCF service.

Yes, I am C++ maniac and would write everything in C++, if I could, but I am not an idiot. I have written distributed network applications in C++ before, this is why for a new project I decided to see how .Net eases such tasks.

That’s true – Windows communication foundation looks pretty good. It’s straightforward, it hides all network stuff behind and even newly released VS 2008 has sufficient project templates that make WCF services creation as easy as can be.

Only a few clicks and you’ve got a fully functional skeleton for the service – just add some business logic and you are ready to go. Even more, new studio helps you debug these services – as you try to run it (remember trying to run a DLL project in Studio 2003 and scary error messages?) Studio kindly starts a process that hosts your service (WcfSvcHost.exe) and shows a nice client that allegedly helps you debugging that service. Isn’t it what we all were dreaming about? Finally, distributed application development became really easy!

Well, it wouldn’t be a Microsoft creation if there were no hidden surprises. In this case, great feature of Studio that allows developer to start a newly created WCF service without a hassle of writing hosting application by her- or himself may become a nightmare.

Studio tends to host and start all WCF services from current solution even if you want run and debug completely different project which may not use any of those services at all! It just does it because these projects are there. And it gets worse when the application consists of a few WCF service projects and Windows or console or NT service project that, as developer intended, should host these services in production. Just imagine – you want to see if your program starts and starts these services, but before you see it running, you’ll watch notification that “Your service(s) have been hosted”. Then you realize that all your services are hosted somewhere else but not by where you wanted them to be. If you did not modify service entry point in App.config, you’ll see exceptions coming through as “another application has already registered that address”. Of course, it did. WcfSvcHost.exe did it for us.

I tried to find the way of switching it off but all my efforts have failed. I found a post with similar problem and the only answer was

If the WCF projects are in the same solution as your WPF app, the debugger will also startup your services. This makes the debugging experience simpler where you can simply set a breakpoint in the WCF service and break whenver the WPF app calls into the WCF service.

Isn’t it pretty? It makes debugging simpler! But who says I was going to debug anything?

I wouldn’t be debugging anything at all. I forgot how to use debugger – for a last few years I completed several projects (in C++, by the way) and they did not have any memory leaks, crashes, performance problems and other nasty things. Without using debugger at all. I just prefer unit tests.

That’s all – great idea, nice project template, but a little feature that breaks everything apart.

Or I just missed a check box somewhere?

No, I did not. All my efforts to stop VS from starting WcfSvcHost.exe each time I run any project were fruitless. But I could stop it from hosting services by removing (or making invalid) app.config in corresponding projects. At least it prevents hosting process from starting the service and occupying a port which I was going to use.

Upd: Just found similar question and possible workaround:

you can remove the ProjectTypeGuids tag from the project file as a workaround.

Another update: After some research I found a way to consume WCF service with unmanaged C++ client.