WPF Application Always Rebuilds In Visual Studio

[aolszowka]

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:

1. Creating a new WPF Application within Visual Studio
2. Modifying the CSPROJ To contain the work around for GenerateCompiledExpressionsTempFile does not clean up the files it creates #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"

Environment data

msbuild /version output:

Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
Copyright (C) Microsoft Corporation. All rights reserved.

15.9.21.664

OS info:
Windows Server 2012 R2

If applicable, version of the tool that invokes MSBuild (Visual Studio, dotnet CLI, etc):
Visual Studio 15.9.8

[livarcocc]

My understanding is that the fix there require a coordinated change for workflows as well that went in on Dev16. You are trying to apply a similar change and make it work on Dev15.

I don't believe that would be expected to work.

[aolszowka]

@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.

[livarcocc]

I think you should file a VS Feedback ticket so that the owners of WPF can take a look at this issue. This is not code that lives in the msbuild repo.

Meanwhile, I am going to close this issue.

[aolszowka]

Can you please point me to the location to properly report this to the owners of WPF? The bug itself only exhibits in MSBuild for what its worth; Visual Studio does the correct thing.

[weltkante]

Note that {Target}DependsOn properties do not work in "new style" SDK projects if they use implicit imports (the default) so the workaround only applies to classic projects.

[KirillOsenkov]

@livarcocc hey Livar, I feel like this bug report has valuable information in it, and other issues spawned off of this one aren't getting the hoped traction. Would be you OK with reactivating this issue and giving it another look?