Overview: Using the Object Model to Customize Administration
Last modified: April 07, 2010
Applies to: SharePoint Foundation 2010
You can use the Microsoft.SharePoint.Administration namespace to address two key scenarios for customizing the administration of a SharePoint Foundation deployment: management of administrative property settings, and creation of objects for custom properties. You can use existing types and members to make global changes to settings natively used in SharePoint Foundation, but when building an application on the platform, you can create custom classes that define and store custom property settings.
SharePoint Foundation includes a revamped administrative object model that provides access to functionality that was hidden in previous versions. The new object model is designed so that you can readily change administrative settings throughout a deployment. If you have a large server farm, or many server farms, and must change an administrative setting globally, you can do so through the object model.
With relatively few lines of code, you can write a script or a basic console application that configures an entire server farm in a particular way. If you need to change a specific property setting, use the object model to do so. For a task that illustrates how to create a simple console application for managing a SharePoint Foundation setting, see How to: Add Blocked File Types.
When you build an application on the SharePoint Foundation platform, you might need to create a class to define custom property settings for your application, and to provide a means for storing the settings. The Microsoft.SharePoint.Administration namespace in SharePoint Foundation introduces object persistence, through which classes that derive from the base SPPersistedObject class are persisted to the SharePoint Foundation database. To create a persisted object, you create a class that inherits from SPPersistedObject, or from a class in the Microsoft.SharePoint.Administration namespace that derives from SPPersistedObject. Your class can define an object model for storing custom property settings in the SharePoint Foundation database. You can create, for example, a Windows service that uses SharePoint Foundation in some way, which involves creating a class that inherits from the SPWindowsService class to store settings that are specific to your Windows service. Your compiled DLL provides customers an object model that they can use to retrieve or save properties. SharePoint Foundation provides a means and a place to store your settings, and manages their availability to all servers and processes in the server farm, including cache refresh.
For an example that shows how to define a custom administration object, see Walkthrough: Creating a Content Service Object.
You do not need to write code for serialization, because SharePoint Foundation automatically handles serialization of persisted objects, which inherently derive from the SPAutoSerializingObject class. If you are developing a product on the SharePoint Foundation platform and need a place to store settings that are accessible to all servers in the farm, no matter how big the server farm grows, you have two options:
Put the settings in a text file, and every time anything changes, copy the file to all the servers, or put the file in a share that is guaranteed to be available to all the servers, or perhaps enter settings in the registry of all the servers. You might need to write a lot of complex code for every property, and determine how to put the property setting in an appropriate location, and how to retrieve it.
Create a persisted object class and add arbitrary fields to store your settings. Because your class is automatically serialized, you do not need to determine how to store data or convert it to some storable format. You provide a class that contains fields for integers, strings, GUIDs, arrays, and so on, and SharePoint Foundation serializes the data to the database for you. Your class defines the members for property settings, but from the base class it inherits automatic serialization, storage, and propagation of settings across the server farm, as well as cache invalidation. SharePoint Foundation provides passage of your settings in and out of the database, or applies the settings to other servers and to other processes, without you needing to write code to convert, for example, integers or GUIDs to strings.