Connection String in Unit Test App.Config is ignored: SQLExpress gets set to LocalDB

c# entity-framework-6 unit-testing


I have a load of unit tests that were running fine in Visual Studio 2013. I dont know if it is related, but I can't think of what else might have changed. I have moved my project to VS2015.

Now whenever I run my unit tests, all the tests that use a data context fail with an error indicating they are trying to use (localdb)\V11.0 and integrated security to access the database.

However, my development database is on .\sqlexpress and has a SQL login.

I've been through every config file, including the app.config in the unit test project, and they all specify the correct database. If I debug step through the code I can reach the line where the data context is created and inspect its properties and see the connection string is wrong, but I can't see where it is coming from.

Here's the relevant bit of my test project's app.config file:

<?xml version="1.0" encoding="utf-8"?>
    <!-- For more information on Entity Framework configuration, visit -->
    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
    <add name="speedEntitiesDev" connectionString="metadata=res://*/mydb.csdl|res://*/mydb.ssdl|res://*/mydb.msl;provider=System.Data.SqlClient;provider connection string=&quot;Server=.\sqlexpress;Database=thedatabase;User ID=theuser;Password=thepassword;Connection Timeout=30;MultipleActiveResultSets=True&quot;" providerName="System.Data.EntityClient" />
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework">
        <parameter value="Server=.\sqlexpress;Database=thedatabase;User ID=theuser;Password=thepassword;Connection Timeout=30;MultipleActiveResultSets=True" />
      <provider invariantName="System.Data.SqlClient" type="System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer" />

When I step into the unit test this is what the property inspector says is the value of the connection string is:

"Data Source=(localdb)\\v11.0;Initial Catalog=thedatabase;Integrated Security=True"

Note that the database name is correct, but everything else is wrong.

I did previously have a database hosted locally in localdb but after upgrading my development computer I stopped using it.

UPDATE: I've discovered that if I rename the connection in the above file, then this breaks the test in a different way. Then I get an error that the connection string is not found:

System.InvalidOperationException: No connection string named 'speedEntitiesDev' could be found in the application config file..

Other changes to the connection string also have an effect (like if I change the database name, the connection goes to the new database name, and uses the login and password I supply.)

System.Data.Entity.Core.EntityException: The underlying provider failed on Open. ---> System.Data.SqlClient.SqlException: Cannot open database "thedatabase123" requested by the login. The login failed. Login failed for user 'theuser'..

When I set the connection string back to "thedatabase" it resets to using localdb and integrated security. It's like it's got an alias going or something.

10/28/2015 11:40:26 AM

Accepted Answer

After diving through the code for a few days, I noticed that in one older library referenced by every class tested by every failing test, there was a data update written as:


and it hit me, this class was using LINQ to Sql instead of Entity Framework. Somehow the class using LINQ to Sql was altering the connection string and defaulting to (localdb) which was what we were using when that library was written.

I changed the class to use Entity Framework instead and suddenly all my tests started respecting the connection string again.

This was weird because

  1. The old referenced library didn't actually do any data updates any more (the data update code in it was legacy and long since placed elsewhere)
  2. The old library didn't even have a valid reference to the data class that supplied its connection string
  3. Despite this, just referencing the old library via the unit tests caused connection string weirdness.
10/29/2015 12:35:53 AM

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow