Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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?

share|improve this question
add comment

6 Answers

up vote 16 down vote accepted

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

share|improve this answer
2  
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 3 '12 at 10:26
add comment
  • 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

share|improve this answer
add comment

Regarding namespaces: Microsoft has recommendations: Namespace Naming Guidelines

share|improve this answer
add comment

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.

share|improve this answer
add comment

If you read Vesa Juvonens super-article about SharePoint 2010 WebTemplates, http://blogs.msdn.com/b/vesku/archive/2010/10/14/sharepoint-2010-and-web-templates.aspx, 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.

share|improve this answer
add comment

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

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.