Should I add .vcxproj.filter files to source control?
Solution 1
Previous versions of Visual Studio (at least versions 6.0 and 2008) store that information in their own project file (.dsp and .vcproj files respectively), which of course is good to add to SCC.
I cannot think of any reason to not include this .filter files in SCC
Solution 2
We intentionally pulled the .filter. file information out of the .vcproj when we translated to the .vcxproj MSBuild format. One reason is exactly what you pointed out, that the filters are purely a logical view, and different team members may want different views. The other is that sometimes the build is set up to check the timestamp of the project file, and trigger a rebuild if it has changed - because that may mean there are different source files to build, or different settings, etc. I don't recall if we actually shipped with the build trigging that way, but the idea was that we did not want to trigger a rebuild simply because the filters changed, as they don't affect the build.
Solution 3
I just found that if you use Git you can mark .filter files to be treated as a union for merging to make it simpler. Just add the line:
*.vcxproj.filters merge=union
to your .gitattributes file.
See Using .gitattributes to avoid merge conflicts for more details.
Solution 4
It should not be added in case you use CMake
(or similar build tools) to generate files like *.sln
, *.vcxproj
, *.vcxproj.filters
etc., because this files may contain full path to your Project Folder and other only your computer's specific folders.
Related videos on Youtube
![jschroedl](https://i.stack.imgur.com/FCMFo.jpg?s=256&g=1)
jschroedl
I am a long-time professional Windows developer. I've done a lot of Win32 C++ coding of desktop applications. I also regularly do C# and C++/CLI development. I have been working with WPF quite a lot lately and love the awesome expressive power of templating and styles which it offers. SOreadytohelp
Updated on November 18, 2020Comments
-
jschroedl over 3 years
While evaluating Visual Studio 2010 Beta 2, I see that in the converted directory, my vcproj files became vcxproj files. There are also vcxproj.filter files alongside each project which appear to contain a description of the folder structure (\Source Files, \Header Files, etc.).
Do you think these filter files should be kept per-user, or should they be shared across the whole dev group and checked into SCC?
My current thinking is to check them in, but I wonder if there are any reasons not to do that, or perhaps good reasons why I should definitely check them in.
The obvious benefit is that the folder structures will match if I'm looking at someone else's machine, but maybe they'd like to reorganize things logically?
-
jschroedl over 14 yearsI'm with you. I checked it in. Thanks!
-
gbjbaanb about 14 yearsfor automatic rebuilds, you build if any file has changed (eg source), so now nothing has changed except we have an yet another file to manage.
-
jschroedl about 14 yearsWe ended up checking them in and have been happy with that arrangement so far. It turns out to be nicer for us to work w/ other devs if they have the same filter structure.
-
gbjbaanb about 14 yearsin other words, you manage both files as if they were one. I don't think anyone else will treat them separately either. Its a nice idea, but a bit of thought about real-world practices would have gone a long way (like putting the runtime in WinSxS)
-
David over 12 yearsI agree with the previous comments. We also treat both as if they were one. This seems like a very non-pragmatic and (annoying to developers) choice they made to separate these files.
-
rwallace over 11 yearsI treat them separately. As far as I'm concerned, the less crap that has to be preserved as part of the project state, the better, so I think this is a good decision.
-
Johan Boulé almost 10 yearsCan we disable those filters altogether if we don't want to use any abstract/logical tree but just see the plain filesystem one?
-
Yakov Galka about 7 years@JohanBoule: I totally agree! They should have just scrapped the filters in the IDE. There is already a logical tree structure and it is called "filesystem". Currently there is a lot of duplication -- each file has to be added to the filesystem, to the build script (vcxproj), filters (vcxproj.filters), source control, and maybe somewhere else. It violates the DRY priciple. Fortunately it seems that the filter files are optional. You can just delete them and use the "Show All Files" button in the IDE. Pity that it's not the default.
-
ollydbg23 over 6 yearsThe mentioned link does not said this .filters file should have "union" mentioned in the gitattributes file.
-
Peter Schneider almost 6 yearsBut it tells what
merge=union
does - nothing else was promised. With that knowledge and a very broad idea how *.filter-files look like, it is easy to see whymerge=union
is a good idea for those files.