So this isn't the most ideal way of setting up the config files but it works. See Managing App.Config Data
for what I think should happen with the app.config data.
What To Add/Change
Change C:\Dev to whatever your root development directory is. If a directory is not specified DBUpdater will use this as the base directory start searching through for change scripts.
<add key="DevelopmentDirectory" value="C:\Dev" />
For each database you need to add a DatabaseInstance for each BuildEnvironment
. The example in the section below is setup for one database and two environments, Dev and UAT.
Where To Add
Under 'Solution Items' (in Solution explorer) there is file named 'App.config'. Make changes to this file, changes here get 'pulled' into the target directory as a post build event. See Managing App.Config Data
for why it isn't simply in the same directory as the project file.
How Does It Get Connection Details from App.Config?
DBUpdater uses the DAB from the enterprise library. The way it uses it is this, it combines the database name with the environment name to makup the DatabaseInstance name.
In this example:-
<add name="DBUpdaterTestDevelopment" connectionString="Database=DBUpdaterTest;Server=.;Integrated Security=SSPI;"
<add name="DBUpdaterTestUAT" connectionString="Database=DBUpdaterTest;Server=UATServer;Integrated Security=SSPI;"
DBUpdateTest - is the Database Instance Name Prefix.
Development - is the environment
Where does it get the values for the database name and environment from?
The Database Instance Name Prefix it gets from a file called 'DatabaseInstanceNamePrefix.txt', which is in the SQL directory (see ProjectSetup
The 'environment' name it gets from the build.environment file (see BuildEnvironment
The .Tests project has it's own App.Config and shouldn't require any changes unless you need to explicitly name the server (config file just has a '.' for the server name.)