2

My SharePoint Visual Studio solution structure currently contains these projects:

  • Common: contains extension methods, helpers, frequently used controls, etc.
  • Logging: would normally be included in Common but contains calls to native methods so marked 'unsafe'
  • Site-specific project: one for each distinct site, containing features, web parts, event receivers, etc. specific to that site
  • Console app: console app projects as/if needed

I'm using WSPBuilder hence each project (apart from the console apps) has its own SharePoint WSP solution file.

Is this a good way to split up SharePoint code? What approaches do you use?

Alex Angas
  • 59,219
  • 41
  • 137
  • 210

2 Answers2

2

That seems reasonable, though you might want to be careful about the deployment of the shared projects - The deployment script probably includes updating the common package, which isn't good for older site specific projects.

For most projects I prefer to have a single solution package with necessary shared libraries included - usually being installed to the GAC.

Tom Clarkson
  • 16,074
  • 2
  • 43
  • 51
  • Good points here, though planning updates the the common package here should be SharePoint agnostic - the need to maintain backward compatibility is equally strong. – Greg Hurlman May 13 '09 at 14:23
2

If you aren't doing this already, I would consider bundling your common code into one or more features and have the non-common code be in a feature with a feature dependency to the common code. You may want to have the common code use a different WSP or the same WSP - not sure of all of the pros/cons of that.

Kirk Liemohn
  • 7,733
  • 9
  • 46
  • 57