Mar 05, 2010 06:30 PM|neothemachine|LINK
You say you don't touch the original web.config "because that has settings specifically for your local development machine". Although it is the right thing not to touch it, I don't think there should be settings for your specific local development machine
in it because in the end the web.config should be under source control and be generic enough for everybody. Maybe it's better if I explain our structure a bit.
We have several developers, say DevA, DevB, DevC. Each of those potentially needs a slightly different web.config file. Then we have a staging server and the live server, each needing its own web.config. Our sourcecode is on SVN, including web.config, web.staging.config
and web.live.config. The difference between the final web.config's is mainly the database connection string but there could be other differences.
The transformation feature as it is now works great for publishing to the staging and live server because it's actually deploying/publishing it using the transformation target.
The problems are the development machines. After thinking about it I'm not sure anymore if my initial feature request is the right thing to do (transformations for local debugging) because that would implicitly say that one file per development machine would
have to be put into source control where it may just not belong in an ideal world because it is too specific.
Currently we are doing it like that: All development machines have the same local settings (database names etc.) which are put into the web.config file. So for local debugging it works just with that web.config without transformations. And for deploying
the other config files are used for transformations as usual. This works for us but it may not work very well for larger projects. I'm not yet sure how the best way to handle it would be but I just wanted to explain the situation so you can think about it
and maybe come up with new ideas.