Update simple name references with HintPath from DLL from NuGet package instead of replacing reference

[dsplaisted]

Fixes #1244

[dsplaisted]

@dotnet-bot test OSX10.12 Debug

[dsplaisted]

@dotnet-bot test Windows_NT Debug
test Ubuntu16.04 Release

[davkean]

There's not a built-in way of doing this?

[nguerrera]

@rainersigwald?

[nguerrera]

I don't think so. We have an atrocious pattern in msbuild xml elsewhere for this that we need to eradicate. A task is a step in the right direction for those cases but I still worry about the perf here introducing this complexity where it didn't already exist. Feels like a risky fix at best.

Dave, can we measure the impact of this on the Roslyn scenarios you've been tuning before merging?

[davkean]

Yeah I would like to see the impact on the build, I'm only testing 1.1 SDK - so I have no idea what impact 2.0 SDK has on perf.

Is there a good write up on what we're trying to solve with all these "fixups"? They smell like we're missing feature asks.

[davkean]

I was thinking of an item function or existing task that did something similar, but couldn't see one.

[rainersigwald]

So you're trying to copy metadata from Right to Left items that correspond? You can do that with shared metadata batching:

<Project>
 <ItemGroup>
  <L Include="foo" />
  <L Include="bar" />
  <L Include="baz" />
  <L Include="bat" />

  <R Include="foo" M="m1" />
  <R Include="bar" M="m2" />
  <R Include="baz" M="m3" />
  <R Include="bat" M="m4" />
 </ItemGroup>

 <Target Name="ExecuteJoin">
  <ItemGroup>
   <Joined Include="@(L)" Condition="'%(Identity)' != '@(R) '">
    <M Condition="'%(L.M)' == ''">@(R->'%(M)')</M>
   </Joined>
  </ItemGroup>

  <Message Text="Joined: @(Joined->'%(Identity), %(M)')"/>
 </Target>
</Project>

s:\>msbuild S:\msbuild\join.proj
Microsoft (R) Build Engine version 15.3.409.57025 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

Build started 8/3/2017 11:20:22 AM.
Project "S:\msbuild\join.proj" on node 1 (default targets).
ExecuteJoin:
  Joined: foo, m1;bar, m2;baz, m3;bat, m4
Done Building Project "S:\msbuild\join.proj" (default targets).

Only caveat is you can't use different keys for the left and right item--but you can always first add a JoinKey metadatum to both lists.

[dsplaisted]

@rainersigwald I don't understand how that batching is working. The condition seems like it would do the opposite of a join (ie return all pairs where the identities didn't match): Condition="'%(Identity)' != '@(R) '".

[rainersigwald]

True!

The condition should have been '%(Identity)' != '', since all we need is to batch over a unique shared metadatum.

<Project>
 <ItemGroup>
  <L Include="foo" />
  <L Include="bar" />
  <L Include="baz" M="m3_original" />
  <L Include="bat" />

  <R Include="foo" M="m1" />
  <R Include="bar" M="m2" />
  <R Include="baz" M="m3_modified" />
  <R Include="bat" M="m4" />
 </ItemGroup>

 <Target Name="ExecuteJoin">
  <ItemGroup>
   <Joined Include="@(L)" Condition="'%(Identity)' != ''">
    <M Condition="'%(L.M)' == ''">@(R->'%(M)')</M>
   </Joined>
  </ItemGroup>

  <Message Text="Joined: @(Joined->'%(Identity), %(M)')"/>
 </Target>
</Project>

ExecuteJoin:
  Joined: foo, m1;bar, m2;baz, m3_original;bat, m4

My original attempt "worked" because I had a trailing space in '@(R) ' . . . so the comparison never matched and always passed.

[nguerrera]

Note that {HintPathFromItem} comes before {TargetFrameworkDirectory} in AssemblySearchPaths while {RawFileName} comes after it. I don't know if we depend on this ordering in any subtle ways.

[nguerrera]

Nit: These aren't very long and I think it would be easier to follow with the attributes on one line. (Maybe not for the cases that use all of the options).

[nguerrera]

Looks good overall.

I'd like to see end-to-end perf impact on large solution here.

We should also think about that search path ordering change.