MSBuild should generate metaprojects that merge the outputs of the individual MSBuild invocations about msbuild

[sarajoiner]

Item creation from the output of a task should append to an item list in the same way a normal Include would. If that's not happening, I would say that that is the real issue here.

[olivierdagenais]

OK, I'll try to reproduce that specific scenario.

[olivierdagenais]

Item creation from the output of a task should append to an item list in the same way a normal Include would.

Confirmed with this MSBuild script:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build"
         xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <UsingTask TaskName="Generator" TaskFactory="CodeTaskFactory"
             AssemblyFile="$(MSBuildToolsPath)\Microsoft.Build.Tasks.v4.0.dll">
    <ParameterGroup>
      <StartPoint ParameterType="System.Int32" Required="true" />
      <Generated ParameterType="Microsoft.Build.Framework.ITaskItem[]" Output="true" />
    </ParameterGroup>
    <Task>
      <Code Type="Fragment" Language="cs"><![CDATA[
const int Max = 10;
Generated = new TaskItem[Max];
for (int c = 0, d = StartPoint; c < Max; c++, d++)
{
  Generated[c] = new TaskItem(Convert.ToString(d, 10));
}]]></Code>
    </Task>
  </UsingTask>
  <Target Name="Build">
    <Generator StartPoint="0">
      <Output TaskParameter="Generated" ItemName="g" />
    </Generator>
    <Message Importance="high" Text="g: @(g)" />

    <Generator StartPoint="20">
      <Output TaskParameter="Generated" ItemName="g" />
    </Generator>
    <Message Importance="high" Text="g: @(g)" />
  </Target>

</Project>

...I'll next chase down why the append isn't happening in this particular case.

[olivierdagenais]

Whoa, I don't understand how I got it so wrong the first time around and after reviewing the .metaproj files it seems so obvious now. I was close, though: the [generated] .csproj.metaproj file's <Target> elements are missing an Outputs attribute to relay back the contents of (in this case) MSBuildIssueBuildOutput:

<Target Name="Build" Outputs="@(MSBuildIssueBuildOutput)">
  <MSBuild Projects="@(ProjectReference)" BuildInParallel="True" Properties="BuildingSolutionFile=true; CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionPath=$(SolutionPath)" SkipNonexistentProjects="%(ProjectReference.SkipNonexistentProjects)">
    <Output TaskParameter="TargetOutputs" ItemName="MSBuildIssueBuildOutput" />
  </MSBuild>
  <MSBuild Projects="C:\Users\odagenais\oss\MSBuildIssue\Repro\MSBuildIssue\MSBuildIssue.csproj" BuildInParallel="True" ToolsVersion="$(ProjectToolsVersion)" Properties="Configuration=Debug; Platform=AnyCPU;BuildingSolutionFile=true; CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionPath=$(SolutionPath)">
    <Output TaskParameter="TargetOutputs" ItemName="MSBuildIssueBuildOutput" />
  </MSBuild>
</Target>

...which explains how the repro files would only talk about the other (non-transformed) project; its outputs were indeed properly collected (and were the only ones shown) and it wasn't a corruption of the output of the .csproj.metaproj files we were seeing, but rather the absence of output.

For my next trick, I'll encode my findings into a failing unit test and then we can discuss how to fix this.

[olivierdagenais]

You can cherry-pick the [failing] unit test as b5f7056 in the 69-metaprojects_should_relay_outputs branch of my fork.

[olivierdagenais]

I'm developing on Windows 7 with Visual Studio 2013, so I understand there are some tests that are known to fail (as per issue #30) and, according to the README, a sub-optimal experience without VS 2015, but my proposed fix in 0af88d9 indeed fixes the broken test I introduced and does not appear to break other tests.

Let me know what you think and I can open a pull request after reviewing other possible instances of this sort of "missing relay".

BTW, the unit test I added creates some files in %LocalAppData%\Temp\TempDirForMSBuildUnitTests, which allows one to also reproduce the defect with older versions of MSBuild (as had been initially reported in the Connect report) by running something like:

"c:\Program Files (x86)\MSBuild\12.0\Bin\MSBuild.exe" automatic.msbuild /verbosity:minimal

[olivierdagenais]

What do you think, @sarajoiner?

[sarajoiner]

Added a couple of comments. Definitely looks like you're on the right track to me. :)

[olivierdagenais]

Added a couple of comments. Definitely looks like you're on the right track to me. :)

Fabulous! Does this mean I satisfy the first two "limits" outlined in Contributing Code?

• Contributions must be discussed with the team first, or they will likely be declined.
• Only contributions referencing an approved Issue will be accepted.

In other words, does your last comment imply the contribution has been discussed (my pull request will of course address your comments and be more thorough) and that this issue is approved?

[sarajoiner]

Ah ... Unfortunately, I'm not a current member of the MSBuild team. So my opinion may hold some weight, but I don't think it counts as an official "go ahead".

@AndyGerlicher, @ValMenn, @dannyvv, @NikolaiTillmann, would one of you care to weigh in?