获取最新的解决方案文件或解决方案文件夹（复杂的依赖关系）？

我大部分时间都看到开发人员为了在解决方案上工作，右键单击源代码管理中的解决方案文件夹，选择“获取最新”，并且......有大量问题：解决方案的项目引用其他解决方案中的其他项目，丢失的引用，等等获取最新的解决方案文件或解决方案文件夹（复杂的依赖关系）？

下面是类似的东西，我们在工作中所模拟的例子... enter image description here

现在，想象一下，你必须在TicketsSolution工作，特别是 - 修复了一些漏洞，使使用TicketsSolution的Web项目进行更改。通常开发人员右键单击TFS/VSS中的TicketsSolution文件夹（无论什么），然后选择“获取最新版本......”，上述问题直接影响了他们。

原来，TicketsSolution还包括这样的项目如

Common.Solution1.Project1，其可以具有以Common.Solution2.Project1

Common.Solution1.Project2

WCFServicesLibrary项目的引用，其中可能有一个引用SQLServerProxy项目

此外，一些外部的第三个派生DLL已经丢失或放置在ROOT下但在TicketsSolution文件夹之外的某处...

在当您获取最新的只是TicketsSolution文件夹中所有的引用将会丢失这种情况下，

因此它似乎是唯一合理的途径到获取最新将右键单击只是解决方案的文件，例如TicketsSolution.sln，并只获取该文件的最新版本。然后，在Visual Studio中打开TicketsSolution.sln文件，希望能够重建解决方案所需的解决方案文件夹内部和之外的所有树节点。

即使在这种方法中，外部DLL libabries的引用也会被忽略，因为VS知道如何重建文件夹树，但它不包括TicketsSolution文件夹之外引用的DLL。

但是，90％的开发人员会得到最新的解决方案文件夹并产生大量问题。

因此，我的问题是 - 在这种情况下，在TicketsSolution解决方案中包含外部项目是否正确，或者在TicketsSolution文件夹下添加“lib”文件夹并删除所有这些外部依赖项的dll会更合理项目，然后，从解决方案的项目中引用它们，而不是重建整个文件夹树和上层的所有依赖项目（可能并可能会有自己的依赖项和引用问题）??

来源

2014-06-14 monstro

切勿在您的解决方案中打开另一个解决方案项目。这是非常糟糕的做法，应该避免。将每个解决方案视为一个应用程序，将任何东西视为二进制依赖。 –

@MHHinsh，完全同意。问题在于它已经在我加入的公司的那个州。除此解决方案之外的所有这些外部项目也以同样的方式被其他项目引用，它们就像几种解决方案中的“常见”一样。 – monstro

Lib文件夹使生活更简单，但在构建层次结构中引入了其他问题。另外，你必须将你的库存储在源代码管理中，这对某些人来说是不可能的。

我使用本地NuGet提要。

我认为你的问题最简单的答案是，创建一个.bat文件，为你需要签出解决方案的文件夹写入检出调用，存储在TFS上的解决方案根文件夹中。

让开发人员单击bat文件以获取解决方案的所有文件的最新版本。

来源

2014-06-14 17:09:05

这是解决此问题的正确方法。将你的依赖关系打包为nuget包，其他解决方案使用它 –

@MHHinsh，是的，我同意，这只是我无法制定我的规则如何组织他们的TFS存储，这是巨大的，我在这里签约:)除此之外，他们对于使用Nuget有点“背后”:)我可能会建议所有引用的外部项目都编译成DLL，并将这些DLL放入解决方案中的Lib文件夹中，并完全从这个解决方案中删除这些外部项目，只留下项目这是解决方案的一部分（在解决方案的文件夹内）。 – monstro

获取最新的解决方案文件或解决方案文件夹（复杂的依赖关系）？

回答

相关问题