CODEWITHSUNDEEP
asp.netdeployment
tishma
tishma

Reputation: 1885

How to separate configurations in ASP.NET?

My team is doing web development (ASP.NET, WCF), and we are at a beginning stage where everyone needs to make DB changes and use own sample data.

We use a dedicated DB server, and we want each developer to develop against separate DB.

What we appear to need is ability to configure connection string on per-developer basis in source controlled way. Obviously, we might have other configuration settings that need custom setting and finally, we'll need to maintain a set of configuration settings that are common to all developers.

Can anyone suggest a best practice here?

PS Similar issue appears when we want to deploy a built application to different environments (test, stage, production) without having to manually tweak configurations (except perhaps configuring the environment name).

Upvotes: 0

Views: 133

Answers (2)

tishma
tishma

Reputation: 1885

OK.

Maybe not so elegant solution, but we've chosen to read connection string from a different place when the project is built using Debug configuration.

We are using registry, and it has to be maintained manually.

It requires some extra coding, but the code to read the registry is only compiled in debug (#if debug), so there is no performance hit in production.

Hope this helps as well.

Cheers

v.

Upvotes: 0

SouthShoreAK
SouthShoreAK

Reputation: 4296

You can use config transforms for your deployment to different environments. That's easy enough. Scott Hanselman did a pretty awesome video on it here.

For your individual developer db problem, there isn't any particularly elegant solution I can think of. Letting each developer have a unique configuration isn't really a "best practice" to begin with. Once everyone starts integrating their code, you could have a very ugly situation on your hands if everyone wrote their code against a unique db and configuration set. It almost guarantees that code won't perform the same way for two developers.

Here is what I would recommend, and have done in the past.

  1. Create a basic framework for your database, on one database on your test db server.
  2. Create a Database Project as part of your solution.
  3. Use .Net's built in Schema Compare to write your existing database to the database project.
  4. When someone needs to change the database, first, they should get latest on the Database project, then make their changes, and then repeat step 4 to add their changes to the project.
  5. Using this method, it is also very easy for developers to deploy a local instance of the database that matches the "main" database, make changes, and write those changes back to the project.

Upvotes: 2

Related Questions