locked
Secondary references, whats the story morning glory...? RRS feed

  • Question

  • I've come across a problem with MSBuild that has been summed up here very well:

    http://sstjean.blogspot.com/2006/11/msbuild-cant-find-secondary-references.html

     

    Is this true that this is going to be left this way? It would be VERY useful if MSBuild was able to spider the references so you don't have to add seemingly unused references to a project....

     

    I assume that the solution in the article is the only one avaiable? there isn't another work around?

     

    Thanks,

    Matt

    Thursday, August 30, 2007 2:49 PM

Answers

  • Sorry for the late reply.

     

    You can try adding the following target at the end of your project file (after the import of Microsoft.Common.Targets)

    <Target

            Name="AfterResolveReferences"

            >

        <ResolveAssemblyReference

            AssemblyFiles="@(_ResolvedProjectReferencePaths)"

            SearchPaths="$(AssemblySearchPaths)"

            >

          <Output TaskParameter="ResolvedDependencyFiles" ItemName="ReferencePath"/>

        </ResolveAssemblyReference>

      </Target>

     

    What this basically does is to get the dependencies of the referenced projects and not just the referenced project output and send them to the compiler.

     

    Unfortunately we cannot prevent not using the _ResolvedProjectReferencePaths item as it is private to Microsoft.Common.Targets. We could have used ReferencePath but that caused a second pass of RAR on the entire set of references and not just the resolved project references.

     

    Please note that this is just a workaround and not the actual solution to the problem. The workaround could be affected if the internal property name or its functions were changed so you cannot rely 100% on this workaround. We will investigate to see if there is something that can be done for future releases.

     

    Thanks,

    Jay Shrestha

    (jaysh@microsoft.com)

     

    Thursday, September 13, 2007 8:09 PM

All replies

  • Hi,

    I am currently investigating a workaround. I will have that posted by the end of this week.

     

    Thanks,

    Jay Shrrestha

    (jaysh@microsoft.com)

     

    Wednesday, September 5, 2007 4:01 PM
  •  

    Hi Jay,

     

    Any news on this?

     

    Cheers,

    Matt

     

    Wednesday, September 12, 2007 10:26 AM
  • Sorry for the late reply.

     

    You can try adding the following target at the end of your project file (after the import of Microsoft.Common.Targets)

    <Target

            Name="AfterResolveReferences"

            >

        <ResolveAssemblyReference

            AssemblyFiles="@(_ResolvedProjectReferencePaths)"

            SearchPaths="$(AssemblySearchPaths)"

            >

          <Output TaskParameter="ResolvedDependencyFiles" ItemName="ReferencePath"/>

        </ResolveAssemblyReference>

      </Target>

     

    What this basically does is to get the dependencies of the referenced projects and not just the referenced project output and send them to the compiler.

     

    Unfortunately we cannot prevent not using the _ResolvedProjectReferencePaths item as it is private to Microsoft.Common.Targets. We could have used ReferencePath but that caused a second pass of RAR on the entire set of references and not just the resolved project references.

     

    Please note that this is just a workaround and not the actual solution to the problem. The workaround could be affected if the internal property name or its functions were changed so you cannot rely 100% on this workaround. We will investigate to see if there is something that can be done for future releases.

     

    Thanks,

    Jay Shrestha

    (jaysh@microsoft.com)

     

    Thursday, September 13, 2007 8:09 PM
  • I found a different workaround to this problem.

    Just edit the language-specific target-file that ships with .NET framework, and MSBuild works.

    (Files can be found in <windowsdir>\Microsoft.NET\Framework\v<version>)

     

    If you use VB edit the Microsoft.VisualBasic.targets, Microsoft.CSharp.targets for C# and so forth.

     

    Find the corecompile target, and edit the references parameter in the compiletask (vbc or csc).

     

    Instead of References="@(ReferencePath)", type References="@(ReferencePath);@(ReferenceDependencyPaths)"

     

    This includes the nth order paths to dependencies together with the first order primary paths when compiling.

     

    Oh, it might be a good idea to save a backup-copy of the original targets file before you edit.

     

    I find this hack a bit more appealing than adding bogus references to the different projects.

     

    Wednesday, September 19, 2007 5:46 PM
  •  

    Thanks for the workaround - i've been on hol and haven't got time to try it yet but will soon.

     

    It would be good if it could be fixed though, if you find anything out please soon please could you post here.

     

    Thanks,

    Matt

     

    Tuesday, September 25, 2007 10:21 AM
  • This is a great "patch" and I applied it to "v3.5\Microsoft.VisualBasic.targets" and it worked.  I was disappointed with the MSBuild behavior and even more disappointed with the suggested workarounds.  This solution is very appealing.  Thank you.

    X
    Friday, March 13, 2009 4:21 PM
  • There is another workaround which does not require changing the central msbuild targets.

    Add the following Target inside the csproj or vbproj that is experiencing difficulties:

    <Target Name="AfterResolveReferences">
        <!-- Redefine referencepath to add dependencyies-->
        <ItemGroup>
          <ReferencePath Include="@(ReferenceDependencyPaths)"></ReferencePath>
        </ItemGroup>
      </Target>

    This does not seem to interfer with Visual Studio and also works with TFS Build - at least 2010.

    I have written about the background and a Step by step 1,2,3 instruction on my blog: automatically resolving secondary assembly references with msbuild

    • Proposed as answer by AgileJoshua Friday, February 17, 2012 2:14 PM
    Friday, February 17, 2012 12:05 PM