2017-03-09 116 views
0

当多个解决方案中解决方案中的某些项目引用另一个解决方案中的另一个项目的组合时,最佳策略是什么?Visual Studio 2015多种解决方案策略(TFS)

- Solution 1 
-- Proj1 
-- Proj2 
- Solution 2 
- OtherProj 1 
- Solution 3 
- FooProj1 
- FooProj2 

例如,如果OtherProj,FooProj1和FooProj2使用Proj1或Proj2程序集。

现在我必须构建例如Proj1并手动将该程序集复制/粘贴到解决方案2和解决方案3中的解决方案文件夹中。 我无法直接引用,因为那样会使用本地路径,并且如果我签入通过源代码管理(TFS),我的同事收到我的本地路径(这就是为什么我们复制/粘贴到解决方案文件夹中,以便路径总是相对的)。

我们正在考虑的是添加后构建事件并将程序集复制到server \ myserver \ assemblies \ relaase \ Proj1.dll上的共享文件夹,然后在我们的解决方案/项目中引用这些文件。

这是一个很好的策略,因为它可以与源代码控制一起工作,还是有其他策略可以工作吗?

(有什么存在像在Visual Studio中共享项目,但我认为这是多为单一的解决方案,但多个平台,而不是共享周围)

+0

一旦你的代码库变得足够大,它使得单个SLN文件无法管理。此时,您需要编写和维护MSBUILD“.proj”文件,以正确的顺序构建所有项目。如果你这样做,你的项目可以从它们所在的地方引用DLL。您不需要为参考使用绝对文件路径 - 您应该使用相对路径(这是创建对另一个程序集的引用时的默认路径,因此您不需要在此处做任何特殊的操作)。 –

回答

2

您应该公布每个项目/解决方案的输出作为NuGet包并依赖这些软件包。

将您的项目或解决方案的输出打包为Nuget包,并且内置了大部分功能非常简单。NuGet存储库可以是网络共享,也可以使用托管服务(MyGet,VSTS/TFS等)。

+0

发布Nuget包对CI构建来说很好,但是当您需要在一个解决方案(SolutionA)中进行更改时,在另一个参考SolutionA的解决方案SolutionB中工作时,该怎么办?除了用本地参考(脖子上的痛苦和受到本地参考的意外提交)临时替换SolutionB中的Nuget包参考外,还有其他选择吗? –

+0

您将每个解决方案视为具有松耦合的第三方包。你所描述的是代码的紧密耦合。不是一个好的做法... –

+0

这与耦合无关。它与您正在开发的开发工作有关,例如,图书馆和使用它的应用程序。您需要在库中进行更改,并立即在应用程序中查看/使用它们。发布到Nuget仓库是一个大锤,如果Nuget不支持类似于Maven的SNAPSHOT版本的东西,那么它就会非常痛苦。如果Nuget有这样的话,那么在每个版本上发布这个库至少是可行的。 –

0

VS扩展,NuGet参考切换器是这种情况的一种解决方案。从它的描述:

NuGet参考切换器是一个Visual Studio扩展它可以自动将NuGet组件引用切换到项目引用,反之亦然。这在开发引用自己的NuGet包的应用程序时很有用。

Here is the VS 2015 version

Here is the VS 2017 version

相关问题