Scripting the COM+ Catalog
COM+ applications can be complex to configure. This complexity increases as you use more COM+ services. By the time you have an application that consists of several configured components, using multiple roles, and method level security it is almost impossible to easily document the configuration of the application. In an environment where all of your source code is routinely stored in a configuration management system and you can automatically rebuild any version of your application from your source tree, having to then manually reconfigure your COM+ application from scribbled notes and memories is simply not an option.
The COM+ Catalog is manipulated by the COM+ Admin COM objects. These allow you to do anything that can be done using the COM+ Explorer programmatically. The interfaces are very general, dealing in COM+ catalog collections which contain COM+ catalog objects, which in turn have name/value properties. These interfaces can be used to access the entire configuration of your COM+ application, store it externally to the COM+ catalog and then rebuild your application from it.
The scripts available from these pages make it possible to save your COM+ application's configuration as an XML document, place it under version control with the rest of your source code and then recreate your COM+ application from it at a later date.
You can save multiple applications into a single XML document, the result of saving the three COM+ applications that form part of IIS can be seen here.
Patching for different environments
Some configuration settings may be specific to a particular environment in which you you wish to run your application. For example, the
ConstructorString property of an object may be different if you're running your application on a development server rather than a production server. The scripts allow you to save complete applications and also application patches. A patch is simply a subset of the XML required to create the entire application, it can be as many or as few settings as you like and can be applied after the main application has been recreated to allow you to tailor the application for a particular environment. At present you have to create the patch files manually using a tool like the XML notepad, but I intend to produce some scripts which will make this process easier [I never did - Len, 2005]. An application patch element is different only in that the element name is
ApplicationPatch rather than
Application and it has a
Patch attribute that is used to allow a file to contain different patches for the same application. An example can be found here.
Run each script without any parameters for a help screen listing available options.
- 11th June 2000 - Initial revision at www.jetbyte.com.
- 12th June 2000 - A few bug fixes.
- 15th June 2000 - Bug fix: save component properties before configuring component, interface and method roles. If the "ComponentAccessChecksEnabled" property isn't set to true and the component saved before configuring roles then the role configuration is silently ignored.
- 29th June 2000 - New functionality. You can now create patch files that include a prompt and a default value. If a prompt is present then a dialog box is displayed and the user is prompted for the value that will be patched - useful for password requests, etc. You can also add a prompt to each application and application patch so that the user can be given some information about what they're installing.
- 27th September 2005 - reprinted at www.lenholgate.com.