How should SharePoint Visual Studio projects that share each other's code be managed?

Question

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?

Answer 1

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.

Answer 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.