It depends how you want to structure and manage your deployments. We also support an "advanced" install which requires a "/farcry" alias/virtual directory/mapping, and you can use this to deploy your projects against one copy of FarCry Core (including your plugins) if you like, or you can use it to keep the framework outside of the webroot (even if you have individual copies of Core with each project).
The only configuration difference is where you point the webroot of the site in your webserver, and the additional /farcry alias/virtual directory (for CF) or mapping (for Railo)
For a "shared" Core, the steps would be something like:
- Extract the Community release to C:/inetpub/wwwroot/Clients so that you see a "farcry" folder within the Client folder (i.e. you should see C:/inetpub/wwwroot/Clients/farcry, and within it you should see core, plugins, skeletons).
- Inside the farcry folder, create a "projects" folder (C:/inetpub/wwwroot/Clients/farcry/projects)
- Inside the projects folder, create a "tiger" folder, and inside that create a "www" folder. You should now have C:/inetpub/wwwroot/Clients/farcry/projects/tiger/www -- Set this as your webroot in your webserver.
4a. For ColdFusion installations, add a "/farcry" alias (for Apache) or virtual directory (for IIS) to your webserver which points to C:/inetpub/wwwroot/Clients/farcry
4b. For Railo, go into the Railo Admin and add a "/farcry" Mapping which points to C:/inetpub/wwwroot/Clients/farcry (in either the Server context or Web context, up to you)
- Run the installer with the usual steps described in the instructions
However, we find that it's easier to manage when all of your sites have their own copy of FarCry Core, because you can update them independently and not worry about a Core upgrade affecting a site that you may not have wanted to upgrade, etc.
The same concerns apply to sharing a database, which some other frameworks allow you to do. When you have many sites installed into a single database you need to be mindful that an upgrade may affect many sites all at once. Or similarly, when one site grows very large and you want to split it into a separate database or move it to a different host you may have some difficulty - perhaps some frameworks offer tools to do this, but I'm not sure. We generally find that this is more trouble than its worth (unless the application is specifically designed to work this way, like the BroadcastMed platform that Geoff mentions), so 9 times out of 10 we'd recommend keeping everything separate.
Long story short, I'd stick with the simple webroot installs for now