Copy task should error if copying multiple sources to the same destination path

[brthor]

A project with multiple items with CopyToOutputDirectory and conflicting assigned TargetPaths will cause the last file to be copied to the TargetPath.

I'm not certain this is a bug, but the behavior seems non-intuitive. It seems like multiple files trying to output to the same TargetPath should cause an error.

An example:

<Project ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" />

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworkIdentifier>.NETCoreApp</TargetFrameworkIdentifier>
    <TargetFrameworkVersion>v1.0</TargetFrameworkVersion>
  </PropertyGroup>

  <ItemGroup>
    <Compile Include="**\*.cs" Exclude="$(GlobalExclude)" />
    <EmbeddedResource Include="**\*.resx" Exclude="$(GlobalExclude)" />
    <Content Include="Program.cs;project.json">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
      <Link>otherfilename.json</Link>
    </Content>
  </ItemGroup>

  <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>

onlyproject.json will be copied to otherfilename.json and no error is thrown.

cc @rainersigwald @cdmihai @eerhardt

[martinscholz83]

I don't think this is a bug but more a missing feature. For now the content is only overwritten which seems to be fine. Maybe there is a need for a switch which let decide to append instead to overwrite!?
Here is a example i have tested

<Content Include="Class1.cs;Class2.cs">
      <Link>Test.cs</Link>
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </Content>     

And this is my output

UPDATE
Sorry for my comment 🙈 , you're right it should throws an error. It makes no sense that two different files are copied into one!! So i think it should throw an error if there are two files and the <Link> option is selected.

For example
Ok

<Content Include="Class1.cs;Class2.cs">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </Content>  

Should throw error

<Content Include="Class1.cs;Class2.cs">
      <Link>Test1.cs</Link>
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </Content>  

[jeffkl]

Do you really need the <Link /> element in there?

[martinscholz83]

Not really, but i gives you the opportunity to rename the file. But i think this more a side effect?

[martinscholz83]

Correct me if i'm wrong but i think the failure here is that you can add multiple items into <Content Include= If you add multiple items as a link with visual studio output is like this

<Content Include="Class1.cs">
<Link>Class1.cs</Link>
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </Content>  
<Content Include="Class2.cs">
<Link>Class2.cs</Link>
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </Content>  
<Content Include="Class3.cs">
<Link>Class3.cs</Link>
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
    </Content>  
...

This seems to be more correct.

[jeffkl]

Yes if you want to do <Link /> with multiple items, you'll need to do list them out and not do a semi-colon delimited list of paths to a single item.

[rainersigwald]

We talked about this briefly in triage yesterday. The general problem (many files could be copied to the same destination path) is hard to deal with (MSBuild doesn't track all outputs from every task, which would be necessary to detect a conflict), but this specific case should be catchable, because it's all happening within a single call to the Copy task.

This situation will become more common as more folks start using globs.

Would anyone object if I changed the title to "Copy Task should error on duplicate destination paths"?

[martinscholz83]

Would it be ok for all if i take this Issue and try to create a Solution within a PR?

[rainersigwald]

@maddin2016 I think an error on multiple-copy-to-same-location is valuable even if it doesn't satisfy everyone here. I wouldn't object to a PR for that.

[brthor]

Thanks for the attention on this 😄

Feel free to change the title @rainersigwald

[martinscholz83]

I have opened #1037.