At work we’ve just spent a few hours tracking an error in a click-once application. This is what it looked like:
EventType clr20r3, P1 formeladmin.exe, P2 220.127.116.11, P3 4af94120, P4 system.data, P5 18.104.22.168, P6 4889deaf, P7 2753, P8 29, P9 system.data.sqlclient.sql, P10 NIL.
The app worked on the dev machine, but when installed to a user machine (and som VM’s) it failed miserably. It is a rather cryptic message, and not until we moved the the whole thing to another dev machine and could attach a debugger did we track it down
What the error message meant was actually: “You have an unhandled error in your connection-string”. What further hid the problem from view was the fact that one DLL had an app.config file all of its own – which must really be regarded from now on as a no-no. The problem with the connection string was, that the dev machine had a special host-table entry for the SQL-server used – all done automatically by Linq2Sql.
What we then did was to move all configuration-strings to the topmost exe-file’s app.config and to ensure that all server references would be globally accessible from everyones machine.
I’m still pondering whether to always programmatically feed the connection-strings into datacontexts – leaving one ring to bind them all so to speak, ie only one connectionstring for each possible database connection which is then specifically fed into the Linq2Sql datacontexts. This goes hand in hand with my previous postings about maintaining configurations more on an application meta-level than on an individual exe-level. But then again, maybe I should look into more of the machine.config concept, except it looks to me that this wasn’t really meant for the application developer to tweak?