Configuration and the Enterprise Library Configuration Tool
| Chapter 1 explained how the Configuration Application Block's runtime stores the metaconfiguration data for a section in the application domain configuration file (i.e., app.config or web.config), how it provides capabilities to encrypt configuration settings using a key and symmetric algorithm, and how Enterprise Library's features can be configured for an application by using an XML editor to modify the XML for those features. This section introduces the Enterprise Library Configuration Tool, a Windows application that provides developers and administrators with the ability to easily configure application blocks, StorageProviders, Transformers, encryption information, and more. Essentially, the Enterprise Library Configuration Tool is a part of the Configuration Application Block that you can use to configure any application or block that uses the Configuration Application Block's design-time features without the need for an XML editor. The Enterprise Library Configuration Tool uses the Configuration Application Block to not only read and write the configuration information contained for an application, but to also load the design-time objects for each application block. The design-time objects for an application block are populated with information obtained from their corresponding configuration runtime objects. For example, the configuration nodes for the Data Access Application Block shown in Figure 2.1 (e.g., connection string nodes and database type nodes) retrieve their configuration information from the runtime components of the Data Access Application Block. The Configuration Application Block populates these runtime objects by getting the configuration settings from the StorageProvider that is configured for that block. The design-time components then use that information to display the settings in the Enterprise Library Configuration Tool. Figure 2.1. Enterprise Library Configuration Tool As you modify the configuration settings at design time, the application block design-time objects update their corresponding runtime objects to reflect the changes. When you save an application through the Enterprise Library Configuration Tool, the design-time objects perform validation on the data and report any failures. If the configuration is valid, then the Configuration Application Block writes the metaconfiguration to the application domain configuration file, and the configured StorageProviders write to their respective data stores. Each application block provides support for its design-time configuration by leveraging the design-time classes that are part of the Configuration Application Block. This is accomplished by implementing the interfaces, deriving from the classes, and overriding the methods that are exposed by the Configuration Application Block. This entails creating classes to represent configuration nodes, configuration menu items, and a configuration design manager. As I cover each of the other application blocks in later chapters, I demonstrate how to use this tool to easily configure that block's features as well. To begin using the Enterprise Library Configuration Tool, click Start > All Programs > Microsoft patterns & practices > Enterprise Library June 2005, and then click Enterprise Library Configuration. Figure 2.1 illustrates some of the primary features of the Enterprise Library Configuration Tool. Creating a Configuration SectionYou can use the Enterprise Library Configuration Tool to create, modify, and remove configuration sections for an application. You can choose to either create a new application configuration file or to open an existing one. A nice thing about this tool is that it works with existing application domain configuration files. If you already have developed a Web application and decide to use some of the features of Enterprise Library at a later date, you can point the Enterprise Library Configuration Tool at the web.config file for the Web application. This simply appends the metaconfiguration that it needs, but it doesn't modify any of the other configuration data that is contained in it.
Figure 2.2 shows a new application configuration file named Tabbed Application. It has a Configuration Application Block and a new configuration section named Tab Config Info. Figure 2.2. Adding a Configuration Section After you have created a configuration section, you can configure it to use a StorageProvider and Transformer. The following sections describe how to do configure these. Configuring StorageProvidersTo configure StorageProviders and Transformers, you just add or change the application's metaconfiguration. These modifications can be automated by using the Enterprise Library Configuration Tool. A configuration section must have one StorageProvider to read and write configuration data and may optionally have one Transformer to change the form of the data. To add a StorageProvider, right-click on the Configuration Section node and select New. This displays a list containing all the available StorageProviders and Transfomers. The StorageProviders that are available with Enterprise Library are XmlFileStorageProvider, AppConfigFileStorageProvider, RegistryStorageProvider, and SqlStorageProvider. You can also configure a custom StorageProvider using the Enterprise Library Configuration Tool. The following sections describe these StorageProviders. The XmlFileStorageProviderThe XmlFileStorageProvider is probably the most popular StorageProvider because it was the only one that shipped with the initial release of Enterprise Library and is the default StorageProvider when another application block is added to the configuration for an application. Configuring an XmlFileStorageProvider amounts to configuring the location and name for the external XML file it uses. Relative pathspaths relative to the location of the application domain configuration fileare supported. If a path isn't specified, the file will be created in the same folder as the application domain configuration file. Any path entered must be valid and must exist at the time the application block attempts to read or write configuration data. In other words, the Configuration Application Block will not create directories for paths that don't exist. To set this property, change the value of the FileName property in the Property Panes dialog. Figure 2.3 illustrates an added XmlFileStorageProvider with a renamed FileName property. The data for this configuration section is in a file named tab.config. Figure 2.3. Configuring the XMLFileStorageProvider Listing 2.1 shows the app.config file for this application. Listing 2.1. App.config file After Adding an XMLFileStorageProvider
Because the XmlFileStorageProvider is configured to store its configuration data in a file named tab.config, a tab.config file now exists in the same directory. This file, currently empty because no configuration data has been saved to it yet, will be populated once configuration data for an application has been saved. For example, Listing 2.2 might be a fair representation of the contents in the tab.config file if this configuration represents the Listing 1.1 in Chapter 1 for saving an application's tab configuration. Listing 2.2. Tab.config File After Saving Configuration Data
The AppConfigFileStorageProviderWith the XmlFileStorageProvider, the configuration data for each configuration section gets saved in its own XML file. Some architects prefer to have all the configuration data, including metaconfiguration, for an application reside in the application domain configuration file instead. The AppConfigFileStorageProvider is designed to fit this requirement. This StorageProvider allows the configuration data for a configuration section to be saved and retrieved from the application domain configuration file. To use this StorageProvider, right-click on the Configuration Section node and select New > Application Configuration Storage Provider. Because a configuration section can only have one StorageProvider configured for it, if a StorageProvider has already been configured for this configuration section, you will first need to remove it by selecting the StorageProvider node, right-clicking it, and selecting Remove. There is nothing to prevent you from erroneously adding more than one StorageProvider to a configuration section if editing the XML with an editor. The Enterprise Library Configuration Tool, however, understands this to be invalid and will prevent more than one StorageProvider from being added to a single configuration section. This is one example of how the Configuration Tool increases productivity by helping to prevent configuration errors from occurring. Once you have added the AppConfigFileStorageProvider for a configuration section, you don't need to do any other configuration for it. It uses the name of the file that was set for the Application node to determine where to save the configuration data for this section. Optionally, you can rename the StorageProvider the same way as the other configuration nodes thus far. This is generally true for all configuration nodes in the Enterprise Library Configuration Tool. There is no need for separate configuration files like the tab.config file that was shown earlier; all the metaconfiguration and configuration data is saved in the application domain configuration file. Listing 2.3 represents what the configuration data might look like in the application configuration file. Listing 2.3. Application Configuration File When Using the AppConfigFileStorageProvider
Incidentally, an Xml SerializerTransformer was added to the configuration for this section for the application to run properly. Adding Transformers to an application are covered a little later in this chapter. The RegistryStorageProviderAnother approach to eliminate the need for separate configuration files for each configuration section is to save and retrieve the configuration data from the Windows Registry instead of files. To create a RegistryStorageProvider, right-click on the Configuration Section node and select New>Registry Storage Provider. Configuring the RegistryStorageProvider involves setting the RegistryRoot property and RegistrySubKey property. The combination of these properties gives the StorageProvider enough information to locate the proper key. The RegistryRoot property represents the root key of the registry tree where this StorageProvider will read and write the configuration data for this configuration section. A drop-down list exists for the RegistryRoot property to ensure that the value for this property is one of the ones shown in Table 2.1.
The RegistrySubkey property represents the subkey in the configured registry root where this StorageProvider will read and write the configuration data for this configuration section. You can enter a subkey path by separating the subkeys with the backslash character (for example, Software\ Company\Application). If any key in the subkey path does not exist, it will be created when the Configuration Application Block writes the settings. The RegistryStorageProvider will create a subkey underneath the location that is specified for this property with the name of the configuration section. Figure 2.4 illustrates the sample application described in Chapter 1 configured with a RegistryStorageProvider. The RegistryRoot property is set to LocalMachine and the RegistrySubkey property is set to Software\ SomeCompany\TabbedApplication. Figure 2.4. Configuring the RegistryStorageProvider When the configuration data for this application is saved, the Registry keys will be created if they do not already exist. The configuration data for the TabConfig configuration section will be saved and retrieved from the Software\SomeCompany\TabbedApplication\TabConfig key underneath the HKEY_LOCAL_MACHINE registry root. Figure 2.5 depicts how the configuration data will be stored in the Windows Registry. Figure 2.5. Results from Using the RegistryStorageProvider The SqlStorageProviderThe SqlStorageProvider allows configuration data to be read from and written to a Microsoft SQL Server database table. To create a SqlStorageProvider, right-click on the Configuration Section node and select New > Sql Storage Provider. Table 2.2 describes the properties that must be configured for this StorageProvider, ConnectionString, GetConfigStoredProcedure, and SetConfigStoredProcedure. The combination of these properties provides the SqlStorageProvider with enough information to save and retrieve the configuration data for a given configuration section.
Enterprise Library ships with a SQL Script called SqlStorage.sql that you can use to create the database table, stored procedures, and a trigger that allows the SqlStorageProvider to operate properly. This script is located in the src\Configuration\Scripts directory where Enterprise Library is installed. Figure 2.6 illustrates what the configuration properties might Figure 2.6. Configuring the SqlStorageProvider look like for the SqlStorageProvider in the Enterprise Library Configuration Tool. When the configuration data for this application is saved, the configuration data will reside in the Configuration_Parameter table (by default) in the database indicated by the connection string. A trigger exists on this table that allows the SqlStorageProvider to recognize when configuration data has changed for a particular section, even if it is changed from outside an application using the Configuration Application Block. Figure 2.7 illustrates executing a SQL query with the Microsoft SQL Server Query Analyzer to view the configuration data for a configuration section. Figure 2.7. Using the SqlStorageProvider Custom StorageProvidersThe Configuration Application Block also allows custom StorageProviders to be configured with the Enterprise Library Configuration Tool. The section "A Custom StorageProvider: DatabaseStorageProvider" in Chapter 1 described the process for creating a new StorageProvider and showed how to configure the StorageProvider by manually editing the XML in the metaconfiguration. Alternatively, the StorageProvider can be configured with the Enterprise Library Configuration Tool; however, to do so, you must take one additional step when creating the StorageProvider. A custom StorageProvider's Attributes property plays a vital role in providing the ability to read the metaconfiguration that is set for it. The Attributes property is a NameValueCollection of configuration items. When a custom StorageProvider is configured, the metaconfiguration properties that the provider needs must be configured in this Attributes property. For example, the custom DatabaseStorageProvider shown in Chapter 1 needs the same kind of information as the SqlStorageProvider: connection information for connecting to the database, the name of a stored procedure for retrieving configuration data, and the name of a stored procedure for saving configuration data. The Enterprise Library Configuration Tool provides an editor that makes this process a bit easier. In Figure 2.8, a custom StorageProvider has been added by right-clicking on the Configuration Section node and selecting New > Custom Storage Provider. I have configured this custom StorageProvider to use the DatabaseStorageProvider by using the Type Selector dialog that is provided by the Configuration Tool. This utility enforces that the type selected implements the IStorageProvider interface. When the DatabaseStorageProvider was selected, the tool entered the fully qualified type name of the DatabaseStorageProvider as the value for the TypeName property. The TypeName property is important because it determines the actual StorageProvider that will be created. I then configured the parameters needed by the DatabaseStorageProvider by adding items in the NameValueItem Collection Editor, which displays when the ellipses button is clicked for the Attributes property. Figure 2.8. Configuring a Custom StorageProvider But how does the DatabaseStorageProvider know how to use the items in the Attributes property? The answer is that the DatabaseStorageProvider needs to look for the values contained in the Attributes collection when it is initialized. First of all, you don't need to create a data transfer object (e.g.,DatabaseStorageProviderData) when creating this type of custom StorageProvider. Instead, the StorageProvider uses the CustomStorageProvider-Data class that is provided by the Configuration Application Block. In the Initialize method for the StorageProvider, the CustomStorageProviderData's Attribute collection should be queried for the necessary items, and these values can be stored in member variables for the StorageProvider. Listing 2.4shows how the Initialize method would need to be created for the DatabaseStorageProvider to query the Attributes property for the data it needs. Listing 2.4. Initialize Method for the Custom DatabaseStorageProvider
Custom StorageProviders are nice because they make it easy for you to create new StorageProviders and "snap them into" the Configuration Tool with little effort. When a StorageProvider is created, it leverages the design-time properties that have been established for all custom StorageProviders. Namely, these are the TypeName and Attributes properties. Sometimes, however, it is desirable to create a StorageProvider that works more like the StorageProviders that ship with Enterprise Library. This allows many benefits, such as validation of the metaconfiguration data in the tool. To accomplish this, the features and functions of the configuration design-time tool need to be leveraged (this is described later in this chapter). configuring TransformersA configuration section can have up to one Transformer to change the configuration data provided by the StorageProvider into the format needed by the application and then transform it back again from the application to the StorageProvider. As mentioned in Chapter 1, Enterprise Library shipped with a single Transformer, the XmlSerializerTransformer, and the MvpSerializerTransformer was released later. This section shows how to configure both of these Transformers and how to configure a custom Transformer, like the BinaryTransformer shown in Chapter 1. The XmlSerializerTransformerThe XmlSerializerTransformer allows configuration data to be serialized to and deserialized from XML. It serializes objects to an XmlNode and deserializes them from an XmlNode into the appropriate type. Each of the StorageProviders that ship with Enterprise Library was designed to work with the XmlSerializerTransformer. They each accept and return an object of type XmlNode in order to store and retrieve the serialized object to and from the configuration data store. To use an XmlSerializerTransformer for a configuration section, right-click on the Configuration Section node and select New > Xml Serializer Transformer. Because a configuration section can only have one Transformer configured, if a Transformer already exists for this configuration section you will first need to remove it by selecting the Transformer node, right-clicking on it, and selecting Remove. XmlIncludeTypes can be added so that a Transformer can properly create object types that it does not explicitly know about. Any custom providers that don't ship with Enterprise Library fall into this category. The Transformer must know the assembly and type name for such an object so that it can create them. Figure 2.9 shows a configuration section that has been configured to use an XmlFileStorageProvider and an XmlSerializerTransformer that contains one XmlIncludeType. Figure 2.9. Adding an XmlSerializerTransformer to a Configuration Section The MvpSerializerTransformerThe MvpSerializerTransformer, introduced in Chapter 1, works very much like the XmlSerializerTransformer except that it uses a predefined and compiled class that derives from an XmlSerializer in an effort to negate the startup cost associated with the XmlSerializer. To use an MvpSerializerTransformer for a configuration section, right-click on the Configuration Section node and select New > Mvp Serializer Transformer, then select the specific type you will use to serialize the configuration data into an object. This is the class that was created with the Mvp.Xml.XGen tool. The fully qualified typename for this class needs to be specified as the SerializerType for this property. The Enterprise Library Configuration Tool makes this task much easier by using a Type Selector dialog to automatically fill in the fully qualified name for the selected class which derives from XmlSerializer. The SerializerType is important because it determines which object the MvpSerializerTransformer will instantiate to serialize and deserialize the configuration data. Figure 2.10 illustrates how to add an MvpSerializerTransformer to a configuration section and how to use the Type Selector utility to select an appropriate object type for it. Figure 2.10. Configuring a Section to Use the MvpSerializerTransformer Custom TransformersThe Configuration Application Block allows custom Transformers to be configured with the Enterprise Library Configuration Tool in the same way that StorageProviders can be configured. The concept is exactly the same. Figure 2.11 illustrates adding a custom Transformer to a configuration section by right-clicking on the Configuration Section node and selecting New > Custom Transformer. After the Transformer has been added, you need to select the specific type of Transformer by using the Type Selector utility. In this case, the Type Selector only shows classes that implement the ITransformer interface. This allows the BinaryTransformer that was created in Chapter 1 to be selected. Figure 2.11. Adding a Custom Transformer to a Configuration Section You don't need to add items to the Attributes property because the BinaryTransformer does not need additional information to operate properly. Therefore, there is no need to encapsulate a CustomTransformerData in the BinaryTransformer provider or query for the Attributes in its Initialize method. If a custom Transformer did need to obtain additional configuration data, it would need to implement a strategy similar to that for the custom StorageProvider mentioned earlierexcept that it would use the CustomTransformerData class instead of the CustomStorageProviderData class. Encrypting Configuration DataAs described in Chapter 1, the Configuration Application Block's runtime features support encrypting configuration sections for an application using a single key/symmetric algorithm pair. By default, the key is saved in a plaintext file and the file should really be further protected with technologies like the Data Protection API (DPAPI). The Enterprise Library Configuration Tool provides a wizard you can use to both create the key/algorithm pair and enable DPAPI protection for the master key file. Follow these steps to create the KeyAlgorithmPair.
DPAPI operates in either User or Machine mode. In User mode, the ability to decrypt the file is restricted to the account of the user who was logged in when the file was encrypted. Machine mode restricts the ability to decrypt the file to the computer used when the file was encrypted. This means that any user with an account on that computer can decrypt the file. If you select Machine mode, you can use additional security features (e.g., ACLs) to lock the file down even further. Figure 2.13 illustrates using the File Key Algorithm Storage wizard to enable DPAPI protection in User mode. Figure 2.13. Using the File Key Algorithm Storage Wizard After the key has been created, a node for a File Key Algorithm StorageProvider will be added underneath the Encryption Settings node. The only settings you can change for this node are to switch it from one DPAPI mode (User/Machine/None) to another. If you want to make other changes, like selecting a new symmetric algorithm or generating a new key, you will need to create a new KeyAlgorithmPair. Figure 2.14 illustrates the configuration hierarchy after the KeyAlgorithmPair has been created. Figure 2.14. The Configuration Hierarchy of the File Key Algorithm StorageProvider You can use this KeyAlgorithmPair to encrypt the configuration data in any configuration section for an application. After creating the KeyAlgorithmPair, you can enable encryption for a configuration section by simply changing that section's Encrypt property from False to true. Figure 2.15 illustrates turning encryption on for the TabConfig configuration section. Figure 2.15. Enabling Encryption for a Configuration Section Now when the configuration data in this section is viewed, it will look something like Figure 2.16. Figure 2.16. Encrypted Configuration Section Data |
EAN: 2147483647
Pages: 103