sln是否应致力于源代码管理?

我认为从其他答案可以清楚地看出,解决方案文件是有用的,应该提交,即使它们没有用于正式构建。对于任何使用VisualStudio功能(如Go to Definition/Declaration)的人来说,它们都很方便。

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

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

对于VS 2010,还应排除以下内容:

ipch/
*.sdf
*.opensdf

是的,你应该这样做。解决方案文件仅包含有关解决方案总体结构的信息。这些信息是解决方案的全局信息,并且可能对项目中的所有开发人员都是通用的。

它不包含任何用户特定的设置。

你绝对应该拥有它。除了其他人提到的原因外,还需要使整个项目的一步构建成为可能。

我通常同意应该签入解决方案文件,但是,在我工作的公司,我们做了一些不同的事情。我们有一个相当大的存储库,开发人员不时地处理系统的不同部分。为了支持我们的工作方式,我们要么有一个大的解决方案文件,要么有几个小的解决方案文件。这两种方法都有一些缺点,需要开发人员手工操作。为了避免这种情况,我们制作了一个插件来处理所有这些问题。

该插件让每个开发人员只需从存储库中选择相关的项目,就可以签出源代码树的一个子集。然后插件生成一个解决方案文件,并动态修改给定解决方案的项目文件。它还处理引用。换句话说,开发人员所要做的就是选择合适的项目,然后生成/修改必要的文件。这还允许我们自定义各种其他设置,以确保公司标准。

此外,我们使用该插件来支持各种签入策略,这通常会防止用户向存储库提交错误/不兼容的代码。

是的,您应该提交的内容包括:

• 解决方案(*.sln),
• 项目文件,
• 所有源文件,
• 应用程序配置文件

你应该做的事情 承诺是:

• 解决方案用户选项(.suo)文件,
• 生成生成的文件(例如,使用生成脚本) [编辑:]

separate thread .

是的,您总是希望包含.sln文件,它包含指向解决方案中所有项目的链接。

在大多数情况下,最好将.sln文件提交给源代码管理。

我们这样做是因为它使一切保持同步。所有必要的项目都位于一起,没有人需要担心丢失一个。我们的构建服务器(Ant Hill Pro)也使用sln来确定要为发布版构建哪些项目。

如果您有一个包含许多源代码管理项目的大型解决方案,并且您希望使用主解决方案中的一些项目创建一个小型解决方案,以满足一些私有的临时需求,那么您甚至可以考虑不将其存储在源代码管理中。

是-用于生成产品的所有内容都应在源代码控制中。

我们在TFS版本控制中保留或解决方案文件。但由于主解决方案非常大,大多数开发人员都有一个只包含他们需要的内容的个人解决方案。主解决方案文件主要由生成服务器使用。

.SLN是我们唯一需要的 没有 在tfs中遇到问题!