Develop Reference

How can I validate my web.config before I publish according to the publishing profile?

I have a few different publishing profiles, for publishing to either our test sites or to our live sites. We also have various 'test' versions of our databases for when we're adding new features. At the moment, I manually modify the web.config before publishing depending on where I'm publishing to. It's never happened, but it's conceivable that I could forget and publish to the live site with a connection string to our 'test' database (this would be very bad).
Is there any way that I can run some sort of routine immediately before publishing that just checks the web.config connection string, and if I'm publishing to live and the connection string is not to the live databases, then it'll refuse to publish?
That would give me a lot of peace of mind, that I've made it impossible for me to do something very stupid.

You can setup web.config transformations:
https://msdn.microsoft.com/en-us/library/dd465318(v=vs.100).aspx
When you configure the transformation files, the web.config will be transformed automatically at publish time based on the Solution Configuration chosen for the deployment.
So, for instance, the production connection string from the Web.Release.config would be placed in the resulting web.config which is eventually deployed.

Easiest way to make web.config transforms for deployment?

Anyone have a preferred method for making web.config transforms? I am curious as to what others have done for this. I hate having to continuously update the web.config every time I update or republish.

A few years ago Scott Hanselman gave a solution using pre-build events and batch files:
http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx
Basically you maintain a separate different configuration for each build and run the batch script pre-build to copy over the Web.Config. The obvious disadvantage is that if you have thirty different build configurations you need thirty different configs, but I find it's nice for projects where you only have two or three configs (like hobby projects, or tools you'll only ever be publishing to internal servers). Plus, it's nice knowing that if you want to you can take extra control of the build process if you want to.

The easiest way to use VS built in support:
You have versions of web.config, for your build versions, (by default Debug and Release)
In the release version you can define transforms what are applied during build. The effective web.config will be the result.

Look into the nuget package for slow cheetah: https://www.nuget.org/packages/SlowCheetah/ This does what you are looking for quite nicely. Be aware that it is for publish transformations only, switching to a different config for local debugging will have no affect.

Create a build configuration for each server you want to deploy to
Example
-Dev Server "copy from debug"-
-Prod Server Debug "copy from debug"-
-Prod Server Release "copy from release"-
Then right click your web.config and select "add config transforms"
You will get new transforms for each configuration you added above.
Now configure your web config transforms for each environment.
Now when you publish you can just select the configuration "Dev, Prod Debug, or Prod Release" and out it goes, no need to update them after that.
Now, the base web.config should always be configured for your local environment, so if you set up in IIS locally it will use web.config without any transforms. Your transforms should transform your local settings in the base web.config to w/e they need to be.

Multiple copy of IIS Site, Databases and Windows services

I have a Big Application build in asp.net 4.5.1 Web form. The Application has two Windows Services. This is a product that we host for different vendors. The client Requirement is to have Separate URL, Database and separate Services. we are getting vendors rapidly, now this became a big problem for me, to update, each url separately, to trace any db changes across the database and implement that separately, and to create separate windows service applications for each vendor and to install that separately on the server. Although I have put code in class libraries so that is shared among all the web and the Windows Service application. but there are other settings, like encryption key, the connection strings to each database, the email settings etc.
can someone please guide me how can I manage multiple copy of same application when there are Windows Service applications too.
Thanks in Advance

I am doing similar things by using different build configurations for that.
Create a new build (solution) configuration for each customer. Right click solution and select 'Configuration Manager'.
Add new configuration with customer name and select to copy settings preferably from Release config.
Once you've done that you are able to switch between those configs next to the debug button in VS.
Go to your web project, right click your Web.config file and select 'Add config Transform'
New config files are created (Web.[ConfigName].config) and placed as sub node under the Web.config file.
These new files are used to transform the original Web.config depending on the selected solution configuration. There's some information in the transform file on how to use it, it is not difficult.
If you would go for automated build process later on, the solution config is the key for that as well. Also if you define publish templates (e.g. to create web deploy packages), you are able to select the config. The transformed web.config is then automatically put into the package.

How I prevent to get latest or check-in a specific file automatically in Team Foundation Server?

I work on a team that works on a project. I change my project web config file to set a specific connection string but when I check-in or get latest version of project it changes to others connection strings. I have same problem in WCF Service references. appconfig and xsd files of service references always corrupted when I check-in or get latest version of program from tfs and I have to delete service references and add it again! How can I get rid of this?

We had the same issue on our project (with connection strings), and found a good solution: http://msdn.microsoft.com/en-us/library/ms254494(v=vs.110).aspx
By adding a connections.config file for each developer with his own connection string, we just needed to say that this file must not be a part of Source Control. Then in the web.config connectionString section, you just refer to the connections.config file.
Just be aware that you need to either transform your web.config or add the connections.config when publishing the site.
I know you can do the same about the appSettings section in the web.config.
How you do it with WCF, I don't know - but it sounds strange to me that your are not using the same WCF refence.

There are many solutions.
The team uses the same configuration (e.g. everyone uses localhost references)
You separate user from application settings (do not apply to all kind of settings nor projects)
Use transforms and solution configuration to map have per-environment setting
Use configSource to move config section in separate files that are not under version control
I do not think there is a perfect solution, but maybe you apply a mix of these. I strongly suggest to apply them in the stated order.

settings.settings connectionstring in development vs production

I'm using Visual Studio 2008, developing a winforms app.
I have my database connection string stored in settings.settings.
My development and production environments require different database login credentials and right now I'm manually changing the connectionstring by hand before building for the 2 different environments.
Is there a better solution?

An eternal problem! :-)
Basically, right now, Microsoft doesn't really have a good answer for this.
What I would do is have both connection strings in my settings file, under two separate names, and then have a config setting in app.config which tells me which one to use:
MyDatabaseDEV = server=(local);database=mydatabase;-........
MyDatabasePROD = server=ProdServer;database=MyDatabase;........
and in app.config
<appSettings>
<add key="UseDatabase" value="MyDatabaseDEV" />
</appSettings>
This setting in app.config can be tweaked in your build process, e.g. by a "after build" batch file, or an MSBuild task or something, to be switched to "MyDAtabasePROD", when you do a production (release) build.
Microsoft promises us more and more flexible tools for .NET 4.0 / Visual Studio 2010, which should be out by the end of the year 2009. You should be able to create "config transformations" - check out these blog posts:
Web Deployment: Web.Config Transformation
ASP.NET 4.0 and Visual Studio 2010 Web Development Beta 1 Overview
Visual Studio 2010: Web.config transforms
Web.config Transformations with Visual Studio 2010
Marc

Where I work this is done by creating a folder called config that holds the various configurations.
source
config
MyProject
environment1
environment2
MyProject2
environment1
environment2
When the build script is run, it grabs the correct config based on which environment you're doing the build for...

you can make form asking the user to enter the connection parameters such as server name and database..., and store those parameters in Registry, files etc...

You should add an app.config file to your winform application. In this file store the connection string under the ConnectionStrings section.
In your code, when create a connection use that connection string using ConfigurationManager class to access config file.
So when you deploy your application, you have to chance the connection string once in config file and everything runs as expected!

You can defines your connections in settings, use dev connection in debug mode else production connection with #if directive.
//affect your prod connection here
#if DEBUG
//re affect your dev connection here;
#endif
A link to explain : http://msdn.microsoft.com/fr-fr/library/4y6tbswk.aspx

Right-click on the web site in the Solution Explorer and select Add Web Deployment Project.
Whenever this new WDP project is built, it will replace all the configuration elements you specify. You can also have different versions depending on Debug or Release builds. It works for almost all of the configuration options, including the connection string. There's lots of documentation on how to configure it correctly on the net, just search for "Web Deployment Project".
This is definitely the new "default" way to do this until MS decides to make it more formal in some future version of .Net/Visual Studio, if they ever do.

I've started using a setting called TestMode="dev|prod|uat".
The problem with compilation targets is that you can't change anything after build.
With this approach you can include all the connection strings and settings you need for all the environments you want. In your code configuration provider you can switch based on this setting.
With this approach all you have to do is change the flag once deployed or use deployment software like Octopus to change it for you.
I have given up with merging .config files which is difficult and error prone.