Saturday, May 30, 2009

Manageability of custom code on a MOSS server environment

Types of Custom Code
To ensure manageability for a MOSS server, all custom code should be packaged into one of the standard SharePoint constructs for building custom applications. Any custom code should be deployed with a solution (described below).

Ø Solution
A solution package is a cabinet (.cab) file with a .wsp file name extension and a manifest file. It can contain the following components:

  • Web Part files (*.webpart, *.dwp)
  • Site definitions
  • Code access security policies
  • Feature definitions and their corresponding element definitions and files
  • Template files and root files, which can include the following:

---- _layouts files
---- Resources (*.resx)
---- Resource files (for example, *.doc or *.xls)

  • Assemblies, which can include the following:

---- Safe control entries
---- Resources

For a detailed description of solutions and web-part packages, refer to

Ø Features
Features reduce the complexity involved in making simple site customizations, and are robust when upgrades are applied to a deployment. Features eliminate the need to copy large chunks of code to change simple functionality. Features thus reduce versioning and inconsistency issues that may arise among front-end Web servers. Features make it easier to activate or deactivate functionality in the course of a deployment, and administrators can easily transform the template or definition of a site by simply toggling a particular Feature on or off in the user interface. Features provide the following capabilities:

  • Pluggable behavior for activating or deactivating Features at a given scope
  • Scoping semantics for determining where custom code runs
  • A scoped property bag for storing data required by a Feature within its scope
  • Pluggable behavior for installing or uninstalling Features within a deployment
  • The basis of a unified framework for distributed deployment of WSS solutions

For a detailed description, refer to

Ø Excel User Defined Functions
User-defined functions (UDFs) are custom functions that extend the calculation and data-import capabilities of Excel. Developers create custom calculation packages to provide:

  • Custom implementations to built-in functions.
  • Functions that are not built into Excel.
  • Custom data feeds for legacy or unsupported data sources, & application-specific data flows.

Users who create workbooks can call UDFs from a cell through formulas—for example, "=MyUdf(C6*2.2)"—just like they call built-in functions.

Excel Services UDFs give you the ability to use formulas in cells to call custom functions written in managed code and deployed to Microsoft Office SharePoint Server 2007. You can create UDFs to:

  • Call Web services from the UDFs.
  • Get data from custom data sources into worksheets.
  • Call custom mathematical functions.

Ø User Controls
SharePoint does not directly support ASP.NET Web user controls but they can be hosted inside a web-part. Web parts such as SmartPart & Son of SmartPart for SharePoint 2007 can be used for this purpose. It’s deployed in the GAC which can be leveraged to host your user controls instead of writing your own web-part to host these controls. If you prefer to write your own host web-part, it should be deployed in the BIN directory of SharePoint web-application.

Ø InfoPath Form Templates
InfoPath Forms Services, as part of either Office Forms Server 2007 or Microsoft Office SharePoint Server 2007, provides a Web browser experience for filling out InfoPath forms. For computers that do not have Microsoft Office InfoPath 2007 installed, users are able to work with the same form layout and logic as a user with InfoPath installed on their computer. Additionally, the same form can be used in the browser or in the client, which simplifies the form template design and management process. The InfoPath Forms Services technology is built as a feature on the Microsoft Office SharePoint Server 2007 platform. InfoPath 2003/2007 doesn’t have built-in support for consuming WSE 2.0 enabled web-services.

Ø Business Data Catalog Application Definitions
One of the major design goals for the Business Data Catalog is to enable you to surface business data from various business applications such as SAP, Siebel, databases and web-services with minimal coding effort. To achieve this goal, the Business Data Catalog provides homogeneous access to the underlying data sources with a declarative metadata model that provides a consistent and simplified client object model. Version 1.2 of WSS 3.0 SDK includes BDC Definition Editor which automatically generates the XML definition file required for exposing data sources. BDC is exposed as a Shared Service in SharePoint which means that this application definition will be seen by everyone. The real value of BDC in SharePoint is reach, search and composite application. It’s recommended that you should use LOB application itself for changing data.
For complete technical details, go to

Code Access Policy
The Sharepoint environment should not allow custom code to run with full-trust by default. SharePoint Server should be configured to run with medium trust (WSS_MEDIUM). Any custom assemblies should be deployed in the BIN directory hence will run with medium trust which does not allow direct access to system resources like registry or event logs or calling a public web-service. In order to grant specific permissions to an assembly, the custom code access policy is used to give controlled and granular access. Please refer to the following MSDN article for a detailed discussion;

Elevation of Privileges
This new feature in SharePoint 2007 allows you to execute code under increased level of privilege than that of a current user.

No Support for WSE 2.0
SharePoint does not have inherent capability of using Web-Services Secured (WSE 2.0) in the current version. A custom solution is required to pass credentials to consume such a web-service.

No comments:

Post a Comment