A Big Strike Against TableAdapters

I'm hoping that someone reads this post and corrects me. But I'm not holding out much hope.

I don't normally use TableAdapters, but for a small application I decided that they seem like a reasonable choice. And so long as I was using them on my development platform, all was well and good. The problem arose when I delivered the application.

Like any good developer, I store the connection string to the data store in the configuration file. Which is what I did for this application. When I defined the TableAdapters, I pointed the connection string property to the same setting. Or so I thought. But what actually happened was that the connection string was actually stored in the DLL that contained the adapters. Hard-coded. As in not modifiable through the config files. And, naturally, this wasn't discovered until deployment.

So I started to look for ways to have the TableAdapter pull the connection string from the config files. I figured that this would be a fairly common scenario, so it should be address. Not so much

Apparently there is no way to automatically have TableAdapters use config settings. The "solution" is to use the fact that TableAdapters are partial classes to create a write-only ConnectionString property. It looks like the following:

public partial class FormTableAdapter
{
   public string ConnectionString
      {
         set
         {
            System.Data.SqlClient.SqlConnection conn = new 
               System.Data.SqlClient.SqlConnection();
            conn.ConnectionString = value;
            this.Connection = conn;
         }
      }
   }
}

Then, where the adapter is instantiated in your code, you set the ConnectionString property to the value from the config file.

To me, this is unacceptable. I was already a little skeptical of TableAdapters (I don't like the DataSet and the data access code in the same assembly), but this takes the cake. It almost seems like they were designed to not allow a reasonable deployment model. Maybe it will get better in the next version, but until then, I'm sticking with DataAdapters.