Add 'RunCsWinRTGenerator' task and target

[Sergio0694]

This PR adds supporting infra for CsWinRT 3.0 (see here):

• A RunCsWinRTGenerator task that runs cswinrtgen
• A target that loads and invokes the task as needed

Everything is opt-in and off-by-default.

[Sergio0694]

Here we need to get the path to the root directory of the Microsoft.Windows.SDK.NET.Ref package that's going to be used. Not sure how to get it from here though.

[baronfel]

If there's a packageref to this package (implicit or explicit), there may be a PackagePath_MIcrosoft_Windows_SDK_NET_Ref MSbuild property already ambiently available. Check a binlog and see?

[Sergio0694]

Tried in a blank app targeting net9.0-windows10.0.26100.0, not seeing that variable 🥲
Is this something we could configure in the .NET SDK? Since it's the one adding this 🤔

[Sergio0694]

We need two things here:

• @(CsWinRTGeneratorInteropAssemblyPath) needs to be copied to the output directory
• @(CsWinRTGeneratorInteropAssemblyPath) also needs to be added to .deps.json

I'm not sure how to do both. I could do it by adding the item to both ReferencePath, UserRuntimeAssembly, and IntermediatePath, but that doesn't seem correct. What is the right way to achieve this?

[baronfel]

Will need to look into answers for both of these, I'll try to do that tomorrow.

[Sergio0694]

Ideally, this target would only run if something changed. As in, if there's been any code changes or if any transitive dependency changed. I'm assuming the Csc task that's invoked in CoreCompile would already be doing some kind of check like that, to skip work if eg. you just F5 again without changing anything. Is there a way for us to perform the same check (or get that result out of CoreCompile) so we can also skip this target if not needed?

[baronfel]

This concept is known as incrementality. The short form is that if you know your inputs, and your inputs are files whose timestamps can be tracked, then you can set Inputs=..all that stuff.. on your Target and the MSBuild engine will transparently track them and only call your target if any of them are out of date. Similarly, if you know your Outputs, you can provide those to the engine as well and up-to-date checking will take place.

This means that many complex Targets often have a 'compute the inputs and outputs for Target XXXXX' Target that runs immediately before them, so that you can compute the correct set of inputs/outputs for incrementality purposes.

[Sergio0694]

Thank you! I added the Inputs property. I have a couple more questions though:

• I don't know the exact output path in advance, as that's computed by the target. I get that via that CsWinRTGeneratorInteropAssemblyPath item that the target produces as output. Is there a way to configure that returned item as the Outputs item for the wrapping task?
• I also need to re-run the target if any of the other input properties changes. The docs seem to only talk about input/output items. How can one handle incrementality with respect to properties as well? 🤔

Thank you!

[baronfel]

For the first point, we usually try to have those paths be able to be input into the Task to help with this kind of incrementality.
For the second, this is a gap in the MSBuild Incrementality model - it only supports files today. To get around this, most people have a 'generate property cache file' Target that they have run immediately before their real Target and they add this generated file to their Inputs. You can see an example of this pattern here.