I usually run svcutil directly, using a batch file. This has a few benefits, chief among them is that you don't need to talk to a running service.
svcutil is capable of generating the required code based on your service definition from the implementation assembly.
Here is the contents of a batch file I use for this purpose:
rem set up path so svcutil can be found
rem this is where the service implmentation assembly is located
rem this assembly contains types shared between the client and server
rem let svcutil generate wsdl
rem let svcutil generate code ( service reference )
svcutil %WCFSERVICECLIENTDIR%\wsdl\*.wsdl %WCFSERVICECLIENTDIR%\wsdl\*.xsd /namespace:*,Goodtech.Databox.DX.Client /targetClientVersion:Version35 /language:C# /ct:System.Collections.Generic.List`1 /out:DataServiceReference.cs /config:GeneratedApp.config /reference:%COMMONTYPESDLL%
A typical solution will usually have at least:
- An assembly for types shared between client and server
- An assembly for the service implementation
- A windows forms application that hosts the service implementation - for development purposes
- A windows service that hosts the service implementation - for deployment
- A client API assembly that wraps the code generated by svcutil, adds logging, connection handling, etc.
- The client application
Everything that determines how the client and server talks to each other goes into the application configuration files.