I'm currently working on a large SharePoint 2010 published intranet development project. The initial months of planning have been completed and we're now gearing up to commence the actual dev/build.
At a glance, our overall solution comprises the following applications:
- An intranet site (publishing portal)
- A separate collaboration portal (team sites)
- My Sites
FYI: All these applications will be hosted in the cloud (SharePoint Online) and as such must be deployed using sandbox solutions.
What would be the best way to structure our Visual Studio solution? I.e. What are the best practices for splitting up our overall solutions into projects, features, WSPs etc.
Please consider the following points:
- Each application will be deployed to it's own single site collection.
- We will be branding all three applications consistently (i.e. they will all need to share the same custom masterpages, page layouts and theme files).
- This project will be provisioning brand new SharePoint 2010 applications, but obviously once we go live the solution needs to be able to "upgrade" files and sites without blowing them all away.
- We will need to be able to update/upgrade certain elements of the solution frequently after our initial go-live (e.g. custom web parts, list definitions, workflows etc) without having to re-build, re-package and re-deploy other things such as the theme and global site template. Does this mean we should split our SharePoint projects up by function rather than by application?
- Sandbox soltuions do not permit us to deploy any physical files to the file system, so everything must be deployable to the content database (i.e. Style Library, Assests Library etc).
- Sandbox solutions cannot make use of site definitions, so we will be using web templates to define each of our subsite templates.
An ideal answer may just include a screenshot of a dummy Visual Studio solution which shows how the various applications / packages / features / content types / lists / web parts / branding files have all been split up.