Set PackageValidationBaselineName to assemblyName when packageID is not set

[Anipik]

Fixes issue in dotnet/runtime#54250

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label.

[ViktorHofer]

In which cases is PackageId not set?

[Anipik]

In which cases is PackageId not set?

Its being set late during the sdk evaluation.

[ViktorHofer]

Its being set late during the sdk evaluation.

Doesn't that mean that PackageId is never used then?

[Anipik]

Doesn't that mean that PackageId is never used then?

unless its a global property

[ViktorHofer]

unless its a global property

which is never the case usually.

[Anipik]

which is never the case usually.

setting the packageID in the csproj would be another scenario.

[ViktorHofer]

setting the packageID in the csproj would be another scenario.

That's also very rarely the case for projects unless they would want to override it.

You could easily avoid this sequencing issue by inlining the PackageValidationBaselineName value into the two locations where it's used:

• The PackageDownload item
• In the task as a property later

By inlining it, you will only access the PackageId value after it is set by NuGet. And with that you can then remove the AssemblyName fallback scenario as well.

[ViktorHofer]

LGTM module the one remaining feedback item.