我希望这与编程有关，因为它涉及如何构建项目。
因为我一直使用VS.net的网站模型，所以我从来没有过解决方案和项目文件，并且将所有内容都放到源代码控制中。我知道我网站目录中的所有内容都是网站所需的全部内容。
现在我正在使用asp.net MVC，它只有一个项目模型，所以现在我有这些解决方案和项目文件。如果我单独使用它就可以了，但是一旦其他人开始添加/删除项目中的文件，我们的解决方案文件就搞砸了，人们最终不得不抓住最新的解决方案文件，看看有什么变化，然后添加/删除他们的文件并再次检入解决方案文件。它已成为一个问题，因为有时人们没有意识到解决方案文件已被更改，他们进行了其他更改，然后当他们检查其他所有人对其文件进行更新时，他们发现他们的文件已从项目中消失（尽管仍在物理上在磁盘上。）
这是正常的吗？有没有办法构建项目，以便我们不需要签入解决方案和项目文件？
答案 0 :(得分：3)
您的开发人员未正确使用TFS。您应该打开多个签出，每个人都需要小心在签入时正确合并他们的更改.TFS将提示您这样做，并且接受默认值几乎总是正确的。
让一两个开发人员永远不会得到它的情况并不少见，你可能不时需要帮助他们。但是，每个在团队中工作的程序员都需要学习如何正确使用源代码控制工具。如果他们无法管理，他们就不应该编写软件。
[edit]如果您直接签入* .sln文件，而不是选择“将解决方案添加到源代码管理”，则可能会遇到这些问题。
答案 1 :(得分：2)
TFS多次检查往往会发生这种情况。由于VSS允许一个人一次检出文件，因此从VSS到TFS很难掌握。自动合并应该在大多数情况下适合您，但是一些规则可以减轻痛苦：
尝试进行持续集成设置，以便开发人员始终了解buidl的状态以及是否可以签入\ out。
在我们当前的项目开始时，我们有点痛苦，但是当我们遵循上述规则时很快就解决了。
答案 2 :(得分：2)
我不认为这是正常的 - 您使用什么来进行源代码管理？听起来开发人员并不尊重其他人所做的改变 - 在没有合并的情况下进行检查。
我知道在项目的早期，当添加大量文件时＆amp;删除，这可能是一个问题，你需要检查项目文件，添加文件，然后检查新文件＆amp;项目，以便其他开发人员也可以更新它。您可能在解决方案中有多个项目文件 - 也许一个临时解决方案是为每个开发人员设置一个“持有”项目，然后定期清理它们 - 尽管这些类型的临时修复确实有成为永久性的趋势。 / p>
我不知道如何设置一个不在源代码控制中的项目文件，不过我想你可以创建一个可以生成它们的脚本。
经历过这一切，关键是尊重＆amp;开发人员之间的良好沟通。
答案 3 :(得分：2)
就个人而言，我认为对项目和解决方案文件进行更改需要在整个开发团队中遵守规则和明确（易于理解）的规则。这些文件（.sln，。* proj）是项目的瓶颈，任何错误或不一致都会导致团队停机。需要仔细考虑，计划然后执行变更。
它们必须通过源代码控制（您已经使用，非常好）来保护，并且您的团队成员应该仅在进行所需更改的基础上工作，而不是让项目或解决方案文件长时间签出
如果您允许多个（共享）结帐，则在覆盖其他用户的更改方面可能会出现问题。根据您的源控制机制，可能需要人员手动合并更改。就个人而言，我会要求人们在合并时协商他们的项目/解决方案变更（这不能总是实现）。
如果您使用TFS，第三个选项是搁置功能。如果有人需要在本地进行更改，他们可以搁置更改并稍后合并。
最后，另一个策略是尝试将您的解决方案设计为尽可能模块化 - 因此人们是分布式的，在单独的项目上工作，并且（理想情况下）不必在太多公共区域上重叠。
答案 4 :(得分：2)
我不确定你是否正在使用TFS，正如人们所提到的那样，但如果你是（或者如果你正在使用具有类似功能的源代码控制）你可以设置它，使得sln和csproj文件是独占锁定并且是无法合并。
我们已经在相当大的团队中做到了这一点，虽然它会导致一些初始问题，因为人们长期习惯它，但它解决了许多以前导致问题的问题。基本上你交换长期合并问题/复杂性的短期编译/签到问题，我们发现这是一个很好的权衡。
一旦你将它设置为强制独占结账并且没有合并你就会让你的开发团队习惯于他们应该在sln和proj文件上保持锁定的时间越短越好。
答案 5 :(得分：0)
始终检查它们。
在签入新版本之前，请务必查看最新版本（如果可能，请合并），确保您的更改已完成。
如果您的源代码管理不需要特殊操作来从旧版本签入，请获取不同的源控件。