我正在使用许多控制台应用程序,并且它们都使用一个共享项目。TFS中的分支如下所示:
-branchname
--scripts
--sharedlib
--applications
--application1
--application2 etc.
有数百个应用程序都在sharedlib中引用该项目。而且我们没有从中引用.dll,因为某些应用程序团队希望自定义共享项目。
因此,要使所有应用程序正常工作,我已将TFS分支映射到本地,并打开了解决方案,添加了一个现有项目,并添加了共享项目.csproj作为参考(在Visual Studio 2015中)。我可以在应用程序的.sln和.csproj文件中看到对共享项目的引用,如下所示:
..\..\sharedlib\commonproject\commonproject.csproj
这意味着它从应用程序解决方案文件夹上升了两个级别,找到了sharedlib文件夹,然后找到了.csproj文件。它在本地工作正常。
但是,当我在TFS 2015中为应用程序创建构建定义时,这一切都破灭了。因为TFS构建“获取源”步骤将共享库文件夹带到.sln文件夹级别,因为TFS中的存储库映射是针对应用程序文件夹和共享库文件夹进行的,因此分别映射到$(build.sourcesDirectory)和$(build.sorcesDirectory) \ sharedlib路径。因此,当它查看.sln文件并尝试向上两级查找共享的项目.csproj文件时,它根本无法做到这一点,因为在构建服务器中,通用的.csproj文件从.sln文件复制到的位置向下一级: (sharedlib\commonproject\commonproject.csproj)
因此,如果我编辑.sln和.csproj文件以删除路径上的两个级别并将其简单地放置为(sharedlib\commonproject\commonproject.csproj),则它将建立在服务器上,但是甚至不会在本地加载,因为路径在本地不正确。因此,我似乎无法使其同时在本地服务器和TFS服务器上运行。
有什么办法可以解决这个问题?
我想到的一种可能的解决方案是,在开始构建之前,将共享项目复制到构建服务器中的两个级别上,并保持.sln和.csproj中的路径不变。但是,如何在TFS中设计该步骤呢?
任何解决方案将不胜感激。
RISEBY
有只小跳蛙
相关分类