Getting back to my earlier brain dump on the many ways you can create WCF services today...I have uploaded two samples:

The first sample is a solution with three projects: service, host and client. The service is a class library with a HelloIndigo.Service implementation, the host is a console application that initializes the ServiceHost for the service (self-host over HTTP), and the client consumes the service. ServiceFromScratchConfig.zip (54.5 KB)

THe second sample is a solution with two projects: a Web site created from the Indigo Service template, and a client to consume the service. The Web site acts as the host for the service (through IIS) but actually references the HelloIndigo.Service from the previous example. IISHostedService.zip (22.11 KB)

Same service, two hosts with possibly different bindings, behaviors, instancing.

If you always designer your services to be “moveable“ you will have an agile service-oriented system on your hands. The service contract and implementation (as expected) does not change, that should be appropriately versioned once it has been published. Oh, and guess what? Since the service is contained in a separate class library (assembly) it can be versioned appropriately with CLR versioning as well as contract versioning semantics.

So I have now explained why you should never use the Indigo Template “as is” when you build Web site, console, class library, or other applications that contain or host services. Sorry...templates are for kids...