VB.Net Application config file 2

[mcauliff]

I have research the app config file for VB.Net. I understand how to code the parameters. What I didn't see is how it works when the program is moved between environment.

The coding environment is VS 2005 with SQL Server 2005. There is a Dev, QA, and Production environment.

My questions;

When I code the app config setting for the Dev environment and then move the program to QA, does the app config from the Dev environmnet move also?

If it does, then it would need to be edited in the QA environment to use the QA databases, etc

This would alos be true for production.

After the initial installation, does the app config file need to be moved again?

 

[Gnism]

Hi mcauliff,
In our experience we use a different config file in four environments: Prod, Stage, Test, and Dev...Each environment has an app config file that points to proper the Data Source. It's fairly straight forward in our setup since the databases are named the same throughout each server.

 

[mcauliff]

Gnism

I'm new to Vb.Net and config files. In my environment the databases name are the same, server names are different and there is a .csv file. The .csv file will be in a folder on the database server.

Is the app.config file separate from the program? When I open the project, I have a app.config file listed in the Solution Explorer. Is this the one I use or do I create a seperate file?

Thank you for your assistance

 

[RiverGuy]

I've always distributed the same app.config I developed with. There is no need to create a brand new one. You can either set it to point to production before you distribute the app, or allow the IT tech or user to change the values upon installation.

Some applications will allow the user to switch between prod and test at any time. In that case, you'd probably want to distribute your app with the config file pointed to test. You might have a menu option to allow the user to edit the app.config values from within your application.

If the application is not really designed to allow the users to switch to test whenever they feel like it, then you can probably get away with pointing the config to prod before you distribute the app. Then, for any UAT, you can manually edit the app.config with a text editor.

 

[Gnism]

Yes, that would be the file you have to configure...I guess it was a little misleading to say that we have a different file for each environment - it is essentially the same expect that we do change the values during installation depending prod/test etc. as RiverGuy points out.

 

[mcauliff]

I noticed that I didn't mention that this has no UI (User Interface), it is a Console Application that executes once per day to update information on the database.

I was hoping to write the config and never have to do it again for the 4 environments that we have.

Thanks for the input

 

[RiverGuy]

With a console app, it is also quite common to accept command line arguments to use within the application. For example, SomeProgram.exe "ComputerNameOfProdServer"

 

[Jasen]

I have to deal with the same thing. When developing I point at a dev server, then when I push the app out, I change that line in the app.config to point at the server for whichever site I'm pushing down to.
It's really not a big deal.

How I've found to get away from having to alter this every time is that I'll create an installer package for each site, each one with the appropriate app.config.
When I push out a new version or bugfix to the app, I only push down the executable, not the installer or the config file. My apps all check back to this shared folder at launch to see if a new copy of the executable exists, and if so copies it down to update itself. In this way, once each client has its local app.config, it never gets overwritten, and I don't have to edit it each time I compile and distribute.
I manually copy the files out btw, I don't use the "Publish" feature in VS.