3

Soon, I will start a new sp2013 project and I want to start it fine from the scratch. I just read the Application Lifecycle management chapter from the book Professional Sharepoint 2013 development book.

They suggest to use a sharepoint project for each webpart, and indeed its an amazing idea, in my current project, we didnt do it that way ,and deployment and upgrades of webparts might be difficult.

They also suggest a common framework for all projects and one package for each site definition or publishing packages.

The questions, is how do you usually do it in very HUGE environments and projects?

I was thinking of:

mycompany.commonframework.wsp mycompany.commonframeworkforpublishingsites.wsp mycompany.humanresources.wsp (a solution that will deploy a site definition for HR alongside with all the resources HR will need) mycompany.management.wsp (same here) mycompany.webpart1.wsp mycompany.webpart2.wsp

What else would you recommend me?

What about the structure inside each project??

Luis Valencia
  • 5,201
  • 22
  • 118
  • 219
  • Possible duplicate of http://sharepoint.stackexchange.com/questions/11249/list-of-best-practices-on-structuring-sharepoint-2010-solutions , http://sharepoint.stackexchange.com/questions/53509/sharepoint-2010-visual-studio-project-structure , http://sharepoint.stackexchange.com/questions/3084/structure-of-sharepoint-solution, – Muhammad Raja Apr 22 '13 at 12:25

1 Answers1

3

I am currently working on a large project for a large and local retailer. We have a few web parts, quite a few timer jobs and 4 event receivers. The structure we use has all non-SharePoint pieces in a standard format, where these is data, business, etc in separate projects and separate dlls.

Then we have a SharePoint project for common types, where I have a event receiver project, a timer job project, and a UI project. Those projects each have features for each unique piece for example timer job 1, 2, and 3 each have their own FEATURE.

I also have 5 deployment project that solely have the use of building common projects, There is a common deployment project that each of the Web Applications will need installed and there is a separate project for each Web Application. (We a creating a solution for 5 Business Units, 3 share Web Apps, and 2 are separate.)

There is also one case where we have a shared lived piece, so that piece gets its own project and thus its own WSP.

In the end we have about 10 features AND 5 WSPs in our solution.

(Common deploys globally and deploys all of the external dlls)

Sam Sussman
  • 1,678
  • 10
  • 22
  • +1 for deploying non sharepoint using WSP file instead of a manual gac add. This way, you will leverage the SharePoint deployment model, very usefull on farm with multiples servers ! – Steve B Apr 22 '13 at 12:13
  • can you post a screenshot of the vs Solution explorer please? you could just erase the confidential parts. – Luis Valencia Apr 23 '13 at 05:38