Mercurial .hgignore for Visual Studio 2010 projects

Question

Not to be confused with Mercurial .hgignore for Visual Studio 2008 projects

I was asking whether if that same file can be reused for Visual Studio 2010, or some other extensions, etc should be added to it, & why?

Cordey

Answer 1

The new things are related to MSTest stuff. This is the one that I use:

# use glob syntax
syntax: glob

*.obj
*.pdb
*.user
*.aps
*.pch
*.vspscc
*.vssscc
*_i.c
*_p.c
*.ncb
*.suo
*.tlb
*.tlh
*.bak
*.[Cc]ache
*.ilk
*.log
*.lib
*.sbr
*.scc
*.DotSettings
[Bb]in
[Dd]ebug*/**
obj/
[Rr]elease*/**
_ReSharper*/**
NDependOut/**
packages/**
[Tt]humbs.db
[Tt]est[Rr]esult*
[Bb]uild[Ll]og.*
*.[Pp]ublish.xml
*.resharper
*.ncrunch*
*.ndproj

Archoplasm

@David: That's for Windows thumbnail cache files "thumbs.db" read more about it here: en.wikipedia.org/wiki/Windows_thumbnail_cache – Cordey

@Shady. I know, shouldn't thumbnail caches be ignored, too? – Eupatorium

Ah.. sorry thought you were asking about an entry that's already there.. Feel free to edit the list and yes I totally agree, it should be added – Cordey

I had to change [Dd]ebug*/ to [Dd]ebug*/** to get Mercurial to not ignore files starting with Debug*. Same for the other directories too. – Fibroid

@Fibroid I confirmed and agreed with your change. I edited the question, awaiting peer review for it. – Pyelography

And what about adding "packages". So that when using NuGet package restore, NuGet packages are not added to source control – Mollee

At the time of the posting NuGet was not yet widely in use. Feel free to add to the list whatever makes sense to you. – Archoplasm

Probably should add *.publishsettings as well: twitter.com/shanselman/status/294541436236480512 – Inkblot

Answer 2

I feel that it is important to know every piece of information about my repositories, so I never copy and paste the .hgignore file from one repo to the next, instead I always build them as I go.

This is easy with TortoiseHg, as the Commit window will list all untracked files, and a simple right-click will allow me to add patterns to ignore those files. This way I always discover new files that I may or may not want to keep.

For instance, in the list published by Thomas, *.resharper is the last entry. This will prevent sharing the resharper settings per solution, as one of the options in the config dialog for ReSharper can be set to. In other words, if you want to ensure that all the developers are running with the same settings for a lot of the things ReSharper will help you with, that particular line can't be there.

So my advice is this: Do it manually, you'll learn a thing or two about your project in the process.

Tiddly

I really appreciate your advice, actually that's partially what I do, but needed to check what other people usually do just to have some ground to start from.. Concerning the *.resharper it's a team thing.. some teams prefer to have separate settings for it rather than sharing forcing them same settings across the whole team.. but I got your point.. thanks again :) – Cordey