C#/WinRT projection generation breaks incremental building

[llongley]

The CsWinRTGenerateProjection target in Microsoft.Windows.CsWinRT.targets always runs, which always generates new .cs files on build, which in turn causes the CSC task and anything downstream of it to run every time we build since it detects that the source files are newer than their products, even if nothing has actually changed. We should ensure that we only regenerate the C#/WinRT projection if something has changed. There are two options I can see for that:

1. Easier, but less elegant: Generate the projection .cs files to a temp folder, and compare the files generated to the existing files. Only if something in the newly generated files is different, copy them from the temp folder to the generated files folder.

2. Harder, but more elegant: Check the parameters and inputs to cswinrt.exe and only run the projection if something in them has changed. I believe this would include checking for any differences in $(CsWinRTParams) since the last time we ran cswinrt.exe, plus any differences in the contents of the files in @(CsWinRTInputs) since the last time we ran cswinrt.exe.

Option 2 would likely require saving to disk a file containing the state last time we ran cswinrt.exe that we'd compare against the next time we ran it. This is similar to what the XAML compiler does: it saves a file containing the reference DLLs used and the XAML files compiled, and only runs XAML compilation if either those lists have changed, or if the contents of those files has changed.

[Scottj1s]

@llongley - I can't repro this. cswinrt.exe works like cppwinrt.exe - it only writes files if their content changes. This is about the only reliable way to deal with multiple unknown inputs (winmd files), and outputs (*.cs files), and the opaque mapping between them (based on filters, etc). In other words, the tool always runs, but does its own dependency checking, and its output is conditional. When I build a test projection the first time, I see *.cs files created. When I run a subsequent build, I see none of them updated, and no csc.exe is run. Can you provide a repro or a binlog so we can see what the triggers are in your scenario?

[llongley]

Hmm, I can't repro this either. It might have been fixed in the intervening time, or I might have been mistaken. Either way, looks good now.