I have a Visual Studio solution containing a web site project plus a bunch of supporting projects (domain model, data access, etc).
I want to expose an API to the same underlying data, via urls under the same domain, so I developed a WCF/REST project to do this (which has dependencies on the same set of domain/data access projects).
Now I’m wondering what the pros and cons are of having the WCF service in a separate solution, deployed under a virtual IIS path, compared with just putting the WCF project into the original website solution.
Are there good reasons why I would want to go one way or the other? I’m not too experienced with IIS deployments.
IF you ever want to self-host the service instead of hosting it inside IIS, or if you ever want to share the service interface as an assembly for some reason, it will probably be easier to have it in a separate assembly.
I would recommend one assembly for the service interface(s) (including data contracts and such), one for the service implementation, and another (if needed) for a self-host (e.g. Windows NT service or command-line app). That’s the cleanest separation and there’s no real reason not to go that way, IMHO.
Marc