Sunday, July 24, 2005
Enterprise Library has Built-in Dependency on WMI Instrumentation Schema
As my team was deploying his solution based on Enterprise Library v1.0, we discovered something that was not stated clearly in the documentations; EL has a set of instrumentation support built-in, and this introduces dependency on an instrumentation schema. This schema must exist on the executing machine, otherwise the following error is generated:
Failed to fire the WMI event 'DataConnectionOpenedEvent'.
Exception: System.Exception: This schema for this assembly has not been registered with WMI.
at System.Management.Instrumentation.Instrumentation.Initialize(Assembly assembly)
For developers, the schema would have being installed during the installation of EL by a batch file, "InstallService.bat". Hence, this issue will not be discovered on the development platforms until the time comes for deployment on production machines. Details of this instrumentation schema can be found at MSDN: Monitoring in .NET Distributed Application Design, and Registering the Schema for an Instrumented Application.
To resolve this issue on deployment platform, simply execute the batch file "InstallService.bat" on the deployment machine again, and the required schema will be installed. Note that this must be run under 'Local Administrator' rights for the registration to be successful (no more simple xcopy deployment?).
In addition, the release notes for EL v1.1 (June 2005) does highlight this issue.
From experience, the needs for instrumentation (post-deployment) is very vital. Building instrumentation into a solution, on top of the functional requirements, can make the difference between hell or ease for application support.
However, the EL's dependency on the schema is far from ideal, IMHO. Why didn't they provide flexibility to plug-in different Providers like they have done for other application blocks? Isn't this binding the EL to the implementation specifics on MS's platform features like WMI? A coincidence, or conceived move? You tell me.
Failed to fire the WMI event 'DataConnectionOpenedEvent'.
Exception: System.Exception: This schema for this assembly has not been registered with WMI.
at System.Management.Instrumentation.Instrumentation.Initialize(Assembly assembly)
For developers, the schema would have being installed during the installation of EL by a batch file, "InstallService.bat". Hence, this issue will not be discovered on the development platforms until the time comes for deployment on production machines. Details of this instrumentation schema can be found at MSDN: Monitoring in .NET Distributed Application Design, and Registering the Schema for an Instrumented Application.
To resolve this issue on deployment platform, simply execute the batch file "InstallService.bat" on the deployment machine again, and the required schema will be installed. Note that this must be run under 'Local Administrator' rights for the registration to be successful (no more simple xcopy deployment?).
In addition, the release notes for EL v1.1 (June 2005) does highlight this issue.
From experience, the needs for instrumentation (post-deployment) is very vital. Building instrumentation into a solution, on top of the functional requirements, can make the difference between hell or ease for application support.
However, the EL's dependency on the schema is far from ideal, IMHO. Why didn't they provide flexibility to plug-in different Providers like they have done for other application blocks? Isn't this binding the EL to the implementation specifics on MS's platform features like WMI? A coincidence, or conceived move? You tell me.
