.sln是否应该致力于源代码控制? [英] Should a .sln be committed to source control?

问题描述

将.sln文件提交到源代码管理是最佳实践吗?何时合适或不合适?

Is it a best practice to commit a .sln file to source control? When is it appropriate or inappropriate to do so?

更新 答案中有几点要点.感谢您的答复！

Update There were several good points made in the answers. Thanks for the responses!

推荐答案

我认为从其他答案中可以明显看出，解决方案文件是有用的，应该提交，即使它们没有用于正式版本.对于使用诸如转到定义/声明之类的Visual Studio功能的任何人来说，它们都很方便.

I think it's clear from the other answers that solution files are useful and should be committed, even if they're not used for official builds. They're handy to have for anyone using Visual Studio features like Go To Definition/Declaration.

默认情况下，它们不包含绝对路径或任何其他特定于机器的工件. (不幸的是，某些外接程序工具无法正确维护此属性，例如AMD CodeAnalyst.)如果您谨慎使用项目文件中的相对路径(C ++和C#)，它们将与机器无关.也是.

By default, they don't contain absolute paths or any other machine-specific artifacts. (Unfortunately, some add-in tools don't properly maintain this property, for instance, AMD CodeAnalyst.) If you're careful to use relative paths in your project files (both C++ and C#), they'll be machine-independent too.

可能更有用的问题是:您应该排除哪些文件?这是我的VS 2008项目的.gitignore文件的内容:

Probably the more useful question is: what files should you exclude? Here's the content of my .gitignore file for my VS 2008 projects:

*.suo
*.user
*.ncb
Debug/
Release/
CodeAnalyst/

(最后一个条目仅用于AMD CodeAnalyst分析器.)

(The last entry is just for the AMD CodeAnalyst profiler.)

对于VS 2010，您还应该排除以下内容:

For VS 2010, you should also exclude the following:

ipch/
*.sdf
*.opensdf

这篇关于.sln是否应该致力于源代码控制?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！