1

I want to know what to look for and what to do (both from a developer and IT admin point of view) before installing a third party solution into a SharePoint 2007 farm?

Is there a checklist that I can follow?

Can my deployment target a particular farm, site collection or site?

These solutions could be Site Definitions, Web Parts, Field Controls etc.. including the freely avilable Codeplex solutions.

Do I have to worry about code access security?

Is there a white paper or blog post that you can direct me to?

Thanks.

||improve this question
  • Changed to community wiki as it is not a single question/answer it is more of a request for best practice. – Charles Lee Apr 28 '10 at 7:42
2

Here is a list from the top of my head, others might have something to add to it (in general these types of questions are bordering to community wiki style question with no single answer):

  • artifacts should be packaged in a sharepoint solution (WSP file)
  • web.config configuration should be managed using SPWebConfigModification class to provide consistent deployment across Web Front Ends (where possible! There are configuration entries where it is not possible to use this class)
  • demand reasons from developer for putting assemblies in the GAC (there might be good reasons such as event handler code, or other code that need to go in GAC or that code should be reached across WFE)
  • depending on company policy you could require that code is decorated with CAS attributes to allow lowest possible CAS settings (dont accept code that demand Full trust, then it might as well be in the GAC!)
  • make sure WSP files are documented -just a few lines to tell what the solution contains and what it does (makes it easier when you need to debug what caused your farm to become unstable)
  • make sure dependencies between WSP files are documented
  • require that upgrade scenarios have been thought into the features you are about to install (often this will include callout code that handles feature deactivation)
  • create a baseline performance indication of your farm that you update each time you deploy new solutions and features to monitor performance degradation
  • use batch files or PowerShell scripts to deploy your packages to make deployments consistent across environments (dev-test, integration-test, pre-prod, prod)
  • demand your code as a bare minimum is unit tested (also consider functional testing, load testing..)
  • developers should run SPDisposeCheck.exe as part of their release builds
  • dont accept debug mode build assemblies!
  • suggest developers do code review before releasing code

Will add more later if i think of more :-)

||improve this answer
1

Another slant to thinking about this is that everyone's needs are different. You should develop a Governance Model that covers all of this for your situation. Large banks are not going to have the same governance as small startups. The staffing will be different, the skills will be different, etc. So there's no "one answer". One of the key questions you need to ask yourself is "What do I need to do to be able to support this?"

||improve this answer
0

You need to have a CAS policy, which disallows maliscious code running in the environment when dealing with thirdparty code

||improve this answer
  • It doesn't really - its not that granular and neither is the "Sandbox" model in 2010. Sure you can restrict the code from doing something like writing a file or editing a registry key. But you can't stop it using the SP object model to delete every single list in your site. – Ryan Jun 23 '11 at 23:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy