I’ve moved into the C#/.NET world for a bit. I’m working on a project that offers a simplified interface into a system. Part of that system requires providing a filtered view of data from the original database. I’m not doing test-first development. But I am writing unit tests frequently to confirm concepts before completing a module.

Since this is the .NET world, I’m using NUnit as my unit test framework. But I was getting headaches trying to figure out why I couldn’t set up my test system to use a different database than the debug or production systems. I’m trying to keep the database in a known state for testing, meaning that I delete the records and re-add them before running unit tests. I couldn’t get DBUnit, with IKVM to work, as recommended in http://stackoverflow.com/questions/780614/dbunit-net-alternatives. Nor could I get NDBUnit or tdunit, also recommended in the same query to work. In each case, I was apparently connecting to the database. But at the point I tried to read the xml data I’d created, everything seemed to break down. Since the latter two have had no update in about 3 – 4 years, and the IKVM solution combined so many different technologies, I wasn’t sure where to find an answer, I moved back to trying to use LINQ, as we were using in the rest of the project.

But LINQ was giving me headaches, too:

The specified named connection is either not found in the configuration, not intended to be used with the EntityClient Provider, not valid.

I had an app.config file. It contained the correct connection string entry. I even went as far as to copy and past the connection string from our .edmx file, to ensure I had it right. I did find one person who suggested making sure that it was being correctly read by querying the connectionstring(s) and printing them out during debug:

ConnectionStringSettingsCollection settings = ConfigurationManager.ConnectionStrings;
if (settings != null) {
   foreach(ConnectionStringSettings cs in settings) {
      Console.WriteLine(cs.Name);
      Console.WriteLine(cs.ProviderName);
      Console.WriteLine(cs.ConnectionString);
   }
}

Rather than finding my named connection string, I found one named LocalSqlServer. I search all the files in our solution and couldn’t find that anywhere. I then looked in the machine.config and lo and behold! I found it!

So the system wasn’t even reading my app.config file.

As we all know, many times, finding the answer means finding the right set of keywords to search. Hopefully, I’ve filled in enough detail in this article that someone else won’t have that problem. I finally found the right answer when looking for a solution for ‘nunit reading app.config’. Some other poor soul had had the same issue. His solution:

1. Make sure that your .nunit file has the same name as your project. That is, if your project is MyProject, then your .nunit file needs to be called MyProject.nunit.
2. Your configuration file needs to have the same prefix as well. Rather than being called app.config, you need to name it MyProject.config.
3. Both of the aforementioned files need to be in the same directory.

It worked for me. Hopefully, someone else can find this solution as well.

Next problem to solve: dynamic ‘where’ clauses for LINQ.

UPDATE:

I just updated to NUnit 2.6. And, again, the config file wasn’t seen. The new version has an option in the NUnit config file to note what the project config file should be. From the interface, select Project/Edit. In the popup, look for the textfield marked Configuration File Name. In that blank, enter the name of your file only; you can’t enter the full directory structure. NUnit is still expecting the file to be in the same directory as the dll file.