risu wrote:

Another devolper has gone the route of a local ini file (which my project manager likes). Thus he can siply change the ini file and relaunch the program. Test to production in a heartbeat. He understands that this exposes the DB login information in plain text and wants to write an encryption function to handle this. I think this is the direction we're going to end up going in.


The ini approach is definitely the way to go. It allows the use of multi-environments and customization of authentication, which clients love (keyword "security").  In my shop we use something like this:

[dsn]
dsn1=something

[dsn1]
user=user
pwd=password

The username and password are both encrypted so there isn't the slightest bit of authentication data visible to the user.

As far as API vs Framework, I've stuck with the API method for now.  Some old habits are hard to break and I've grown accustom to using the API for simple methods while other more complex methods I use the Framework.

Something as simple as reading an INI file shouldn't make much difference in performance.  From the API you can only read a 255-character string from each key so you aren't moving much data back and forth.

No if you are looking for consistency through the whole app and want to use only the Framework then I guess you have an argument.  If you really want to confirm to the .Net standard, from what I've read, you wouldn’t use ini files within but xml files or Isolated Storage.