MSBuild gets a reference to the ProjectReference assembly

I am writing an MSBuild task that adds some code generation to a standard C # project (.csproj). The task must have access to the types in the assemblies referenced by this project.

This is easy for assembly references (getting all elements in a <Reference>), but it becomes more difficult to reference other projects (<ProjectReference>)

Does MSBuild provide a way to get a compiled assembly reference from <ProjectReference>?

If not, is there an easy way to resolve this name by reading the .csproj file?

The .csproj file does not directly provide a compiled build path; it must be restored from other properties. In addition, some properties are conditional (depending on the configuration of Debug / Release), so using a simple XPath reader will not work:

The Dll file name can be obtained from <AssemblyName>, but the path where the Dll file is written is in

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' "> <OutputPath>;bin\Release</OutputPath> <PropertyGroup> 

Is there a way to programmatically read the .csproj file and solve the correct OutputPath value by evaluating all the conditions?

I need a solution in which .csproj referenced files remain plain old project files (no changes to csproj files that would add the necessary information in a more accessible way)

+6
msbuild
source share
1 answer

You can add something like:

 <Target Name="CopyDllsFromDependentProjects"> <MSBuild Projects="@(ProjectReference)" Targets="Build" BuildInParallel="true" Condition="'%(Name)'=='ProjectA' Or '%(Name)'=='ProjectB'"> <Output TaskParameter="TargetOutputs" ItemName="OutputAssemblies" /> </MSBuild> <Copy SourceFiles="@(OutputAssemblies)" DestinationFolder="$(PostBuildDir)" SkipUnchangedFiles="true" /> 

into your project and name it as follows:

  <Target Name="AfterCompile" DependsOnTargets="CopyDllsFromDependentProjects" /> 

Add seasoning to taste.

This includes MSBuilding dependencies for generating results (information cannot be obtained due to the way in which inclusions are processed in MSBuild, for example, where did TeamBuild put the output?).

Inside the book, the MSBuild Engine is great for delving into such nonsense.

+6
source share

All Articles