Why did my Visual Studio 10 stop using App.Config

I have a working database application using WPF and SQL Server 2008 R2, which for two years has been getting its SQL Server connection string from the App.Config file. A few days ago on one dev machine, it started ignoring the App.Config file's connectionString, and is now using a string from somewhere else (looks like either settings.settings, or the DBML file).

Why might this be happening, and how can I get it to stop doing that?

The app.config starts out like this:

<configuration>
  <configSections>
    <section name="log4net" type="System.Configuration.IgnoreSectionHandler"/>
  </configSections>
  <connectionStrings>
    <add name="DronzApp.Properties.Settings.DronzAppConnectionString"
     connectionString="Server=dronz.db.123.dronzdbserver.com;Database=dronzdb;User ID=dronz;Password=secretsauce;"
     providerName="System.Data.SqlClient" />
 </connectionStrings>

Edit: Thanks for the suggestions from both of you for more info and where to look. I don't know where a WPF App gets the information that it ought to look in App.Config, or anyplace else, but until I learn that, here are some more pieces:

One of the first things my program does is test the database (which now fails). Right before it does that, it calls the auto-generated function InitializeComponent(), whose auto-generated code is:

        /// <summary>
    /// InitializeComponent
    /// </summary>
    [System.Diagnostics.DebuggerNonUserCodeAttribute()]
    public void InitializeComponent() {
        if (_contentLoaded) {
            return;
        }
        _contentLoaded = true;
        System.Uri resourceLocater = new System.Uri("/DronzApp;component/ui/startwindow.xaml", System.UriKind.Relative);

        #line 1 "..\..\..\UI\StartWindow.xaml"
        System.Windows.Application.LoadComponent(this, resourceLocater);

        #line default
        #line hidden
    }

My start window constructor calls InitializeComponent(); and then tests the database with the line:

int hmm = App.db.Dronz_FooTable.Count();

where App.db is a data context defined in the app.xaml.cs file as:

public static DronzDataDataContext db = new DronzDataDataContext();

where DronzDataDataContext is defined in auto-generated code by LINQ-to-SQL such as:

public partial class DronzDataDataContext : System.Data.Linq.DataContext ...

    public DronzDataDataContext() : 
            base(global::DronzApp.Properties.Settings.Default.DronzConnectionString, mappingSource)
    {
        OnCreated();
    }

Which used to heed the app.config file, and now doesn't. When I catch the DB exception (which is about a DB version problem because it is trying to use the wrong SQL server) and look at the connection string, it is asking the wrong SQL Server for a file instead of the correct connection string. The connection string it is using seems to match either the DBML file that Linq-to=SQL created when the database schema was imported, or a string in settings.settings (which is a file I don't really understand where it came from or what I'm supposed to do or not do with it).

Ok, I seem to have found and fixed the problem, but I don't know what caused it, exactly.

What references the Config file is actually in the .proj file, and somehow it changed to add a reference to app.config at the project root instead of in an App subfolder. From reading other discussion of app.config, I think VS2010 did this automatically perhaps when I was looking at the Project settings in the GUI. Deleting that line of XML manually from the .proj file allowed it to find and use the previous version which points to where the app.config file actually is. Since I didn't have an app.config file in the project root where the new first line was edited to say it was in the .proj file, it seems to have fallen to looking at settings.settings, where it found the connectionString value where the file was when I imported the database file using Linq to SQL.