I am working on a project where I have separated the Typed DataSets into a separate Assembly. I nievely made the Typed DataSets use a named Connection String in this assembly. So when I attached to the Database when creating my DataSets, I saw that it was using a Connection String called "MyConnection".
In this assembly, the designer created an app.config and a Settings.setting object. All sounded good. So in my ASP.NET 2.0 project, I setup the connection string in the web.config and called it "MyConnection". This all worked until I deployed it to a server, when all hell broke loose. After deployment, my code that did *not* use Typed DataSets (mostly DataSources) worked fine with my new "MyConnection" connection string...but...
Everywhere I used the Typed DataSets it was failing to connect to the database. When I looked at it it seems that the Typed DataSets were using the connection string I used on my dev box...but no app.config to be seen. How was it getting that bad connection string? Well it seems that the connection string information is being embedded as the "default" connection string to use if it can't find the connection string in the configuration. Ok, this is bad...I'd hate for my assembly to actually have stuff like my password embedded in it, but I doubt that happens. I was using integrated security so I haven't tested the password embedding yet.
But what is strange is the connection string was in the web.config. What gives? Well the Typed DataSet satellite assembly named my connection string with namespace and setting prefixes. "MyConnection" became "MyApp.Properties.Settings.MyConnection" because the serialization of the name includes all of that. Yeech...
For now I added that as a connection string to my web.config and got over my initial issue, but I am still digging to find a better solution. I'll let you know what I find.
