Enterprise Library ""FAQs""

Have a question that isn't answered here? Ask it on the Enterprise Library Community
Know an answer to a FAQ not listed here? Please add it to the wiki.

General

Q: Why am I getting errors or event log messages similar to one of these:

* System.Security.SecurityException: Requested registry access is not allowed
* Failed to fire the WMI event 'DataConnectionOpenedEvent'. Exception: System.Exception: This schema for this assembly has not been registered with WMI.
* Failed to create instances of performance counter '# of Commands Executed/Sec' - The requested Performance Counter is not a custom counter, it has to be initialized as ReadOnly.."

A: Enterprise Library blocks invoke various instrumentation mechanisms, including WMI events, Event Log events and performance counters. These instrumentation types need to be configured before the blocks can write to them successfully, and this is not done automatically at install time. There are a few options to fix this:

The easiest thing to do is run the "Install Services" script from the Enterprise Library folder on the Start Menu (this launches InstallServices.bat). You need administrator privileges to run this script.
If you want to install the instrumentation and you don't have the InstallServices.bat script handy, you can run the .NET installutil utility over the Enterprise Library assemblies you are using. Again you need administrator privileges to do this.
If you are deploying Enterprise Library in an environment where you do not have administrator privileges or can't run the scripts for other reasons, you can disable the instrumentation. To do this you need to recompile Enterprise Library with different conditional compile directives:
Open up the EnterpriseLibrary.sln and modify the Configuration Properties\Build\Conditional Constants of the EnterpriseLibrary.Common project. Remove the USEWMI;USEEVENTLOG;USEPERFORMANCECOUNTER constants. By removing these constants, all of the internal Enterprise Library instrumentation will be disabled. Recompile.

Q: Why am I having problems using Enterprise Library January 2005 with Visual Studio 2005 / .NET Framework 2.0?

A: The January 2005 release of Enterprise Library was designed and tested only for Visual Studio 2003 / .NET Framework 1.1. If you try compiling the code using Visual Studio 2005, you will encounter a few errors due to breaking changes in the .NET Framework. You should download the June release if you want to use Enterprise Library with VS 2005 / .NET 2.0.

Q: Why am I having problems using Enterprise Library June 2005 with Visual Studio 2005 / .NET Framework 2.0?

The June 2005 release of Enterprise Library, while also designed for Visual Studio 2003 and .NET Framework 1.1, can be made to work with Visual Studio 2005 relatively easily (although of course it will not leverage any new .NET 2.0 features or best pracices). There are some steps you need to follow that are documented in the Release Notes. To install Enterprise Library June 2005 you must have .NET Framework 1.1 installed, but you don't need Visual Studio 2003. If you have only Visual Studio 2005 installed, make sure you uncheck the "Compile Enterprise Library" option in the installer. Once it has installed, follow the instructions in the release notes.

Q: When I run a web app using Enterprise Library June 2005 and Visual Studio 2005, why do I get this error?

* {http://www.microsoft.com/practices/enterpriselibrary/08-31-2004/configuration}ReadOnlyConfigurationSectionData’ is not found in Schema.”

Using F5 and debugging does not work since Visual Studio does schema validation on the web.Config.

The work around (not pretty, but it works) is to set a breakpoint, attach the web server worker process and debug.

Q. When will you have a version that supports Visual Studio 2005 / .NET Framework 2.0?

A: The June 2005 release of Enterprise Library can be made to work with Visual Studio 2005 and .NET Framework 2.0 (see above), but it is not a real ".NET 2.0 release" as it doesn't leverage any of the new platform capabilities or demonstrate best practices.

The patterns & practices team is working on a new release of Enterprise Library that is being redesigned for .NET Framework 2.0. This is scheduled for release as close as possible to the release of Visual Studio 2005. Preview versions will be made available leading up to the release via the Enterprise Library Community site

Q: Why aren't the Enterprise Library assemblies strong named? Should I strong name them? How do I strong name them?

A: Since Enterprise Library ships only as source, it was not feasible to give them strong names. However to get the most flexibility in deployment (eg to support deployment to the GAC and to support multiple versions) you can strong name the assemblies yourself. In a large organization it is recommended that a single group maintains and signs the assemblies to ensure consistency across the organization. To strong name the assemblies, either modify the assembly: AssemblyKeyFile("") attribute in each AssemblyInfo.cs file to reference your own key, or delete these attributes from each AssemblyInfo.cs file and add it once to GlobalAssemblyInfo.cs (you must use an absolute path or key container if you take this approach, since the projects need different relative paths due to the solution structure).

Configuration Application Block

Q: How do I use a block without a configuration file?

A: You can programmatically create configuration using the desired block's configuration data classes, the ConfigurationDictionary and ConfigurationContext classes. Here is an example of how to do this using the Data Access Application Block:

(Taken from http://spaces.msn.com/members/yangcao88/Blog/cns!1ppRXnKxUiSr5Bh0faV-l1PQ!107.entry)

		 [DatabaseSettings] settings = new [DatabaseSettings();]
		 // This maps to <databaseType> element in data config file
		 [DatabaseTypeData] type = new DatabaseTypeData("Sql Server", "Microsoft.Practices.EnterpriseLibrary.Data.Sql.SqlDatabase, [Microsoft.Practices.EnterpriseLibrary.Data,] Version=1.0.0.0, Culture=neutral, PublicKeyToken=null");
		 [settings.DatabaseTypes.Add(type);]
		 // This maps to <connectionString> element in data config file
		 [ConnectionStringData] connectionString = new ConnectionStringData("localhost.EntLibQuickStarts");
		 // Followings map to <parameter> elements in data config file
		 [ParameterData] param = new ParameterData("server", "localhost");
		 connectionString.Parameters.Add(param);
		 param = new ParameterData("database", "EntLibQuickStarts");
		 connectionString.Parameters.Add(param);
		 param = new ParameterData("integrated security", "true");
		 connectionString.Parameters.Add(param);
		 [settings.ConnectionStrings.Add(connectionString);]
		 // Too bad compiler gets confused [InstanceData] with [System.Diagnostics.InstanceData.]  It maps to  <instance> element in data config file
		 [Microsoft.Practices.EnterpriseLibrary.Data.Configuration.InstanceData] instance = new Microsoft.Practices.EnterpriseLibrary.Data.Configuration.InstanceData("localhost", "Sql Server", "localhost.EntLibQuickStarts");
		 settings.Instances.Add(instance);
		 [ConfigurationDictionary] configurations = new [ConfigurationDictionary();]
		 // This is how to tie [DatabaseSettings] with [ConfigurationDictionary.] It maps to <configurationSection   name="dataConfiguration"> element in App.config file
		 configurations.Add("dataConfiguration", settings);
		 [ConfigurationContext] context = [ConfigurationManager.CreateContext(configurations);]
		 Database database = new DatabaseProviderFactory(context).CreateDatabase("localhost");
	

Q: How do I programmatically change existing configuration data?

A: A good way to do this is to ask for the configuration data from the block, change the information and put it into your own ConfigurationContext object and give it off to the block's provider factory. For example, using the Data Access Application Block:

		 [DatabaseConfigurationView] view = new [DatabaseConfigurationView(ConfigurationManager.GetCurrentContext());]
		 [ConnectionStringData] [connectionStringData] = view.GetDatabaseSettings().ConnectionStrings["Sql Connection String"];
		 [connectionStringData.Parameters.Add(new] ParameterData("database", dbname));
		 Database db = [DatabaseFactory.CreateDatabase();]
	

A: The code above doesn't work for me...perhaps it's from an old release? To programmatically change the default connection string in the app config file I have found this to work:

		            string defaultDb = "WhateverYouWant";
		            Configuration config = [ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);]
		            [DatabaseSettings] dbSettings = (DatabaseSettings)config.GetSection("dataConfiguration");
		            if [(dbSettings.DefaultDatabase] != defaultDb)
		            {
		                [dbSettings.DefaultDatabase] = defaultDb;
		                config.Save();
		            }
	

Q: How do I build my own configuration storage providers and transformers?

A: Scott Densmore has put together some tutorials on this topic at his blog

Q: I have built my own plug-ins for a block that implement the required interfaces, but when I try to select it with the Configuration tool I get an error saying it doesn't implement the right interfaces. What is going on?

A: This problem is caused by the configuration tool’s inability to reflect on your type. Although it will try to load whatever assembly you specify via the “Load an assembly” dialog, if that assembly depends on another assembly which isn’t in the GAC or the tool’s probing paths, it won’t find it. So the best solutions are to either install your assemblies and all dependent assemblies into the GAC or to copy any dependent assemblies into the tool’s directory.

Q: Where should I put my application's configuration files?

A: By default, all applications use the AppDomain's configuration file for metaconfiguration. Under most circumstances, this file is:

For web applications and web services, web.config in the root directory of your web site or virtual directory
For Windows applications, appname.exe.config (where appname.exe is your app's executable) in the same directory as the application's executable. When using Visual Studio this will often be a .\bin\debug (C#) or .\bin folder. Visual Studio will also automatically copy any app.config file in your project's directory to appname.exe.config in the output directory
For a DLL, Enterprise Library will still use the config file from the AppDomain it is running in. This will normally be web.config or appname.exe.config.
When using the built-in storage providers, each block's configuration is stored in its own separate file. These files can be anywhere, but the location is referenced in the metaconfiguration file, and is relative to that file's location.

Q: Using Enterprise Library June 2005. Standard SQL connection with integrated security. How do I add my application name to the connection string?

A: Using the Enterprise Library Configuration tool, add a new Connection String Parameter to your connection string. Change the parameter's name to 'Application Name' and the value to whatever you want the application name to be.