Export (0) Print
Expand All

Administering Enterprise Library

This topic describes some of the main scenarios for system administrators and operators who manage applications that use Enterprise Library. In general, the processes and techniques are no different from those involved in managing any .NET application. However, Enterprise Library does provide several useful features designed to make administration and management easier. This section covers the following topics:

The assemblies provided with versions of Enterprise Library from 3.0 onwards are versioned and signed with a strong name, and can be installed in the global assembly cache. You can install assemblies from different versions of Enterprise Library in the GAC, as the configuration and binaries for each application will specify the version they require. As there are sometimes breaking changes between versions, you should ensure that you r configuration specifies the correct version.

Alternatively, you can install the assemblies in the application bin folders instead of the (GAC). This approach ensures that each application is deployed with the appropriate version of the assemblies, and it can simplify initial deployment and redeployment to a different location. You do not need to install Enterprise Library on an application server if all of the assemblies used by the application are installed in the global assembly cache or the appropriate bin folders. However, if you need to enable Enterprise Library instrumentation, you should run the install services script provided with Enterprise Library to register this instrumentation.

It is possible to use different versions of the Enterprise Library assemblies in the same application, but this may cause issues with dependencies and should generally be avoided if possible.

In most cases, applications originally designed and built to use Enterprise Library version 2.0 and higher will work with this version. However, there may be issues if developers have modified the source code or created custom providers.

For more information, see the following topics:

The application configuration file, or an alternative configuration source used for Enterprise Library, contains the information for the majority of features and the behavior of the Enterprise Library blocks. This includes the providers or extensions that the blocks use, and their individual settings. This information can be encrypted if required.

Administrators can edit this configuration to change almost all aspects of the way that Enterprise Library works, with the exception of features that are configured through attributes within the code. In general, these attributes are used only to specify settings such as validation rules, interception policies, and dependencies between components. Almost all other settings are defined in the application configuration.

Enterprise Library contains configuration tools that work with application configuration files. The version of the tools that integrates with Visual Studio can only be used if you have Visual Studio installed on the server. Instead, you can use the standalone version of the configuration tools to manage Enterprise Library where Visual Studio is not installed. However, each version of Enterprise Library uses its own specific version of the configuration tool that has been compiled with the appropriate version of the Enterprise Library assemblies—though you can deploy multiple versions of this tool and its associated assemblies in separate folders.

Configuration information can also be exposed through the manageable configuration provider, which you can use as an alternative to the default configuration provider. The manageable configuration provider respects Group Policy settings. It responds to run-time configuration updates, and will apply these to the relevant application block configuration.

For more information, see the following topics:

The flexibility and configurability of Enterprise Library makes it easy to change the behavior of the application without requiring redeployment. With the exception of the Logging Application Block, changes to the configuration file are only applied when the application restarts. The Logging Block does detect changes to the configuration at run time, and will apply these within a few seconds. If you edit the configuration file for an ASP.NET application, it will automatically force a restart. For other types of applications, you must manually force a restart.

The capability to update the behavior of the application through configuration means that administrators can change features such as the providers or extensions used by the blocks, and the individual settings for each block. In addition, the configuration tools support multiple deployment environments that share the same basic configuration but require different property settings. You can generate a default configuration for the application and then specify additional settings as deltas from the default.

For more information, see the following topics:

With the exception of Unity, all of the Enterprise Library blocks expose comprehensive instrumentation that administrators can use to monitor the operation of the components within the blocks. This instrumentation includes performance counters, and Windows Event Log events.

For example, the Exception Handling Application Block exposes performance counters that indicate the rate and total number of exceptions it handles, and raises events when an error occurs while handling an exception. These events can be written to the Windows Event Log.

Instrumentation is turned off by default, but can be turned on in the application configuration. Enterprise Library also contains scripts you can use to configure the instrumentation— to create the relevant performance counters, for example.

For more information, see the following topics:

Most enterprise-level application management tools and environments, such as Microsoft System Center, can collect and use information and events from a variety of sources, such as performance counters, and the Windows Event Log. The instrumentation built into the Enterprise Library application blocks can expose this type of instrumentation, allowing the application to be monitored through your existing environment.

In addition, developers can incorporate the Exception Handling Application Block to provide a structured strategy for handling errors and exceptions in the code, and use the Logging Application Block to send log entries to a wide variety of targets including e-mail, Windows Message Queuing, a database, Windows Event Log, or other locations that support integration with a range of management and monitoring tools.

This approach is particularly useful if developers include additional instrumentation in their application code that can be turned on and off in the configuration of the Exception Handling and Logging Application Blocks. This allows administrators to obtain additional information about the operation of the application when investigating run-time or deployment issues.

For more information, see the following topics:

Developers can choose to include the source code projects for Enterprise Library when creating applications in Visual Studio, instead of referencing the existing assemblies. This allows debugging and tracing through the Enterprise Library code if required. Although this is not a common scenario, it does allow both developers and administrators to examine the source code and—if required—modify it to meet their specific requirements.

Developers may also decide to use the source code to create modified versions of Enterprise Library blocks, or extend the existing blocks, to provide customized solutions. The modified source code can be compiled and, if required, strong named for use in the global assembly cache or for security reasons.

For more information, see the following topics:


Show:
© 2014 Microsoft