List of best practices on structuring SharePoint 2010 solutions

Question

I am looking for good guidance on how to structure a SharePoint Solution including:

Visual Studio Project Structure
Features (how to separate features)
Namespaces
When to use multiple project containers

Are there any good articles, documentation or books on this subject?

score 18 · Accepted Answer · answered Apr 14 '11 at 16:32

There are quite a few things to consider in organizing your structure, or else maintanance or understanding the code becomes a nightmare (even if you revisit after a few years).

A similar question was asked in an earlier best practices post.

Some rules I follow are:

Keep all projects in one folder ("Projects"), keep solutions in another folder ("Solutions"). That way you can have any solution use any projects, esp useful if you have common framework-type projects, Keep all the dependent assemblies separate.
Namespace should indicate the intrinsic functionality of the code, not company, not type not departments, nor something too generic or superfluous (Company.Data eg) . I have worked on projects where company names have changed and had to go thru some tedious refactors, but using company name seems to be the norm in .Net world. Sometimes makes sense, sometimes not. Refactoring is not simple in SP, as code references are in wsp, cdb, config files, webpart pages etc. Naming by project has less chances of changing names and external dependencies.
In anycase, the intrinsic functionality of the module never changes (order is always an order), so it is useful to have namespaces reflect that and put all order related stuff in it. Adding types to namespaces seems superfluous to me in most cases, but occasionally it is useful.
If your marketing webcontrol is generic enough and will be used by somebody else tomorrow, or your marketing is renamed or merged to "sales", you have a code that carries history.
With VisualWebParts, now webpart code and webcontrols are generated together by VS2010. So unless its a webcontrol all of its own without a webpart, may be you can have it a WebControls namespace.

In general, I have seen Functional namespacing makes it quicker to understand the overall relationship of different modules without having to worry about how it is implemented.

Regarding #2 and #3: There's a reason why "Company.Data.*" is "the norm in .Net world" (and I might add in Java world). You might not like it personally, but be careful before suggesting as best practice something that deviates from what everyone else is doing. — Louis, May 03 '12 at 10:26

score 12 · Answer 2 · edited Mar 24 '23 at 12:05

12

If you read Vesa Juvonens super-article about SharePoint 2010 WebTemplates, Link, you will see how he organizes and names features and SPI's. It's a very good approach and it mmakes it very easy to locate SPI's and features in the (not so user-friendly when you have tons of SPI's) package and feature designer.

edited Mar 24 '23 at 12:05

Glorfindel

1,050
1
11
17

answered Apr 23 '11 at 14:51

Wictor Wilen MCA MCM MVP

18,207
40
64

score 8 · Answer 3 · answered Apr 14 '11 at 15:12

Project Structure - I'm still experimenting with different styles, though it seems to be the norm to split off artefacts (such as c# WebParts) atomically, and use project references to include a "release version" of that project into a SharePoint Project designed solely for Packaging. This prevents you from building half-finished and broken code and including that in the current build of the solution you are working on.
Features will be separated by Scope, I personally don't think it's necessary to split up provisioning of columns, webparts, content types, etc... only gives the user more stuff to switch on.
Namespaces - I tend to use ClientName.Division.Function.ArtefactType - so for example: Contoso.Marketing.Branding.WebControls for controls that are used specifically in a solution used only by the Marketing department of Contoso.

Project containers? Haven't used them yet. Slap me silly if I should read into them, still spending a lot of time on my current 2007 project :P

score 7 · Answer 4 · answered Apr 14 '11 at 21:44

7

Regarding namespaces: Microsoft has recommendations: Namespace Naming Guidelines

answered Apr 14 '11 at 21:44

score 7 · Answer 5 · answered Apr 15 '11 at 19:09

7

I think that any .Net guidance that you can find is a really good start, since it's still a .Net project. You could look at the Developing Application for SharePoint 2010 from the Microsoft Patterns & Practices, which is more specific.

answered Apr 15 '11 at 19:09

Gabriel Mongeon

313
5
14

score 5 · Answer 6 · answered May 03 '12 at 10:02

5

The following link describes sharepoint 2010 project structure (VS project structure) http://bitofthought.blogspot.in/2012/05/visual-studio-sharepoint-solution.html

answered May 03 '12 at 10:02

Dileep Jose

1
1
1

score 0 · Answer 7 · answered Nov 18 '14 at 14:00

Victor Wilén did a pretty good writeup on the SharePoint project that I have found applicable in my work situtations.

The template was an output of a collaborative conference, held in London couple of years ago. THe creation of the template involved several Microsoft MVP's, including: Andrew Connell, Ben Robb, Eric Schupps, Matthew McDermott, Mirjam van Olst, Paul Schaeflein, Todd Carter and Waldek Mastykarz.

The template is available from: http://www.wictorwilen.se/Post/International-SharePoint-Conference-2012-wrapup.aspx

and http://spkbase.codeplex.com/

List of best practices on structuring SharePoint 2010 solutions

7 Answers7

Linked