Ingest and import Windows Forms analyzer props

[RussKie]

Description

This work relates to Streamline Windows Forms application configuration and bootstrap design proposal, and acts as a workaround until Proposal to add Framework specific inbox source generators design proposal is approved and implemented.

Provide a mechanism to ingest Windows Forms specific analyzer props into Microsoft.NET.Sdk.WindowsDesktop from Windows Forms transport package, and copy the props file into targets folder of the SDK, so that the props file is resolved and imported when a developer builds a Windows Forms app.

In the end the new props file will end up in a location similar to this: C:\Program Files\dotnet\sdk\6.0.<version>\Sdks\Microsoft.NET.Sdk.WindowsDesktop\targets\.

The build process looks something like this:

• import props and targets
  
  
• execute the task that resolves and references Windows Forms analyzers:
  

Testing

A lot of manual testing

1. Create a Windows Forms transport package, e.g.: winforms> .\build.cmd -pack
2. Copy the build transport package from .\winforms\artifacts\packages\Debug\NonShipping over the currently referenced by WPF microsoft.private.winforms package in C:\Users\<user>\.nuget\packages\microsoft.private.winforms
3. Build and pack WPF: wpf> .\build -pack
4. Inspect .\wpf\artifacts\packaging\Debug\Microsoft.NET.Sdk.WindowsDesktop.Debug\targets folder and see System.Windows.Forms.Analyzers.props and System.Windows.Forms.Analyzers.targets present

[vatsan-madhavan]

This is an antipattern. Foo.*ArchNeutral.csproj, Foo.csproj etc. have certain conventions, and they weren't intended to be spots for additional domain-specific targets. Our domain-specific targets - in fact all of this repos' build-related intelligence - lives under a certain hierarchy under eng\ that I've already alluded to. There are rare well-considered exceptions to this rule - and this does [edit] not [/edit] strike me as one.

[vatsan-madhavan]

I haven't read the docs you've shared, but my sense/guess here is that analyzer related props/targets is a new category of payload that's being introduced. If this is right... then consider introducing a new Item name, something like AnalyzerPackagingContent that's used to track these items. These would become agnostic of WPF/Winforms etc. far as build-logic goes.

Then in Packaging.targets, add logic specific to validation of these. For e.g., anything that's been added to AnalyzerPackagingContent - ensure that they exist, make sure they're added to PackagingContent etc.. Then all you'd do in *.WindowsDesktop.ArchNeutral.csproj is adding your props/targets to the newly introduced AnalyzerPackagingContent Item and let the backend targets do its work as before.

[RussKie]

I added this target purely to perform verifcations as you suggested earlier.
All work is done by these targets https://github.com/RussKie/winforms/blob/project_configuration/src/System.Windows.Forms.Analyzers/src/System.Windows.Forms.Analyzers.targets

[RussKie]

The reason I added this target in this project and not in Directory.Build.targets at other levels is these validations is only relevant to this project. I'm happy to move it out to a separate targets file under eng\ folder and reference it in this project.

[vatsan-madhavan]

A different architecture is fine, but this project is not the right place for adding targets, imports etc. - if you need to extend or hook the build system, it has to be done elsewhere.

[RussKie]

Does 9c0757e look better?

[RussKie]

Tested using an experimental pipeline: