locked
build definition when 2 team projects reference each other RRS feed

  • Question

  • I have 2 team projects, TP1 and TP2.  I've created a build defintion in TP1 that works great and does everything i need it to do.  Now, i need to include TP2 into that build definition, and i'm getting some errors.

    Basically the solution in TP2 references project files that are in TP1 (not as file assemblies, but as project references), and that is where the errors come from.  Each project that is in TP1 gets a 'the project... was not found' error from the build when it's trying to build TP2.

    Is this even possible to do?


    Phil Johnson
    Wednesday, June 30, 2010 6:16 PM

Answers

  • Ok, you also need to make sure the your workspace recreates the same structure on the build server as you have locally. For example, if you have this structure

    TP1
         Solution1
                Project1
                        project1.csproj

    TP2
         Solution2
                Project2
                         project2.csproj

    And you have project1 referencing project2 like this:
            ..\..\..\TP2\Solution2\Project2\project2.csproj

    Then the structure must match on the build server as well. Typically, if you set up a build definition for project 1 in this case, you would set the workspace mapping like this:

    $/TP1/Solution1       $(SourceDir)

    If you add another workspace mapping to include solution2, you normally get something like this:

    $/TP2/Solution2       $(SourceDir)\Solution2

    This will end up with Solution2 being downloaded below solution1 which of course won't work with your relativt path.

    Instead, try something like this:

    $\(TP1)\Solution1\         $(SourceDir)\TP1\Solution1
    $\$(TP2\Solution2\         $(SourceDir)\TP2\Solution2

    This will recreate an identical source folder structure on the buildserver and will make it compile.

    On a side note: Check out this blog post on different options for managing dependencies:
    http://geekswithblogs.net/terje/archive/2008/11/02/article-on-subsystem-branching.aspx

    We usually implement dependencies using branching, check out my blog post on how to replicate dependencies (The example is for TFS 2008) here:
    http://geekswithblogs.net/jakob/archive/2009/03/05/implementing-dependency-replication-with-tfs-team-build.aspx

    This relieves you from creating complicated workspace mappings that must be duplicated for every developer and for every build definition. 

    Hope that helps
    /Jakob
        


    Blog: http://geekswithblogs.net/jakob Twitter: http://twitter.com/osirisjakob
    Thursday, July 1, 2010 5:56 PM

All replies

  • Yes this is possible, at least if you are on TFS 2008 or TFS 2010. What you need to do is to include path of the project(s) in TP1 to the workspace mapping of the build definition in TP1. Otherwise the source code for the projects in TP1 will not be downloaded and you will get a "project not found" error.

    Also, make sure that the build service account has read permission in TP1, otherwise it will not download the source. You will not get an error, so this problem can be hard to spot

    Hope that helps
    /Jakob


    Blog: http://geekswithblogs.net/jakob Twitter: http://twitter.com/osirisjakob
    Wednesday, June 30, 2010 9:12 PM
  • well i'm glad it's possible, but i might need a bit more help on how to do what you describe.  What i think you meant for me to do what:

    edit my build definition, go to the 'workspace' section in the treeview, and add a working folder for each of the folders that contains the projects in TP1 that TP2 references. 

    I tried that, and still get the same issue.  Am i understanding this wrong?


    Phil Johnson
    Thursday, July 1, 2010 12:24 AM
  • No that is correct. Check here for more info on workspace mapping för builds:
    http://www.woodwardweb.com/vsts/tfs_top_tip_16.html

    Ifit still doesn't work, check the permisson issue that I mentioned above.

    /Jakob


    Blog: http://geekswithblogs.net/jakob Twitter: http://twitter.com/osirisjakob
    Thursday, July 1, 2010 7:34 AM
  • yeah, i put in a workspace for each folder that has a project that was 'missing' for the TP2 solution that referenced TP1, and no luck, same issue.  It's actually the same build account used for both TP1 and TP2, so it should have permissions. 

    the actual error (one of them) is :

    C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets (1200): The referenced project '..\..\4.5\CoBRA\SharedProjects\CoBRAPlugInSDK\CoBRAPlugInSDK.vbproj' does not exist.

    the solution in TP2 has a project that points to the above project, which is in TP1.  The actual TP1 project is in the solution too, so that the TP2 project can just reference the above project by reference. 

    Sorry if i'm repeating myself, just hoping to clarify things more in case that helps!


    Phil Johnson
    Thursday, July 1, 2010 4:13 PM
  • Ok, you also need to make sure the your workspace recreates the same structure on the build server as you have locally. For example, if you have this structure

    TP1
         Solution1
                Project1
                        project1.csproj

    TP2
         Solution2
                Project2
                         project2.csproj

    And you have project1 referencing project2 like this:
            ..\..\..\TP2\Solution2\Project2\project2.csproj

    Then the structure must match on the build server as well. Typically, if you set up a build definition for project 1 in this case, you would set the workspace mapping like this:

    $/TP1/Solution1       $(SourceDir)

    If you add another workspace mapping to include solution2, you normally get something like this:

    $/TP2/Solution2       $(SourceDir)\Solution2

    This will end up with Solution2 being downloaded below solution1 which of course won't work with your relativt path.

    Instead, try something like this:

    $\(TP1)\Solution1\         $(SourceDir)\TP1\Solution1
    $\$(TP2\Solution2\         $(SourceDir)\TP2\Solution2

    This will recreate an identical source folder structure on the buildserver and will make it compile.

    On a side note: Check out this blog post on different options for managing dependencies:
    http://geekswithblogs.net/terje/archive/2008/11/02/article-on-subsystem-branching.aspx

    We usually implement dependencies using branching, check out my blog post on how to replicate dependencies (The example is for TFS 2008) here:
    http://geekswithblogs.net/jakob/archive/2009/03/05/implementing-dependency-replication-with-tfs-team-build.aspx

    This relieves you from creating complicated workspace mappings that must be duplicated for every developer and for every build definition. 

    Hope that helps
    /Jakob
        


    Blog: http://geekswithblogs.net/jakob Twitter: http://twitter.com/osirisjakob
    Thursday, July 1, 2010 5:56 PM
  • ok, thank you very much.  that was definitely part of the answer.  I've changed the workspaces so that they match my file directory structure more closely, and that looks like it took care of the references for the projects in the solution (TP2.sln), but the references to the project inside the project (TP2a.proj and TP2b.proj, which both reference TP1a.proj) still doesn't work.  theres something i'm missing, and it looks like it only happens to the projects where i have changed the output path to something non-standard(which we do for several of our projects).  But should that matter?  Shouldn't it look relative to the .proj file, rather than the compiled .dll?  Yeah, it keeps getting more complicated!

    I want to use your ideas above, but it may be a little late to change all the dependencies for me right now.  This project is a fairly small team.


    Phil Johnson
    Friday, July 2, 2010 3:15 AM