TFS: Ignore certain file from pending changes

Question

Hi all,

Here is my problem. I have a certain files from the solution (let's say Web.config) that I've changed and will never want to check-in since the changes are referring to my machine only. Is there a way to say in TFS to ignore changes in a certain file and remove it from pending changes window. Of course, I can skip this file in every check-in, but there is always a change to forget and check-in by mistake. For example, there is a similar ignore list in AnkhSVN.

I would appreciate also any extension that would give me this behavior.

Thanks in advance

Answer 1

There is nothing for ignore, but the best thing is, after checkin, you can use web based login or some different machine where you have not mapped your source code tree, and you can delete the unwanted files from your source code tree and visual studio will not checkin those files next time you modify them.

You can also put file in folder and modify your project file in xml editor to include your file in your project, visual studio will not add files to source code control that were added manually by editing xml of project file.

Answer 2

For our work in VS 2005/2008 we have multiple checkout turned on, and we just never check in the web.config.

For the hassle of trying to do funky things to not have something checked in, we just never check it in. In the odd case that one of those files is checked in, well it's a quick "Hey guys I screwed up".

On the other hand, you can tell TFS to exclude a file from source control. This will will need to exist on all computers because solutions / projects will still look for that file.

http://arcware.net/how-to-exclude-files-from-tfs-source-control/

You can also modify the .SLN / project file. I have done this method with testing projects where I don't want to have to fix other peoples tests just to run my own, so I removed my testing project from TFS, while keeping others intact.

Answer 3

Which version of studio are you using?

If you are on 2010, then you can use web config transformations. That way you can have different web.config files depending on the environment. For example, development, testing, production..

If you are on 2008, we usually had a main web.config file pointing to our development stuff and a web.production.config file pointing to production. During deploy we delete the web.config and rename web.production.config.

Answer 4

The best practice concerning configuration files, TFS and different developper machines is (hem hem)...

All your developpers should have the same dev environnment. It's the only way to manage web.config files in TFS, and it has a lot of added benefits:

• Nomore "but it work on my computer"

• its friend the dreaded "I don't understand what dependencies are required. It doesn't compile anymore."

• You won't regret the famous "Ah! I forgot to tell you, I invented a MyWonderfullApplicationConfigSection and you should define it in your web.config, but I won't tell you how."

• It will really help setting up a build environnement or a depployment.

Ok, it isn't really easy, I know that different developpers like different settings... but it's a good idea to standardize the dev platform. It's really worth it.

Answer 5

One workaround could be to remove the readonly attribute on the web.config in the windows explorer then edit it in notepad:

• It won't appear in the pending changes
• It's still in the source control

Ugly but simple solution.

Answer 6

Some parts of {app,web}.config files can be delegated to another file. Notably <connectionStrings>.

In your app.config or web.config:

<connectionStrings configSource="LocalConnectionStrings.config" />

in LocalConnectionStrings.config have (<connectionStrings> is the root element):

<connectionStrings>
    <!-- For the application's operations. -->
    <add name="Application"
         connectionString="Data Source=server;Initial Catalog=database;Integrated Security=True;Network Library=dbmssocn"
         providerName="System.Data.SqlClient" />
</connectionStrings>

Thus each developer has a LocalConnectionStrings.config which is in the project, but not in source control set with their private settings while the {web,app}.config has shared settings. Unfortunately this only works with a limited set of system defined configuration elements.