I've scoured the internet and tried asking different questions but still can't come up with a nice solution to this problem. Consider a situation where I have 2 web parts, each of which is being developed at the same time by different developers. From what I have gathered, it is impossible to deploy only one of these web parts as a feature without pushing the other if they are both features in the same .wsp solution. So the only way I can see to divide them up and avoid issues with developers clashing while they try to develop their web part is to make an entirely different solution for every single web part. Not only does this not sound right and is a major pain when I have to put in 5 Powershell commands for to deploy each, but the structure that Visual Studio uses when I create a visual web part strongly suggests that multiple web parts should be included in the same solution. Please someone who has developed SharePoint in a team environment enlighten me!

1 Answer 1


How exciting, I'll infer you have multiple requirements and resources to manage, a headache sometimes with any tool, but where to start with SharePoint? The catch 22 is the answer, in a logical world we'd need you to be more specific before we could answer, as we're dealing with information solutions here are some general specifics:-

If you plan to code, deploy, maintain solutions long term, you have an opportunity to reuse code, however while sharepoint OOTB does not provide a base or shared framework, the sharepoint developer community is fab, enthusiastic and large. Plus the API is no more than a .NET 1.0 wrapper around some flat tables stored in SQL Server with security trimming, regardless of whether your code will run on the server or primarily in the user's browser.

Look at the functionality in your solution design, and determine where code will sit. In the main, put 20% in the SharePoint context so it is embedded and reusable for multiple configurations in your SharePoint solutions. Put the remaining 80% outside the sharePoint API so it is maintainable with more familiar and productive coding techniques (c# and Linq, js and Json, html5 and CSS).

Server side code - use common assemblies and package these first. Client side code - abstract what you can, in common js files or behind custom services, and package these seperately Branding - override the existing CSS after it loads, and package these seperately too. JavaScript - call SP when you have to, otherwise use standard js e.g. Jquery etc

To package, list your solutions in XML, and run SP powershell to iterate against them all.

To start, structure your solution:-

Framework Branding and assets Solution for X Solution for Y Build Scripts if required in Linqpad or if required wrapped by event handlers e.g. To create sites or on feature activation or deactivation.


On the server side, add assembly references to web.config, and code like ASP.NET is running. Use Linqpad to prototype and build reusable code, and deploy in shared assemblies. Use user controls or copy and paste an existing aspx page to template your solution's page. Don't waste time trying to code everything inside an event handler or timer job, code the 80% outside using standard .net patterns and OOP - and insert into shared or solution specific assemblies. If you are coding a product solution or deploying to a highly secure environment, you'll have to script every config change, but if you aren't, deploy your code to the bin/gac and resources to layouts/ourresources/x and y...after all, the sharepoint product development team never did otherwise!

On the client side, do likewise, that is, code outside a sharepoint vs project, and simply use the project to bundle, package and output solutions for release.

Depending on what solutions you build, divvy up your solutions as shared and business / functionality / API namespace specific.

Once you have an idea of these, google examples from the community e.g. On codeplex. And deploy project solution files using an automated script which does uninstalls, installs, and if needed feature activation. Ideally, run Linqpad scripts against your shared assemblies to prepare specific configurations for your users, or do so in the browser.

This sounds a lot, but essentially I'm saying code and package sharepoint solutions with as little sharepoint code and caml as possible, and code the rest as you would otherwise. And secondly, identify the parts of sharepoint's Apis you want to use, and reuse someone else's efforts as a starter. Thirdly, if you do something cool or new, reciprocate for the community.

Your Answer

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

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