Post date: Mar 29, 2014 7:55:45 PM
A recent ADR deployment was delayed because the ADR PROD site was causing the application pool to stop each time any .as*x pages were called. The root cause of this was ConfigurationEntry rows pertaining to ConfigurationEntry.
When loading a configuration section for an AbstractObject-derived class, QBO 3 essentially calls the following:
ObjectConfiguration.GetSection(className) =>
BaseConfiguration.Load(sectionName) =>
ConfigurationManager.GetSection(sectionName) (which reads the .config file from disk, deserializing into memory) =>
DbConfigurationElementCollection.PostDeserialize() =>
ConfigurationEntryObject.LoadConfiguration(source, type) (which supplements statements, filters, etc.)
If one defines a ConfigurationEntry row for ConfigurationEntry itself, ConfigurationEntryObject.LoadConfiguration winds up creating a new ConfigurationEntry object, which calls ObjectConfiguration.GetSection('ConfigurationEntryObject'), which is a infinite loop.
To avoid such accidental configurations, ConfigurationEntryObject.LoadConfiguration(source, type) has been modified to skip attempting to load custom configuration if source == 'ConfigurationEntry.config'.
This means that custom configuration for ConfigurationEntry must be done from ConfigurationEntry.config, and cannot be data-driven.
Should you encounter a QBO 3 site constantly causing the application pool to crash, check the ConfigurationEntry table for any rows where Source = 'ConfigurationEntry.config' and delete the matching rows:
SELECT * FROM ConfigurationEntry WHERE Source = 'ConfigurationEntry.config'