Overview: Using the Object Model to Customize Administration
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
You can use the Microsoft.SharePoint.Administration namespace to address two key scenarios for customizing the administration of a Windows SharePoint Services 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 Windows SharePoint Services, but when building an application on the platform, you can create custom classes that define and store custom property settings.
Managing Administrative Settings
Windows SharePoint Services 3.0 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 Windows SharePoint Services 3.0 setting, see How To: Add Blocked File Types.
Defining Custom Administrative Settings
When you build an application on the Windows SharePoint Services 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 Windows SharePoint Services 3.0 introduces object persistence, through which classes that derive from the base SPPersistedObject class are persisted to the Windows SharePoint Services 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 Windows SharePoint Services database. You can create, for example, a Windows service that uses Windows SharePoint Services 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. Windows SharePoint Services 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.
Automatic Serialization
You do not need to write code for serialization, because Windows SharePoint Services automatically handles serialization of persisted objects, which inherently derive from the SPAutoSerializingObject class. If you are developing a product on the Windows SharePoint Services 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 Windows SharePoint Services 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. Windows SharePoint Services 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.