Some transformations on @(ReferencePath) result in mangled references

[rainersigwald]

Some builds fail with an error like

(CoreCompile target) ->
  CSC : error CS0006: Metadata file '%(FullPath)' could not be found

when building using VS 15.3 preview 2 builds (which are not yet public).

This ItemReferenceGroup sets a default value for the ReferenceAssembly metadata of ReferencePath items to %(FullPath). The engine evaluates that as a literal string, but it can be successfully read through by item transformations like FindReferenceAssembliesForReferences's @(ReferencePath->'%(ReferenceAssembly)'), because the evaluator recurses--it sees that literal, interprets it as a metadata reference, and reads the FullPath metadata.

However, not all transformations perform that recursion. An ITask implementation that uses return new TaskItem(oldItem), for example, evidently escapes the metadatum string, and when it is expanded it turns into a literal %(FullPath) instead of the value of the FullPath metadatum.

FindReferenceAssembliesForReferences then populates ReferencePathWithRefAssemblies with a list of items whose identity is %(FullPath), which isn't valid and confuses the compiler, producing the error above.

This is a regression introduced by e3a3d69 when implementing #1986.

[rainersigwald]

You can work around the bug by setting the property

<CompileUsingReferenceAssemblies>false</CompileUsingReferenceAssemblies>

which avoids transforming @(ReferencePath) using the recursive metadata expansion.

[rainersigwald]

Thanks for reporting this @KirillOsenkov and @ToddGrun.

FYI @dsplaisted -- the task that hit this for them was StrongNamer. Filed dsplaisted/strongnamer#14 in the hopes that anyone who sees it will find it there.

[rainersigwald]

fyi @jcouv -- I'll also want to fix this in 15.3 p3.