我有一个Visual Studio解决方案,里面有3个项目。相同的解决方案是有一个文件夹,我在其中添加了属于其他TFS团队项目的现有项目。
TeamPrj1
|- Solution1
|- External Reference(folder)
|- PrjA (added as existing project)
|- Prj1
|- Prj2
TeamPrj2
|- SolutionA
|- PrjA
我想为我的Solution1提供TFS Build。我面临的问题是解决方案没有在TFS Build Server上编译,因为它找不到PrjA的引用。我知道在工作区映射中有一些调整要做,我也经历了different forum和blogpost,但仍然无效。有人说将PrjA dll添加为文件引用,但我不想去那条路线,如果PrjA中的某些变化比Sol1需要重新引用最新的dll。添加为参考后,每次从TFS打开Solution1时,它会自动获取最新信息。
目前,下面是我的工作区映射。
Active $/TeamPrj1/Main/Solution1
$(SourceDir)
Active $/TeamPrjA/Main/SolutionA
$(SouceDir)\Main\
答案 0 :(得分:1)
由于解决方案需要使用相对路径引用其他项目,因此您需要确保构建定义的工作区映射实际上产生与本地工作区相同的文件结构。
根据您的文件夹名称,您应该使用以下映射:
Active | $/TeamProj1/Main/Solution1 | $(Sourcedir)\Solution1
Active | $/TeamProjA/Main/SolutionA | $(Sourcedir)\SolutionA
但在我们知道PrjA.csproj
中Solution1.sln
定义的相对路径之前,我无法确定确切的目标路径。
您可能还需要在Build Definition编辑器的Process选项卡中更新解决方案的路径。
答案 1 :(得分:0)
如果您有Visual Studio项目,例如包含多个团队项目使用的共享库代码的团队项目,
您可以在拥有团队的项目中管理项目 您可以专门为共享创建一个单独的团队项目 项目
如果您选择后一种方法并使用共同的共享项目,则 Microsoft Visual Studio Team Foundation中的文件夹结构 服务器(TFS)源代码控制看起来像
有关详细信息,请参阅以下内容:
Chapter 6 – Managing Source Control Dependencies in Visual Studio Team System
答案 2 :(得分:0)
我想最好的选择是拥有一个企业NuGet服务器并在内部发布这个NuGet站点的包。
对于不同团队项目下的visual studio解决方案,他们可以轻松地NuGet进行参考。 TFS Automated构建还可以轻松恢复任何解决方案的NuGet包。
您还可以使用自动构建将NuGet包丢弃到NuGet服务器,以获得在多个TeamProject和Team Collections中通用的程序集/ exe。 (构建模板中的xcopy命令)。
使用此方法的最大好处:一切都是自动化的。无需进行任何手动合并和签入。可以在多个TeamProject& TeamCollections。如果父公共dll发生更改,则它的自动构建可以将其推送到NuGet服务器。下次使用通过NuGet使用公共dll的所有其他项目将始终使用Build Server上的最新项目时,它将始终从NuGet下载最新版本(假设您保持版本#相同)。