Inline package descriptions and remove descriptions.json files across the repo

[ViktorHofer]

Please review by commits.

1. Deleting the PackageDescriptionFile files (descriptions.json) and converting the json data to the PackageDescription msbuild property. Storing the data in the leaf's Directory.Build.props file to ensure that both the current .pkgproj and the .csproj files will respect it.
2. Handle PackageDescription concats centrally for runtime disclaimer
3. Removing NuGet 3.x disclaimer as the official usage data shows that hardly anyone is using such old clients.
4. Deleting the special handling and the printed SHA in the installer packages as all packages have the SHA listed in nuspec now.
5. Updating the Arcade packaging pkg to allow define the PackageDescription or Description in the project file.
6. Minor MSBuild project file cleanup (only in installer, coreclr and mono).

I'm validating the change right now offline by comparing the generated nuspecs.

Contributes to converting pkgprojs to csproj (couldn't fine an issue).

[ghost]

Tagging subscribers to this area: @ViktorHofer
See info in area-owners.md if you want to be subscribed.

Issue Details

---

1. Deleting the PackageDescriptionFile files (descriptions.json) and converting the json data to msbuild property and items. Storing the data in the leaf's Directory.Build.props file to ensure that both the current .pkgproj and the .csproj files will respect it.
2. Handle PackageDescription conacts centrally for runtime disclaimer and removing NuGet 3.x disclaimer as usage data shows nearly no one using it in the last six months. Deleting the special handling in installer which isn't necessary anymore.
3. Updating the Arcade packaging pkg to allow define the PackageDescription or Description in the project file.
4. Minor MSBuild project file cleanup (only in installer, coreclr and mono).

Contributes to converting pkgprojs to csproj (couldn't fine an issue).

Author:	ViktorHofer
Assignees:	ViktorHofer
Labels:	area-Infrastructure
Milestone:	-

[safern]

Skimmed through. Overall looks good. 2 notes:

I wonder if the support for this should be in the SDK we use to build packages.

We need to update arcade to remove obsolete stuff:
https://github.com/dotnet/arcade/blob/740732d1c0ddfb18e614bb93f93518f74d89bdca/src/Microsoft.DotNet.Build.Tasks.Packaging/src/build/Packaging.targets#L73

https://github.com/dotnet/arcade/blob/ca7fab569267ed3bc73360882d652d119aae5653/src/Microsoft.DotNet.Build.Tasks.SharedFramework.Sdk/targets/framework.packaging.targets#L122

https://github.com/dotnet/arcade/blob/ca7fab569267ed3bc73360882d652d119aae5653/src/Microsoft.DotNet.Build.Tasks.Packaging/src/GetPackageDescription.cs#L80

And we need to error out if there is no Description set for a package.

[ViktorHofer]

I wonder if the support for this should be in the SDK we use to build packages.

We aren't using any target/task and only setting properties. What would you imagine to be handled by that SDK?

[ViktorHofer]

We need to update arcade to remove obsolete stuff:

I'm not planning to remove logic from that SDK as the goal is to replace the entire SDK by a new one. I submitted a PR yesterday to disable some of it's functionality to allow the modifications in this PR: dotnet/arcade@de751cf.

https://github.com/dotnet/arcade/blob/ca7fab569267ed3bc73360882d652d119aae5653/src/Microsoft.DotNet.Build.Tasks.SharedFramework.Sdk/targets/framework.packaging.targets#L122

That SDK isn't used by dotnet/runtime anymore and @jkoritzinsky will remove it as soon as all consumers have switched to the new one.

And we need to error out if there is no Description set for a package.

I didn't know that this is a requirement. We have numerous conditions in master already that check on if '$(Description)' == '' which made me believe that we allow empty descriptions.

EDIT: While iterating on this PR I noticed that the current infra already protects against this. If no Description or PackageDescription is set, this branch will be entered and the task fails as a descriptions.json isn't passed in: https://github.com/dotnet/arcade/blob/3ba79fbd73d6765b67d0f75ac9dac148d6bea346/src/Microsoft.DotNet.Build.Tasks.Packaging/src/build/Packaging.targets#L864.

If we want to force people setting a description, then this could be easily be achieved via an InitialTarget (which its designed use-case is validation :)). I would not add this as part of this PR as I would condition it on IsPackable which isn't set yet in libraries.

[safern]

I've seen that it is pretty common for people to add a new package and miss the description and the error is pretty helpful. So I think we should add the validation as part of this PR and then update once the IsPackable work is done.

We need to disable/remove the task that validates and gets the package description from the descriptions.json file though.

[ViktorHofer]

I've seen that it is pretty common for people to add a new package and miss the description and the error is pretty helpful. So I think we should add the validation as part of this PR and then update once the IsPackable work is done.

The existing validation is already sufficient. It throws if neither Description or PackageDescription are set. As an example:

C:\Users\vihofer\.nuget\packages\microsoft.dotnet.build.tasks.packaging\6.0.0-beta.20621.6\build\Packaging.targets(864,5): error : DescriptionFile 'C:\git\runtime3\src\libraries\Microsoft.Extensions.HostFactoryResolver\pkg\path to descriptions.json must be specified' does not exist [C:\git\runtime3\src\libraries\Microsoft.Extensions.HostFactoryResolver\pkg\Microsoft.Extensions.HostFactoryResolver.Sources.pkgproj]

That's why I believe we can merge this as-is and then immediately follow-up on the IsPackable change and add an initial target to validate the PackageDescription or Description property being set for packages so that the error message is not misleading.

We need to disable/remove the task that validates and gets the package description from the descriptions.json file though.

As said, I already opted-out of that target via a switch and it will only throw if both Description and PackageDescription aren't set. That code path won't be reached with the follow-up PR that will validate in an InitialTarget. I don't see a reason why that code path should be further conditioned or deleted. Thanks for the feedback, I will prepare the follow-up change after this is in.

[ghost]

Hello @ViktorHofer!

Because this pull request has the auto-merge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

[ViktorHofer]

Validated the nuspecs offline for all different subsets and all looks correct now.