Version.Details.xml dependencies are not flowing properly into Version.Details.props, causing invalid removal of dependencies

[nagilson]

Pull request

dotnet/sdk#52028

Type of problem

Problem with version files (Versions.Details.xml, Versions.props, global.json, ..)

Description of the issue

nagilson/sdk@3c15958

In this commit, @mmitche helpfully reflected on how we shouldn't use Microsoft.Dotnet.WinForms.ProjectTemplates in Version.Details.xml and that these flows have special properties for VMR builds on non windows. However, what we're seeing now is that in Version.Details.Props, these dependencies are being deleted, which is causing failures in our code flow, for example in dotnet/sdk#51895.

https://github.com/dotnet/sdk/pull/51895/files#diff-3a6dd62fefc313c2ae46c8eb7999a76e089076d8445bc49e710f37d52b8c63deL105

Here is an example where MicrosoftDotnetWinFormsProjectTemplatesPackageVersion was automatically removed by codeflow - this is despite the fact that Microsoft.NETCore.Platforms is defined in Version.Details.xml.

dotnet/sdk#51895

This was discussed here, dotnet/sdk#52028 (comment), and how we were surprised that this deletion was happening. Perhaps some of the logic that syncs the props files is not aware of the special casing so it's removing the dependencies?

[mmitche]

@nagilson I think maybe something got lost here. There's no special casing for properties in Version.Details.xml and Version.Details.props. The props file is determined by the content of the xml.

the hotreload property being deleted is expected, as it didn't have a corresponding Version.Details.xml entry.

The comment re: Winforms project templates is no longer accurate (as of the head of the VMR tree, since the VMR now produces those packages across all platforms.

[dkurepa]

Hi Noah, as Matt mentioned, this is actually by design. If a dependency gets removed from Version.Details.xml, the next time there's any dependency update (this can happen during a backflow, or a dependency update from a different repo), Version.Details.props will be regenerated based on what is in the Version.Details.xml

So in this case, the dependency got removed from the .xml file, but not the .props file, and then during these following dependency flows, the file got regenerated as expected.
If your repo still needs these props defined, they should go to Versions.props, this file is meant for all properties not managed by Maestro

[nagilson]

Thank you.

Winforms project templates is no longer accurate (as of the head of the VMR tree, since the VMR now produces those packages across all platforms.

In which way is it no longer accurate? Do you mean the template is wrong? Or, that the VMR doesn't need that package, so we removed it from details.xml and the SDK should add it manually? Or, do you mean that the dependency we take is platform specific, but we should use a platform agnostic package?

[ViktorHofer]

Just to share here again, I don't believe there is any revert problem here. See dotnet/sdk#52028 (comment)

[mmitche]

Thank you.

Winforms project templates is no longer accurate (as of the head of the VMR tree, since the VMR now produces those packages across all platforms.

In which way is it no longer accurate? Do you mean the template is wrong? Or, that the VMR doesn't need that package, so we removed it from details.xml and the SDK should add it manually? Or, do you mean that the dependency we take is platform specific, but we should use a platform agnostic package?

The comment in the Version.Details.xml was mentioning not to use the project template properties since they weren't produced. However, as of later 10.0 previews, those are produced in all builds of the VMR.