In an Asp.Net application, if you check the properties of the various Asp.Net providers at runtime, you will get a value that is something of a hybrid between default and custom settings. Similarly, if you check a property such as ConfigurationManager.ConnectionStrings(“LocalSqlServer”).ConnectionString, you will get a value that may originate in web.config or result from a default setting.
Why is this?
When an Asp.Net 2.0 application is loaded, the attributes (and behavior) of the various Asp.Net providers (membership, roleManager, profile and others) are retrieved from sections in machine.config (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config.) If the web application includes a web.config file, the configuration sections contained therein may supplement or override the default behavior.
So how do you programmatically determine if a provider is getting its configuration from the default (machine.config) file or from an application-specific (web.config) file?
I recently had to deal with this issue in testing for various potential user problems with the Membership Manager Control. I was simulating a fairly common scenario where users might configure their AspNetSqlMembershipProvider to store passwords in an encrypted format but forget to provide a machineKey section. The machineKey section defines how to encrypt/decrypt various types of information and, if not defined in web.config, will produce autogenerated values. Anyone who has tried to go with an encrypted rather than hashed passwordFormat will have undoubtedly encountered the following message when they attempt to run the web application:
You must specify a non-autogenerated machine key to store passwords in the encrypted format. Either specify a different passwordFormat, or change the machineKey configuration to use a non-autogenerated decryption key.
This exception is thrown by the AspNetSQLMembershipProvider to force the web application developer to provide a machineKey section in web.config. This requirement is well documented and several excellent resources are available on the Internet to help you generate the elements needed to create your own custom machineKey configuration section.
So in my situation, I wanted to prevent users from changing an individual member’s passwordFormat to Encrypted if the machineKey was not specified in web.config. I would need a way to determine this at runtime.
Well, it’s easy enough to get a strongly typed MachineKeySection object. The following VB.Net method illustrates how to get an instance of the machineKeySection class for the current web project:
Public Shared Function GetMachineKeySection() As System.Web.Configuration.MachineKeySection
Static section As MachineKeySection
If section Is Nothing Then
section = CType(System.Web.Configuration.WebConfigurationManager.GetSection("system.web/machineKey"), MachineKeySection)
End If
Return section
End Function
(Note that "system.web/machineKey" is case sensitive)
And when you check the resulting instance, you will get information in fields such as decryption, decryptionKey, validation and validationKey – whether or not a machineKey section exists in web.config.
So how can you programmatically tell if machineKey contains a non-autogenerated decryption key?
The ElementInformation class is typically available as a property of sections such as machineKey and can tell you if a particular element is a collection, if it can be modified and even the line number where it is defined in its configuration file. And, of course, Microsoft gives us the IsPresent property which tells us whether or not the element actually exists in the configuration file. ElementInformation.IsPresent returns a Boolean and is easy to use as shown in the VB.Net method listed below.
Public Shared Function HaveMachineKey() As Boolean
Dim section As MachineKeySection = GetMachineKeySection() ' see above
If Not section Is Nothing Then
section.ElementInformation.IsPresent
End If
End Function
The model for strongly typed configuration classes has been around since .Net 1.0 and is available for WinForms as well as WebForms applications. Custom configuration classes are relatively easy to create and provide a big step up from INI files. In the 2.0 .Net Framework, configuration classes are even easier to create and provide lots of great new capabilities. This ability to inherit and override configuration settings does a great job in supporting the provider model and features such as the ElementInformation class give the programmer all the information he/she needs to determine the source of any particular configuration section.