Home » full trust solutions » Microsoft offers some recommended procedures for SharePoint customizations built with full trust solutions

Microsoft offers some recommended procedures for SharePoint customizations built with full trust solutions

VisualSP Logo 250x80In the final 10 mins of the 1st of 6 video tutorials titled Transform SharePoint Customizations to SharePoint App Model, Vesa Juvonen, a Senior Program Manager at Microsoft presents several correct practices developers can use to safely build custom trusted solutions for SharePoint, on-premises.

The first 40 minutes of the video were devoted to a structured presentation, perhaps it would be better to refer to it as a rhetorical argument intended to persuade the audience to hasten their pace of adopting the SharePoint App Model.

Regardless, in the final 10 minutes the audience is treated to a presentation of how to build some components correctly, if custom trusted solutions are a development standard for an organization committed to SharePoint, on-premises.

The components include (each quote in the following list is excerpted from a set of PowerPoint Slides presented by Juvonen as an accompaniment to his verbal presentation in this segment of the video):

  • Content Types and Site Columns, which Juvonen acknowledges would be better built with “code called from feature receiver”. Opting to create these components with code affords the developer an opportunity to handle debugging via the console, as opposed to the “hit or miss” nature of the alternative of working directly with element XML
  • List Templates. Juvonen cautions his audience to avoid custom list templates. The problem is each custom list template will have a “unique identifier and [this identifier] creates dependency on the list instances to the schema.xml file of the list template. Should the custom solution be retracted, all of the associated lists can be adversely affected. Once again, the recommended solution is to hard code the template. He does mention creating a custom schema XML file would also work.
  • Custom Fields. Creating custom fields for farm solutions is not recommended. “Data stored in the database will have dependency on the custom field type, which will cause challenges in migration scenarios”. The recommended solution is “[c]onsider using only field controls for presentation or use client side rendering for list editor overrides”

In my opinion the tone of “acknowledgement”, which colors this section of the video is welcome. What I mean is both Walker and Juvonen acknowledge the legitimacy of some popular complaints about apparent errors in MSDN documentation, and, perhaps even software bugs. But their acknowledgement is also accompanied with a commitment to using the video to help developers find the “right” path through these issues to achieve success with their plans to customize SharePoint.

©2015, Ira Michael Blonder & Rehmani Consulting, Inc. All Rights Reserved