CopyToOutputDirectory Does Not Respect PreserveNewest and TargetPath

[benvillalobos]

Hello @benvillalobos. Now that version 16.10 has been released, I am able to test. Unfortunately, I think this change exchanged one problem for another.

<Content Include="Files\**">
  <Link>Files\%(Filename)%(Extension)</Link>
  <TargetPath>%(Filename)%(Extension)</TargetPath>
  <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
</Content>

I have verified the correctness of the first two lines (i.e. the Link and TargetPath elements). However, the last line with the CopyToOutputDirectory element is not working. After completing the first build, if I tell Visual Studio to build again, then it builds the project instead of correctly saying that it is update to date.

I tested by modifying the MWE I provided in my original VSDC isssue.

Originally posted by @TysonMN in dotnet/msbuild#6237 (comment)

[benvillalobos]

I wonder if CopyToOutputDirectory checks an item's Link metadata for up-to-date-ness. Need to get command line binlogs.

[rainersigwald]

This could also be a problem with the project system's fast up-to-date check. Might be interesting to up their verbosity (tools -> options -> Projects and Solutions -> SDK-style Projects -> Up to Date Checks -> Logging Level) and see what they say.

[TysonMN]

@benvillalobos, thanks for creating this issue. As a nitpick, the copy paste didn't work correctly. There is some information missing. I avoid that problem by quoting the comment (i.e. click the three dots in the top-right corner and then select "Quote reply"), deleting the initial right angle brackets and spaces, and then copying that text.

[benvillalobos]

@TysonMN Weird, that seems to be an issue with 3 dots -> Reference in new issue

[TysonMN]

Great suggestion @rainersigwald. Here are the relevant portions of those logs (after optimizing the project structure for smaller logs).

1>FastUpToDate: Checking PreserveNewest file 'C:\A\Files\TextFile.txt': (ClassLibrary1)
1>FastUpToDate:     Source 5/27/2021 7:54:59 AM: 'C:\A\Files\TextFile.txt'. (ClassLibrary1)
1>FastUpToDate: Destination 'C:\A\bin\Debug\netstandard2.0\Files\TextFile.txt' does not exist, not up to date. (ClassLibrary1)

The fast up-to-date check did not take into account the information given in the TargetPath element.

Specifically, it checked

C:\A\bin\Debug\netstandard2.0\Files\TextFile.txt

when it should have checked

C:\A\bin\Debug\netstandard2.0\TextFile.txt

[benvillalobos]

@TysonMN Aha! Does this also repro on a command line build?

[TysonMN]

I don't think so. It seems to me like the project is also being rebuilt when told to build from the command line. Here is the output. Do you have the same conclusion? If this is output is inconclusive, is there some way I can make it more conclusive (i.e. enable some more logging)?

C:\A>dir
 Volume in drive C has no label.
 Volume Serial Number is EEAA-DB41

 Directory of C:\A

05/27/2021  02:10 PM    <DIR>          .
05/27/2021  02:10 PM    <DIR>          ..
02/05/2021  04:17 PM                80 Class1.cs
05/27/2021  01:44 PM               395 ClassLibrary1.csproj
05/27/2021  01:55 PM             1,131 ClassLibrary1.sln
05/27/2021  01:55 PM    <DIR>          Files
               3 File(s)          1,606 bytes
               3 Dir(s)  23,863,943,168 bytes free

C:\A>dotnet build
Microsoft (R) Build Engine version 16.10.0+4242f381a for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  Restored C:\A\ClassLibrary1.csproj (in 307 ms).
  ClassLibrary1 -> C:\A\bin\Debug\netstandard2.0\ClassLibrary1.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:03.49

C:\A>dotnet build
Microsoft (R) Build Engine version 16.10.0+4242f381a for .NET
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  All projects are up-to-date for restore.
  ClassLibrary1 -> C:\A\bin\Debug\netstandard2.0\ClassLibrary1.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:01.36

[benvillalobos]

@TysonMN The best way to provide logs for us is with binary logs: aka.ms/msbuild/binlog

It'll output a .binlog file that you can share. Be aware it will include things like environment variables.

Weird that this class library project always builds, even if I remove everything but the target framework. Meanwhile creating a new dotnet new classlib and building twice doesn't build the second time (all on command line).

I do see Input file "obj\Debug\netstandard2.0\ClassLibrary1.GeneratedMSBuildEditorConfig.editorconfig" is newer than output file "obj\Debug\netstandard2.0\ClassLibrary1.dll". is the reason why the project is running CoreCompile (and therefore building). Which is running because the editorconfig file is always generated. But when debugging with @rainersigwald it magically stopped ._.

Verifying it doesn't happen on command line.

[benvillalobos]

Transferring to project system. We think the fast up to date check has to be updated to account for how MSBuild respects TargetPath metadata. We modified AssignTargetPaths to respect TargetPath when it's already set, where previously the Link metadata would take priority. See dotnet/msbuild#6237

[TysonMN]

Do still want some information from a binlog?

I created one, and I see private information in the environment variables, so I don't want share the whole thing. I looked around, but I wasn't able to find anything related to the fast up-to-date check.

P.S.
The Live Structured Log Viewer doesn't support binlogs with version 13, which is what I have.

[rainersigwald]

No thanks @TysonMN; the binlog doesn't contain any information on FUTD and I think we have enough to repro the problem locally.

[drewnoakes]

Triage notes: I can repro this. We currently plumb through Link metadata, but not TargetPath.

[drewnoakes]

Fixed in #7470.