Reza Alirezaei’s Blog

I understand that each project has its own requirements and those requirements would dictate the layout of your VS solution(s) and the way you package your work into WSP solutions.

As I discussed this with other MVP and non-MVP devs, we finally came to a conclusion that there is no “best way” that fits all scenarios -for example, my buddy Dan Attis (MVP) uses an interesting methodology to package his work into very atomic units (each wrapped into a  feature) and grouped into a Visual Studio project  based on their relevancy and mapped to a WSP solution (SharePoint Solution). One or more projects are located in one VS solution (4 to date). His logic is:

Support , extensibility and maintainability is #1 concern due to the nature of our project ;therefore we need to make sure that future updates would run in the most abstracted way possible. Additionally, we would like all of our developers to be able to work in parallel.We have come up with 25 WSP solutions in total.

We pretty much can’t follow the above approach as we are a small group of developers (Maximum 3 people on a project – one is our designer), always under the delivery pressure, we build, deliver and move on to the next project. Although , this doesn’t mean that we do a poor job on what we do, for us, agile development usually outweighs the extra time required to plan and deal with the complexity of such granularity. In addition, the total number of support cases we have got in 2008 has been ZERO so far, whereas we have got our hands on four medium to large scale projects since Q1. We simply can’t afford anything that causes extra complexity and slows down our dev cycle, my QA (Yeah, I like finding issues 😉 ) and final deployment to the customer’s site.

Below is the way I normally layout my projects in one VS solution. Each project is wrapped into its own WSP solution and deployed in orders. Groping related bits together and abstracting them from each other in a reasonable manner, gives us the possibility for 2 devs to be working on the same project without affecting each other’s work. Sometimes and  based on the situation , I may merge two or more projects into one package , but generally speaking , my deployments are around 5 to 6  WSP packages max.

      Core (Class library – Deployed to GAC)

1.      This project is meant to host the code thatis meant to be used as the base for all other projects in the solution (Think about it as classic Common lib)

OR

2.      Can’t be placed in other projects (for example my membership provider bit)

      Controls (Class library – Deployed to bin folder)

1.      All Web parts and user controls

2.      If I need more granularity in terms of security, I abstract the control in its own assembly and apply more restricted CAS on it

       Infrastructure (Class library – Deployed to GAC)

1.      Custom Field Definitions

2.      Standalone Site columns  (Standalone site column is the one which is used in an standalone content type)

3.      Standalone Content types (Standalone Content type is the one which has no workflow attached to it)

4.      List Definitions

5.      Non-publishing Site Definitions

6.      Custom processes attached to the non-publishing Site Definitions (For example :Provisioning handler)

       Publishing (Class library – Deployed to GAC)

1.      Field controls used in publishing context

2.      Publishing site columns

3.      Publishing content types

4.      Workflows used in publishing context

5.      Web parts used in publishing context ( for example those derived from Content Query Web Part)

6.      Master pages and page layouts

7.      Custom xslts used in publishing context

8.      Delegate controls used in publishing context

9.      Publishing Site Definitions

10.  Custom processes attached to the publishing Site Definitions

       Workflows (Class library – Deployed to GAC)

1.      Site columns

2.      Content types

3.      Workflows used in non-publishing context

4.      InfoPath forms used in workflows as Initiation, Association and task forms

5.      Feature receivers to add content types to the appropriate lists or doc libs proviosned by Infrastructure solution