Underbuild in Visual Studio when using ref assemblies

[rainersigwald]

Issue Description

Normal development operations can result in MSBuild and Visual Studio deciding that a project is up to date and skipping its build, resulting in debugging or running tests on code that doesn't include the latest changes.

A workaround is available: #6917 (comment)

Steps to Reproduce

In a solution with three class libraries, C referencing B referencing A, all using reference assemblies (targeting .NET 5.0+):

1. Build solution.
2. Make changes to project C.
3. Build.
4. Make internal changes to source files of project B.
5. Build in Visual Studio.

Expected Behavior

Projects B and C build; B.dll in the bin folder of C is the latest version.

Actual Behavior

Only project B builds, project C is considered up to date with a log entry like

3>FastUpToDate: Output marker 'C:\Users\raines\source\repos\IncrementalUnderbuild\C\obj\Debug\net5.0\C.csproj.CopyComplete' does not exist, skipping marker check. (C)

Analysis

This is happening because IncrementalClean will delete the .CopyComplete marker file on a build that didn't need to copy references because they were all up-to-date (the build from step 3 that affected only C).

That's happening because the marker is only added to the @(FileWrites) item (which means "files that would have been created by a clean build of this project") if it needed to be touched:

msbuild/src/Tasks/Microsoft.Common.CurrentVersion.targets

Lines 4834 to 4838 in bbb9655

	<Touch Files="@(CopyUpToDateMarker)"
	AlwaysCreate="true"
	Condition="'@(ReferencesCopiedInThisBuild)' != '' and '$(WroteAtLeastOneFile)' == 'true'">
	<Output TaskParameter="TouchedFiles" ItemName="FileWrites" />
	</Touch>

So IncrementalClean decided it was a stale output and decided to delete it.

That bug has been present for a very long time (since #2878) but was masked by #6576, which caused the marker to be touched any time the project built. Since that was fixed in Visual Studio 16.11.4, it revealed this (worse!) bug.

[rainersigwald]

Thanks to @BrennanConroy, @jcouv, @jaredpar, and @jasonmalinowski who have been reporting this offline and getting logs, and to @drewnoakes who paired with me to debug it.

[rainersigwald]

Workaround

Add this target to your affected projects:

<!-- Prevent underbuild in Visual Studio, https://github.com/dotnet/msbuild/issues/6917 -->
<Target Name="WorkAroundDotnetMsbuild6917" AfterTargets="_CopyFilesMarkedCopyLocal">
  <ItemGroup>
    <FileWrites Include="@(CopyUpToDateMarker)" />
  </ItemGroup>
</Target>

This can be added to a Directory.Build.targets in your repo or applied to all projects you build by putting it in MSBuildUserExtensionsPath, which is %LOCALAPPDATA%\Microsoft\MSBuild. For instance on my machine I created

C:\Users\raines\AppData\Local\Microsoft\MSBuild\Current\Imports\Microsoft.Common.props\ImportAfter\WorkaroundMSBuild6917.props

with the contents

<Project>
  <!-- Prevent underbuild in Visual Studio, https://github.com/dotnet/msbuild/issues/6917 -->
  <Target Name="WorkAroundDotnetMsbuild6917" AfterTargets="_CopyFilesMarkedCopyLocal">
    <ItemGroup>
      <FileWrites Include="@(CopyUpToDateMarker)" />
    </ItemGroup>
  </Target>
</Project>

This workaround will not conflict with the real fix once it is available, so it can be adopted and removed much later.

[benvillalobos]

Note on the workaround: you may need to add Condition="'@(ReferenceCopyLocalPaths)' != ''" to the target for it to work correctly.