I'm working on my first CSLA 4 project using a remote DP (hosted in IIS). One question I have is how others generally structure their services. As I struggled to understand the proper WCF and IIS application settings to use, I somehow ended up with two different IIS aplications - one for the service exposed to my WPF UI, and a completely different one exposed for my SL version of the same app. I don't remember if I separated them to keep me from inadvertantly making changes to one that affected the other, or if I did so because something forced me down that path.
For those of you who have multiple CSLA apps that use a remote DP, how do you go about structuring your DPs in IIS? Do you use one IIS application per project? Do you use one IIS application to host all of your WcfPortal services for WPF apps (using the IWcfPortal contract), and another for Silverlight apps (using the Silverlight.IWcfPortal contract)? Or do you use one for your entire organization that all your apps use?
Here's what I currently have, but again I'm confused and not sure if this is necessary or ideal:
Instead of doing the above, should I just have one service for the app (like http://server/MyFirstApp) that contains the service endpoints for WPF and SL? Or even beyond this, should I have something entirely more generic so that all future CSLA apps could partake...such as http://server/CslaDataPortal?
Any guidance is appreciated.
You should generally have one virtual root per application. That virtual root can expose a .NET endpoint, a Silverlight endpoint, or both types of endpoint.
Each virtual root is an "IIS Application" of course - but what you should really be considering is your application, and how each application should have its own virtual root so it remains isolated from other applications. This helps improve overall managability, and avoids cross-contamination of data, configuration, and user information. It also helps ensure you can version each application independently.
Copyright (c) Marimer LLC