Replacing .ini files used for Access applications which I migrate to .Net C#


I have a number of Access VBA apps to migrate to C#. My Access apps have to be able without software changes to access data either in a prod environment or in a test environment, both being on separate SQL Server DBs on separate Windows servers. To achieve that I use an .ini (text) file which they look for when they are starting and which tell them which DB to access (the ini file contains entries for DB type, name, server and DSN name). Currently I have one central ini file for each environment, and I use 2 sets of shared network directories, one for prod, one for test, with the ini files in the corresponding root directories of each environment. So the apps look for the ini file first in their own directory, and if finding none, go up the directory tree until they find the central ini file, read it, and relink all their tables to the appropriate DB.

What would be the recommended way to achieve a similar result with C# apps ? I've heard about config files but know nothing about them, really. WHat I want to avoid is to have to duplicate the apps.

Thanks for your input
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Kyle AbrahamsSenior .Net DeveloperCommented:
The config file is the new ini file.

For windows applications, just add a configuration file called App.Config

When it's compiled, the app.config turns into


which can then be read by the Application.

More on how to read from the application config can be found here:
Jacques Bourgeois (James Burger)PresidentCommented:
Kyle is right, but the easiest way to learn how to use the configuration file is the official documentation on the MSDN site.
Éric MoreauSenior .Net ConsultantCommented:
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

bthouinAuthor Commented:
HI guys

Thanks for your posts, now I now everything I need to know about config files.

However, they don't really solve my problem:
- ideally, I don't want a config per app, I want one for a group of apps which all reside in subdirectories of a given root directory. I have one root dir for prod and one for test, and all apps are in various subdirectories ot the corresponding root dir. In other words I have the same app always twice, once in a subdir of the prod root dir, one in a subdir of the test root dir. All the apps under one root dir should connect to the same prod SQL Server DB on the same remote server. Therefore I need only one config for prod apps and one config for test apps
- I don't like at all the idea that a config file (which can be open with Notepad or IE) is going to lay open to look into for any curious user (and, who knows, potential hackers), outlining nicely on which server the DB is and which name the DB has. God knows what users are capable of, not to talk about hackers...
- the last thing I want is that my users could decide which DB to use (as suggested in Eric's article). That must in any case remain hidden to them

Is there no way to have such a config file at another location than where the executable is, i.e. can one "tweak" the code reading the config to use another source diretory for the config file and another, generic, file name ? Or do I have to do that all myself by creating an xml config file myself and writing the code to read it at a given "logical" location on the file system (as I do currently in Access) ?
bthouinAuthor Commented:
Well, it seems I found somebody who has had exactly the same idea as me. Googling the problem, I found a C# project on the Code Project site, called Configurator, which covers EXACTLY what I need, and not only that, but it can even convert my existing ini filse into XML config files...

So I'd say, problem pretty much solved !
Jacques Bourgeois (James Burger)PresidentCommented:
Since all your applications are working with the same DB, why not have a table in that DB to store your configuration.
Kyle AbrahamsSenior .Net DeveloperCommented:
He would still want some kind of configuration to point between them.  Can you point a link to the project?

Also XML is still clear text so it won't keep it from "prying eyes".  The best way to do that would be to write some kind of utility that uses a symmetric encryption key, and then you can write values out to the config and read them in.

Just my 2 cents.
bthouinAuthor Commented:
@James: this would be a catch22 situation. By definition I cannot have the app to access the DB to find out which DB to connect to...

My 10+ user applications have each to know if they should connect to the Prod or the Test DB. This depends actually on where an app is stored. If it is stored in a subdirectory belonging to the Prod directory tree, then it should connect to the prod DB. That's why I was looking for a mechanism for the apps to look into a file on the file system that will tell them to which DB to connect.

@Kyle: yes, you're right, but that's a bit overkill, as now the config file will not be where the apps are but in a different (parent) directory at least 2 levels up from the apps themselves. That should be sufficient hiding. If not, I have done symmetrical encryption before in my career, so I could absolutely do what you suggest. Thanks.
Jacques Bourgeois (James Burger)PresidentCommented:
If all you need is the database to connect to, a simple text or binary file on the network can do the trick. It does not have to be a .config file. Encrypt it if you need to.

Depending on how you decide to distribute your updates, the databases location can also be hidden in the application itself. A ClickOnce distribution for instance makes it a snap to recompile and redistribute the application with a new value for the constants it contain.
Kyle AbrahamsSenior .Net DeveloperCommented:
I would not trust that the config file being in a different directory (especially if it's in a sibling) being "secure enough".  Anything that can go wrong will go wrong.  A user still might be able to find it, and as a developer that case should be handled.  

If you're launching from a network path . . . you could store all additional settings in the database.  If the DB or paths ever changed, simply update it here, recompile and you're good to go.  

Set the connection string (hardcoded on load).

Something like:

string connStr;

if (inProdPath())
   connStr = "..."; // prod conn str hardcoded
   connStr = "---"; // test conn str  hardcoded


Open in new window

Again, just my 2 cents, and trying to help you achieve your goal.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Access

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.