Visual studio 在源代码管理中如何处理VS.net sln和proj文件？

我希望这与编程相关，因为它涉及到如何构建项目

因为我总是在VS.net中使用网站模型，所以我从来没有解决方案和项目文件，将所有内容都放在源代码控制中非常有效。我知道我网站目录中的所有内容都是我网站所需要的

现在我使用的是asp.NETMVC，它只有一个项目模型，所以现在我有了这些解决方案和项目文件。如果我单独处理，这很好，但一旦其他人开始从项目中添加/删除文件，我们的解决方案文件就会变得混乱，人们最终不得不获取最新的解决方案文件，查看更改了什么，然后添加/删除他们的文件，并再次签入解决方案文件。这成了一个问题，因为有时人们没有意识到解决方案文件已更改，他们会进行其他更改，然后当他们签入其他人对其文件所做的所有更新时，他们发现他们的文件已从项目中删除（尽管仍在磁盘上）

---

这正常吗？有没有一种方法可以构造一个项目，这样我们就不需要签入解决方案和项目文件？

TFS多次签出时，这种情况往往会发生。从VSS到TFS可能很难理解，因为VSS允许一个人一次签出一个文件。自动合并在大多数情况下对您有效，但有几条规则可以缓解您的痛苦：

尽早并经常签入（如果您添加、删除或重命名文件，请立即签入，即使它是一个空白持有人）

在签入之前，请执行“获取最新信息”，这将要求您在本地解决冲突

尝试设置持续集成，以便开发人员始终了解Build的状态以及签入/签出是否可以

---

我们在当前项目开始时有点痛苦，但当我们遵循上面的规则时，它很快就稳定下来了。

我认为这不正常-你用什么来进行源代码管理？这听起来好像开发人员不尊重其他人所做的更改—不先合并就签入

我知道，在项目的早期，当大量文件被添加和删除时，要跟上可能是个问题-您需要签出项目文件，添加文件，然后签入新文件和项目，以便其他开发人员也可以更新它。在一个解决方案中，您可能会有多个项目文件——也许一个临时解决方案是为每个开发人员“保留”一个项目，然后定期清理它们——尽管这些类型的临时修复有变成永久性的趋势

我不知道如何设置不在源代码管理中的项目文件，尽管我想您可以创建一个脚本来生成它们

---

经历了这些之后，关键在于开发人员之间的尊重和良好沟通。

您的开发人员没有正确使用TFS。您应该打开多个签出，每个人在签入时都需要小心正确合并其更改。TFS会提示您这样做，接受默认值几乎总是正确的做法

有一两个开发人员从来没有得到过它，这并不少见，你可能需要时不时地帮助他们。但是每个在团队中工作的程序员都需要学习如何正确使用源代码管理工具。如果他们不能做到这一点，他们就不应该编写软件

---

[编辑]我觉得，如果您直接签入*.sln文件，而不是选择“将解决方案添加到源代码管理中”，您可能会遇到这些问题。

就个人而言，我认为更改项目和解决方案文件需要整个开发团队遵守纪律和明确（充分理解）的规则。这些文件（.sln，.*proj）是项目的瓶颈，任何错误或不一致都可能导致团队停机。变更需要经过深思熟虑、计划，然后执行

它们必须由源代码管理（您已经在使用，非常好）来保护，并且您的团队成员应该只在进行他们需要的更改的基础上工作，而不是将项目或解决方案文件长期签出

如果您允许多个（共享）签出，这可能会在覆盖其他用户的更改方面产生问题。根据您的源代码管理机制，可能需要用户手动合并更改。就我个人而言，我会要求人们通过合并来协商他们的项目/解决方案变更（这并不总是能够实现）

如果使用TFS，第三个选项是搁置功能。如果有人需要在本地进行更改，他们可以搁置更改，稍后再合并

最后，另一个策略是尝试将您的解决方案构建为尽可能模块化的解决方案，这样人们就分散在不同的项目上工作，并且（理想情况下）不必在太多的公共区域上重叠。

始终将他们签入

在签入新版本之前，请始终签出最新版本（如果可能，请合并），确保您的更改已存在

---

如果您的源代码管理不需要特殊操作才能从旧版本签入，请使用其他源代码管理。

我不确定您是否正在使用TFS，正如人们所提到的，但您是否正在使用（或者您是否正在使用具有类似功能的源代码管理）您可以将其设置为sln和csproj文件为独占锁定，并且无法合并

我们已经在相当大的团队中完成了这项工作，虽然随着人们逐渐习惯，它会导致一些初始问题，但从长远来看，它已经解决了许多以前导致问题的问题。基本上，您可以用长期合并问题/复杂性来换取短期编译/签入问题，我们发现这是一个很好的折衷方案

一旦您将其设置为强制独占签出和不合并，您就可以让您的开发团队习惯于他们应该在sln和项目上保持锁定