CODEWITHSUNDEEP
c#visual-studiotfstfsbuildtfs-2015
Ash K
Ash K

Reputation: 3721

Reference to shared project in TFS 2015

I'm working with a lot of console applications, and all of them use a shared project. The branch in TFS looks like this:

-branchname
   --scripts
   --sharedlib
   --applications
        --application1
        --application2 etc.

There are hundreds of applications which all reference the project inside sharedlib. And we're not referencing .dll from it, because some application teams would want to customize the shared project.

So for all the applications to work, I've mapped the TFS branch to my local and open the solution and add an existing project and add the shared project .csproj as a reference (in Visual Studio 2015). I can see the reference to the shared project in both the .sln and .csproj file of my applications which goes like: 

..\..\sharedlib\commonproject\commonproject.csproj

Meaning it goes two levels up from the application solution folder, finds that sharedlib folder and subsequently the .csproj file. It works fine on the local.

But when I create a build definition for the application in TFS 2015, it all blows up. Because the TFS build "Get Sources" step brings the sharedlib folder to the .sln folder level as the Repository Mapping in TFS is made for both the application folder and sharedlib folder to the $(build.sourcesDirectory) and $(build.sorcesDirectory)\sharedlib path respectively. So when it looks at the .sln file and tries to go two levels up to find the shared project .csproj file, it simply won't be able to do that because in the build server the common .csproj file is at one level down from where the .sln files are copied to: (sharedlib\commonproject\commonproject.csproj)

So If I edit the .sln and .csproj file to remove the two levels up path and simply put it as (sharedlib\commonproject\commonproject.csproj), then it builds on the server, but won't even load on the local as the path becomes incorrect in the local. So I can't seem to make it work on both local and TFS server.

Is there any way to fix this problem?

One possible solution that I can think of is copying the shared project two levels up in the build server before it starts the build and keep the path in the .sln and .csproj untouched. But how can I design that step in TFS?

Any kind of solution would be greatly appreciated.

Thank You

Upvotes: 0

Views: 783

Answers (2)

Eddie Chen - MSFT
Eddie Chen - MSFT

Reputation: 29976

You can configure the local path of the projects on Build Agent Folder in the build definition. The easy way I would prefer is setting the path two level down for application project in the build definition like following and then update the path in VS Build step accordingly:

Application: $(build.sourcesDirectory)\app\app 
Sharedlib: $(build.sorcesDirectory)\sharedlib

Upvotes: 0

PatrickLu-MSFT
PatrickLu-MSFT

Reputation: 51183

"Some application teams would want to customize the shared project." They could also generate multiple versions of dll based on the shared project, and use Nuget to manage/import the version they need.

If your team insist on using project reference instead of dll reference. Suggest you use Relative path reference instead of using absolute path.

Since it's two levels up from the application solution folder, you could try to use 

$(SolutionDir)\sharedlib\commonproject\commonproject.csproj

Upvotes: 0

Related Questions