2

We have an Entity framework 4.1 setup, auto generated POCOs and DbContext classes for interaction with the db.

The automatically generated DbContext derived class looks like this:

 public MyEntities()
        : base("name=MyEntities")
    {
    }

And the automatically generated connection string in app.config something like:

<connectionStrings>
    <add name="MyEntities" connectionString="blah blah blah"  providerName="System.Data.EntityClient" />
</connectionStrings>

That's all fine, and works right out of the box.

Each of our developers has their own SQL Developer edition install for unit testing and dev purposes, so they need to modify the connection string to point to their installation when doing unit testing. These connection strings are in the App.config file of the unit test project

This is currently a manual modification step, and I had thought to automate this in some way.

Now, I can go and work out the connection string in code, but passing this into the entity framework constructor is prevented by the default auto-generated "MyEntities" constructor above - it doesn't have a connection string parameter on any constructor. (Although DbContext does). Furthermore, I don't particularly want to plumb the connection string through the DAL code and down into the entity framework code - that isn't needed in production, so that's modifying my code just for the purposes of unit test.

I had thought there must be some way to override the string in App.config. This would be similar to how this can be done with a local Appsettings file. (ie <appSettings file="Local.config"/>), but I can't seem to see how to do this for the ConfigurationManager.ConnectionStrings entries.

So, what does one do here?

Coopernick
  • 229
  • 2
  • 17
  • If every developer has his own SQL server you don't need to change connection string. Simply make convention that everybody must use default instance and that the database has fixed name. – Ladislav Mrnka Jan 31 '12 at 09:41
  • 1
    Sorry, but sometimes we have different SQLs installed on the same machine, people work on a lot of different stuff, we can't guarantee everybody must do that. – Coopernick Feb 06 '12 at 03:04
  • I worked on different stuff of different size and complexity several years and I never needed more than one SQL server instance (except one situation where I specifically needed to test migration between two instances). If I needed to work in isolation I used virtual machine. So it doesn't look like a valid argument. – Ladislav Mrnka Feb 06 '12 at 09:32

2 Answers2

3

If naming convention is not acceptable, you might want to create a SQL Alias on each developper computer to point toward their own SQL Instance. This article : http://www.mssqltips.com/sqlservertip/1620/how-to-setup-and-use-a-sql-server-alias/ provide step by step instructions to create an alias.

2

Thanks, here is what I ended up doing, inspired by:

Because this is only for DAL unit tests, and not production, I modify the connection string on the fly, based on a users environment variable.

I would never advise this for production, you should be using appropriate transforms, etc.

So for unit test I have "data source=ENVVARTOSQLSERVER" defined in the app.configs.

Then a fn in the unit test to modify the config, save it, and reload it at startup.

    private static void ModifyUnitTestConnectionString()
    {
        // Note that the updated .NET 2.0 and later "ConfigurationManager.ConnectionStrings"
        // cannot be used to modify or add connection strings, as it is read only.
        // However, accessing the same settings via the configurationSection directly
        // is not read only.

        // Get current configuration.
        Configuration currentconfiguration = 
            ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);

        // Get the connection strings section
        ConnectionStringsSection currentConnectionStringsSection = 
            currentconfiguration.ConnectionStrings;

        // Read the "SiteEntities" connection string.
        string ntCNStr = 
            ConfigurationManager.ConnectionStrings["MyEntities"].ConnectionString;

        // Replace any instances of "ENVVARTOSQLSERVER" in that connection string
        // with the appropriate environment variable.
        EntCNStr = EntCNStr.Replace("ENVVARTOSQLSERVER",
                                            Environment.GetEnvironmentVariable("ENVVARTOSQLSERVER"));

        // Write the connection string and save the changed config file.
        currentconfiguration.ConnectionStrings
                            .ConnectionStrings["MyEntities"].ConnectionString = siteEntCNStr;
        currentconfiguration.Save(ConfigurationSaveMode.Minimal);

        // This is this needed to refresh the configuration manager and get it to
        // read the config file again.
        ConfigurationManager.RefreshSection("connectionStrings");
    }

So, that's it. Devs need to set an environment variable so that the appropriate source path to their SQL is in place.

Community
  • 1
  • 1
Coopernick
  • 229
  • 2
  • 17