Sometimes it is really helpful to have different ways to build things...like WCF services for example...I can approach it from many different starting points. If I know I am going to host my services as part of a Web site/application...I might start from a different path than if I was building a truly service-oriented application that may or may not be always exposing services over HTTP and/or through IIS.

So you can do any of the following to create a service:

 a)       Create a new Web site project using the Indigo Service template and selecting HTTP (creates an IIS virtual directory for you, that's great!)

b)       Create a new Web site project using the Indigo Service template and selecting File System (this creates a file-based Web site, no IIS virtual directory, hosted with Cassini Web server)

c)       Create a new Class Library project then add an Indigo Service template item to it (no virtual directory is created for you, and no .svc endpoint is created...because the idea here would be to host this service “wherever you like“)

d) Create a new Console Application project then add an Indigo Service template item to it (no virtual directory or .svc but you can add self-hosting code to this application, coupling the host and service in one)

Some observations:

Option a) is useful for testing IIS services because it quickly generates a project that and creates the appropriate IIS virtual directory.

Option b) is problematic for a few reasons. First because in general, Cassini testing does not yield the same results as IIS-hosted testing when we’re talking about anonymous vs. authenticated access. Second because it requires NTLM authentication by default, requiring extra steps to enable access to your services on the development machine (I'll make a separate post on this)…possibly settings that will leak into deployment configs for QA and production if not caught. Whenever possible I think we should develop in the environment we will deploy in.

Both a) and b) have another drawback, that the service interface now gets lumped into the deployment of the ASP.NET Web site (the project it belongs to). That means either deploying source (hopefully no one will really deploy source in ASP.NET 2.0...just because you can) or precompiling the site (so now the code for the service is lumped into the ASP.NET application DLLs and it must now be versioned with those DLLS). This tightly couples the service (which should be an agile component of a system) to the ASP.NET application it is exposed through. I recommend there NOT be a template for creating indigo services with Web sites for this reason…because it moves you away from a pure service-oriented design.

Option c) is best because it implies that the service interface is part of a component that can be distributed and used by either an ASP.NET site, or a self-hosting environment, but coupled to neither.

Option d) couples the service to the host, nice for demos, not practical in deployment.

Of course, we always want tools for testing, that will make us quickly productive, and for that reason I say perhaps we are missing a few things. If we can have templates for services exposed as part of Web sites ( a) and b) ), we should also have template for creating self-hosted console services ( d) ), or IIS hosted class libraries ( c) with a twist ). The last item there is what we are missing perhaps, just in productivity terms:

e) Create a new Class Library then add the template item for IIS Hosted Indigo Service. This would create the IIS vdir and give us the darned .svc file for our class library, maybe even set the Build directory to \bin instead of \bin\debug or \bin\release so it will work without editing that.

Of course e) goes against my initial argument -> to force developers to build services in a service-oriented and decoupled manner...which would mean get rid of all but c) and watch people scream. I think what we'll need instead is a) through d) (plus e) if I get my wish) and we'll need to educate people why real services should be designed with c) because you know that a million and one code samples are already flying out to the Web that don't do c).

I'll post some samples separately, I wanted to get my rant out first. That feels better.