我应该将.vcxproj.filter文件添加到源代码控制中吗?

8 浏览
0 Comments

我应该将.vcxproj.filter文件添加到源代码控制中吗?

在评估Visual Studio 2010 Beta 2时,我发现在转换的目录中,我的vcproj文件变成了vcxproj文件。每个项目旁边还有vcxproj.filter文件,似乎包含了文件夹结构的描述(\\Source Files,\\Header Files等)。\n你认为这些筛选文件应该保留在每个用户之间,还是应该在整个开发组中共享并检入SCC?\n我目前的想法是将它们检入,但我想知道是否有任何不这样做的理由,或者是否有明确的理由我应该将它们检入。\n明显的好处是,如果我在别人的机器上查看,文件夹结构将匹配,但也许他们希望按逻辑重新组织东西?

0
0 Comments

在使用CMake或类似的构建工具生成*.sln、*.vcxproj、*.vcxproj.filters等文件时,不应将其添加进源代码控制。因为这些文件可能包含项目文件夹的完整路径和其他仅限于你的计算机的特定文件夹。

问题的原因是,这些生成的文件中可能包含特定计算机的路径信息,例如项目文件夹的完整路径。这意味着如果将这些文件添加到源代码控制中,其他使用不同计算机的开发人员在获取最新代码时,可能会遇到路径错误或找不到文件的问题。

为了解决这个问题,我们应该在源代码控制中忽略这些生成的文件。这样可以确保在团队协作时,每个人都可以根据自己的计算机环境重新生成这些文件,而不会受到路径或文件缺失的问题的影响。

忽略这些生成的文件的方法可以通过在版本控制工具(如Git)中添加.gitignore文件来实现。在.gitignore文件中,我们可以指定要忽略的文件或文件夹的模式。对于这些生成的文件,可以在.gitignore文件中添加以下规则:

*.sln
*.vcxproj
*.vcxproj.filters

通过添加这些规则,我们告诉版本控制工具在提交代码时忽略这些文件,从而避免了路径相关问题的发生。

总结起来,当使用CMake或类似的构建工具生成*.sln、*.vcxproj、*.vcxproj.filters等文件时,我们不应将其添加到源代码控制中。这些生成的文件可能包含特定计算机的路径信息,如果添加到源代码控制中,可能会导致其他开发人员在不同计算机上出现路径错误或找不到文件的问题。解决方法是在版本控制工具中添加.gitignore文件,并在其中指定忽略这些生成的文件的规则。这样可以确保团队协作时每个人都可以根据自己的计算机环境重新生成这些文件,避免路径相关问题的发生。

0
0 Comments

在以前的Visual Studio版本中(至少是6.0和2008版本),这些信息存储在它们自己的项目文件(.dsp和.vcproj文件)中,当然应该将其添加到源代码控制(SCC)中。

我想不出不将这些.filter文件包含在SCC中的任何理由。

我同意你的观点。我已经将其检入了。谢谢!

原因:以前的Visual Studio版本使用不同的项目文件来存储信息,因此应该将这些文件添加到源代码控制中。

解决方法:将这些.filter文件添加到源代码控制中。

0
0 Comments

问题的原因:

1. 在转换为.vcxproj MSBuild格式时,故意将.filter文件的信息从.vcproj中删除。

2. .filter文件仅仅是一个逻辑视图,不同的团队成员可能希望有不同的视图。

3. 有时候构建被设置为检查项目文件的时间戳,并在其更改时触发重建,因为这可能意味着有不同的源文件要构建或不同的设置等。我们不希望仅仅因为.filter文件的更改而触发重建,因为它们不会影响构建。

4. 自动重建时,只要有任何文件(例如源文件)更改,就会执行构建,所以现在除了又多了一个要管理的文件之外,没有什么变化。

5. 我们最终选择将.filter文件纳入源代码控制,并对此安排感到满意。事实证明,如果其他开发人员有相同的过滤器结构,与他们一起工作会更好。

6. 我们将两个文件视为一个文件进行管理,我认为其他人也不会单独处理它们。这是一个好主意,但是对实际工作实践的思考可能会更有帮助(例如将运行时放在WinSxS中)。

解决方法:

1. 将.filter文件纳入源代码控制。

2. 将两个文件视为一个文件进行管理。

3. 如果不想使用任何抽象/逻辑树,只想看到纯粹的文件系统,可以禁用这些过滤器。

4. 可以删除.filter文件并在IDE中使用"Show All Files"按钮。

值得庆幸的是,看起来.filter文件是可选的,可以删除它们并使用IDE中的"Show All Files"按钮。可惜这不是默认设置。

0