I made a suggestion on how to create a SharePoint project structure in my "SharePoint Development" presentation at Microsoft Copenhagen back in January, but there is no documentation on it in the PowerPoint presentation.
http://www.keutmann.dk/sharepointblog/SharepointDevelopment.zip
In my experience, I find that keeping the number of WSP packages down to a minimum is the easiest thing to managed. Therefore I put all my SharePoint artifacts in one project. Some large SharePoint solutions may require more than one WSP package, but generally not many. I also separate the business logic from the SharePoint project, so it will not be GUI dependent. I use this structure as a general template whenever I create a new Visual Studio solution.
MyCompany.Framework
This project is not specific per solution, but can be used as a library across multiple solutions. This project do not contain any business or SharePoint logic, only clean .NET code. I usually create a lot of.NET Extensions in this project.
MyCompany.SharePoint.Framework
This project is for generally SharePoint related extensions and is still generic across multiple solutions. A lot of .NET SharePoint Extensions is added to this project.
MyCompany.BusinessModel (or ObjectModel)
This project will contain all my business logic and data objects. The project will not contain any UI logic.
MyCompany.MyProjectName (SharePoint Project)
This is the SharePoint artifact project from where I will build my WSP package by use of WSPBuilder. All the SharePoint webparts, features and so on will be created here. It is usually set to deploy to Global Assembly Cache. However if company policy requires the code to be deploy with Code Access Security (CAS), I will create an additional SharePoint project, so I have one project for the GAC and one for the WebApplications bin folder.
MyCompany.Test
The project for Units tests.
I do not say that this is the best structure, but I find it as a good template to start from, specially that I can reuse the Framework projects from solution to solution.
4 comments:
Hrmm that was bizarre, my remark received eaten. Anyway I wanted to say that it¡¯s good to know that another person also talked about this as I had trouble finding the identical data elsewhere. This was the first place that advised me the answer. Thanks.
You describe a simple project structure where there are some classlibrary-projects, a test-project and one sharepoint-project. I assume you add the classlibrary dll's to your wsp as additional assemblies. Still sounds simple.
But we have a situation where our SharePoint farm is shared with other companies (part of our group). Each company has his own webapplication. And has his own design.
We wanted to follow your suggested project structure, one structure (sln) per company. But then the same framework (common) dll's are deployed more than once. That sounds like a bad idea.
So we made an extra project structure (called Common.sln) for deploying the framework dll's and some custom features/webparts/businessobjects which can be reused across companies.
But we need to reference the projects in the Common.sln from the company solutions. And to avoid debug and release differences we started copying the dll's to a Bin folder in the post-build event in the projects from Common.sln.
It has become a sort of spagetti...
What would you suggest for our little more complicated situation?
Another possible solution for the solution structure.
a SharePoint solution invariably will contain multiple WSPs, artifacts. A provisioning engine that will collate all the deliverable will be a good idea to add to the solution.
http://bitofthought.blogspot.in/2012/05/visual-studio-sharepoint-solution.html
http://bitofthought.blogspot.in/2012/05/visual-studio-sharepoint-solution.html
Post a Comment