Have you ever wondered why after adding System.Configuration namespace reference you see a link to System.configuration assembly (note a small ‘c’ instead of the capital one)?

And why calling obsolete functions in order to access your AppSettings through System.Configuration.ConfigurationSettings.AppSettings["myKey"] doesn’t require you adding any additional references, but using System.Configuration.ConfigurationManager.AppSettings["myKey"] requires you going to the project’s Add Reference dialog and adding System.Configuration explicitly?

The reason for that is unfortunately somewhat poor framework design, in particular backward compatibility implementation. In .NET versions starting from 2.0, class System.Configuration.ConfigurationSettings is actually stored in System.dll, and is basically a stub pointing to System.Configuration.ConfigurationManager, which exists in System.configuration.dll (note again small ‘c’).

Here is a good explanation in one of the older blog posts System.configuration.

However, as always the ultimate reference is good ole’ Reflector, which allows you to find exactly where each class is stored, and to peek inside implementation details. Such as delegated calls from deprecated stub class ConfigurationSettings (System.dll) to the new ConfigurationManager (System.configuration.dll).