WPF Application Always Rebuilds In Visual Studio

This was previously reported on GitHub to the MSBuild Team (https://github.com/Microsoft/msbuild/issues/4228) who suggested I open a Visual Studio Support Ticket.

Background

In attempting to reproduce the issue for #4217 I attempted to create a fresh WPF Project to see if I could reproduce it; in doing this I encountered a similar (but I do not believe identical) issue wherein the MainWindow.g.cs was always regenerated.
Steps to reproduce

Please find an attached zip file that contains the project that demonstrates this behavior: WpfAppAlwaysRebuilds.zip

This project was created by:

Creating a new WPF Application within Visual Studio
Modifying the CSPROJ To contain the work around for #1648 as follows

<Target Name="GenerateCompiledExpressionsTempFile">
<!--This is a no-op to overwrite the existing target that ships with MSBuild. When we upgrade to Visual Studio 2019 (MSBuild 16.0) we can remove this. See https://github.com/Microsoft/msbuild/issues/1648-->
</Target>

To reproduce the issue on the command line build the project

msbuild WpfAppAlwaysRebuilds.sln /t:Build

Then launch the Solution in Visual Studio and build you will see this in diganostic verbosity:

Project 'WpfAppAlwaysRebuilds' is not up to date. Input file 's:\temp\markupbug\wpfappalwaysrebuilds\wpfappalwaysrebuilds\obj\debug\mainwindow.g.cs' is modified after output file ''.
------ Build started: Project: WpfAppAlwaysRebuilds, Configuration: Debug Any CPU ------

Note that in order to repeat it a second time you MUST delete the contents of the /obj/ folder to start "clean" again. Once it has built in Visual Studio once MSBuild will happily report that it is up to date.

Expected behavior

The expected behavior is that this project will report as "up-to-date"

Actual behavior

The project rebuilds because it determines that it is not "up-to-date"

@livarcocc The Workflow Fix requires the coordination between Dev16; however if you notice bullet 2 I have already worked around this; this is a NEW issue (even after the workflow one is corrected).

Here is the rebuild trigger:

1>Project 'WpfAppAlwaysRebuilds' is not up to date. Input file 'r:\wpfappalwaysrebuilds\wpfappalwaysrebuilds\wpfappalwaysrebuilds\obj\debug\mainwindow.g.cs' is modified after output file ''.

If this had been the workflow issue it would have been complaining about a *TemporaryGenerated.cs file.

This issue ends up being the same as the reference issue (although it took me a lot longer to get to that point in the reference issue):

When MSBuild compiles a WPF Application MarkupCompilePass1 is called PRIOR to all Compile inputs being calculated. One such task that adds additional compile items is GenerateTargetFrameworkMonikerAttribute
In Visual Studio GenerateTargetFrameworkMonikerAttribute is called PRIOR to MarkupCompilePass1
Because of the design of MarkupCompilePass1 there is another layer of incremental build caching: it is looking at the number of files used as inputs (as well as taking the hashes of their file names) to determine if it should run again or not. Because this added an additional Compile item in Visual Studio it will always rebuild.

The work around is to apply this into the ProjectFile which will temporarily fix you; but the real fix needs to happen in MSBuild to correctly call GenerateTargetFrameworkMonikerAttribute prior to MarkupCompilePass1:

<PropertyGroup>
<!--This is a hack to try and fix https://github.com/Microsoft/msbuild/issues/4228-->
<MarkupCompilePass1DependsOn>$(MarkupCompilePass1DependsOn);GenerateTargetFrameworkMonikerAttribute</MarkupCompilePass1DependsOn>
</PropertyGroup>

Its unclear who owns this; its either gotta be Visual Studio or the MSBuild team that changes to make this consistent otherwise you will ALWAYS rebuild in WPF.

_This issue has been moved from https://developercommunity.visualstudio.com/content/problem/503048/wpf-application-always-rebuilds-in-visual-studio.html
VSTS ticketId: 826388_
_These are the original issue comments:_
(no comments)
_These are the original issue solutions:_
(no solutions)