6

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.

Improve this question
1

1 Answer 1

Reset to default
4

Break everything into seperate projects. I myself am currently in a similar type of project and what we decided to do was the following:

We made a project for each aspect of the site.

  1. Branding - Pagelayout, Masterpages, CSS, Javascript, XSLT (ItemStyles, ContentMainQuery etc. for CQWP).
  2. Webparts - Custom webparts, Overriden webparts.
  3. Controls - Custom controls, Web controls, User controls
  4. ContentTypes - Says itself.
  5. Workflows & BCS.
  6. List definitions.
  7. Site definitions.

The Branding project you might want to brainstorm a bit, as there will come situations where having all branding related files in 1 solutions, especially with the pagelayouts, will be a P.I.T.A.
So an idea might be to split the Branding package into 2 solutions; one with pagelayouts and masterpage, and the other with css, js, xslt etc.

It gives a brilliant overview (from my experience) and you can have several people working on the same solution, but in different projects without having major issues overriding each others work.

Hope this enlightens your search for a solution model a bit :)

Improve this answer
2
  • Thanks for your feedback @Dandroid. My research also indicates the more projects the merrier. Making use of features such as solution dependancies and feature versioning can also make life easier here it seems. I'm still really looking for some specifics on how to break down / structure the actual projects (check out the link I added to my original post, it gives a great example of using solution folders). I'm still perplexed on where to draw the line between using a logic breakdown (i.e. splitting projects by content types, lists, web parts etc) vs a functional breakdown (i.e. "purpose").
    – user4545
    Commented Jun 13, 2012 at 6:58
  • @NickLarter It all depends on how your site is supposed to be constructed as well. Because one thing is having a public site, but then you maybe also have something Intranet specific or even MySite specific. So ways to break projects down even further is to give them prefixed names like: Company.Public.Branding (or) Company.Intranet.BusinessConnectivity (or) Company.MySite.Webparts etc. At least that's a logical way of doing it. From there you can break it even further down by, as you mentioned yourself, splitting projects by "purpose".
    – user2536
    Commented Jun 13, 2012 at 8:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.