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?
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?
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
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.