There are a ton of third party addons to SharePoint ranging from useful to just fun, from open source communities or commercial providers. The business value from the addon can be very good, but you need to make sure there are no hidden cost. What if the addon introduce:

  • Performance and/or stability issues?
  • Increased operations cost?
  • Elements that take your solution in an unsupported state?
  • Increased upgrade cost?

One of the key questions you need to ask yourself is "What do I need to do to be able to support this?"

How your company handle third party addons and code must be described in your governance plan. With the governance plan you have a tool for mitigating the risks. If you don't care about the possible issues, so just write that in the governance plan (not a good idea though). The governance plan is unique for each company. Keep it short and follow up on what you decides on. Most of the value is in the work itself to create the governance plan.

 

What to look after and require?

Here are some guidelines and recommendations to help set up a plan for handling 3rd party addons in SharePoint:

  • In general do not customize existing SharePoint files in the 14 hive. Except for a few well-defined files such as the web.config or docicon.xml files, you should never modify the built-in files included with SharePoint Products and Technologies except through official supported software updates, service packs, or product upgrades.
  • 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
  • Don’t accept debug mode build assemblies!
  • Suggest developers do code review before releasing code

 

Separate application farm?

In some cases the risk can be mitigated by running the third party addon in a separate farm (application farm). That way it will not negatively affect the other SharePoint solutions. An application farm has a cost, doesn't suite all 3rd party addons, and complicates worldwide/global installations.

Information harvested from these resources and experiences: