There is a discussion which has been going on for serveral years when programming for SharePoint.
In Visual Studio you can add a SharePoint solution, which will be converted to a .wsp file to deploy. This .wsp file will contain all required assembly files.
How do you guys hande the codebehind files for: Event receiver, feature receiver, aspx page ?
Do you place this .cs file inside your SharePoint folder? (this way you will need to deploy a .dll from you SharePoint project aswell)
Or do you move all the code logic to one (or more) different project(s) (class libraries) ?
What you do for example in the second example:
- Right click, Add New item, Event Receiver
- Move the .cs file to a different project
- Change the assembly information inside the Elements.xml file
In the first example we do not move these files, just keep them as VS2010 adds them.
I am NOT saying which way i prefer, I just want to receive alot of input. Dont just say "option 2 is bad." I realy would like to know why and why not !
My question here has nothing to do with extensions etc.
I am talking about making sure your sharepoint solution does NOT contain ANY .cs file. This way there does not have to be an assembly in the GAC for this solution.
Example: I have Customer.SPS.Intranet.Solution (=the solution to generate WSP, so an Empty SharePoint Project Item).
If I simply add a feature and a feature receiver, a .cs file is generated and (after deployment) a Customer.SPS.Intranet.Solution.dll file is placed inside the global assembly cache.
This is what some people do not want to have !!! (I do not understand why, that's why I am asking some opinions).
To solve this, they create a project inside this solution named: "Customer.SPS.Intranet.Logic", this solution will contain all the feature receiver codebehind files.
This means we have to edit the feature template.xml file to use the receiver class located in the "Logic" project. This way we keep the "Customer.SPS.Intranet.Solution" clean and we'll only use it for packaging. So there WILL NOT be an assembly deployed to the GAC named "Customer.SPS.Intranet.Solution.dll"... instead a Customer.SPS.Intranet.Logic.dll assembly is deployed to the GAC.