Pin FileVersions in platform manifest for the ref packs in the servicing

[Anipik]

Currently when we build the ref packs, the platform manifest contains the fileversions with the buildNumber string (which will change when we build the ref pack in servicing).

This could cause problems as apps could only target against rtm tfm. We would like to pin the fileversions in the platform manifest to the 6.0.0 ref pack.

cc @ericstj @safern @jkoritzinsky

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

Issue Details

---

Currently when we build the ref packs, the platform manifest contains the fileversions with the buildNumber string (which will change when we build the ref pack in servicing).

This could cause problems as apps could only target against rtm tfm. We would like to pin the fileversions in the platform manifest to the 6.0.0 ref pack.

cc @ericstj @safern @jkoritzinsky

Author:	Anipik
Assignees:	-
Labels:	area-Infrastructure-libraries, blocking-servicing, untriaged
Milestone:	-

[ericstj]

We need to decide the best way to freeze the data files in the ref-pack during servicing. They need to represent the "GA" state of the product since the ref-pack represents a minimum version of the runtime for a given target framework (eg: net6.0).

ASP.NET achieves this by checking in the GA version of these files. Shown here:
https://github.com/dotnet/aspnetcore/blob/4e47fd8f759dbdeeadadf689cd4e60c614932ae3/src/Framework/App.Ref/src/Microsoft.AspNetCore.App.Ref.csproj#L59-L60

We haven't done this yet for runtime since we haven't serviced the ref-pack before, but we need to do that in 6.0.

@jkoritzinsky what do you suppose is the best way to handle this scenario in the shared framework SDK? Should we check in the file like ASP.NET does, or should we do something else to freeze to the GA data?

[jkoritzinsky]

I think freezing the data files makes sense. We'll need to add an option in the shared framework sdk (probably just a property to set) that would skip all of the data file generation steps. Then in dotnet/runtime, we'd add the files manually with matching MSBuild item metadata to what the shared framework sdk does.

[ericstj]

I see, so we create an item like this:
https://github.com/dotnet/arcade/blob/1672ddac621ecce7cb51354347f622a2becd9e80/src/Microsoft.DotNet.SharedFramework.Sdk/targets/sharedfx.targets#L365
And add it to FilesToPackage like it's done here:
https://github.com/dotnet/arcade/blob/1672ddac621ecce7cb51354347f622a2becd9e80/src/Microsoft.DotNet.SharedFramework.Sdk/targets/sharedfx.targets#L376

Then add a condition on this target
https://github.com/dotnet/arcade/blob/1672ddac621ecce7cb51354347f622a2becd9e80/src/Microsoft.DotNet.SharedFramework.Sdk/targets/sharedfx.targets#L362-L363

Perhaps '$(CreatePlatformManifest)' != 'false'

Does that sound right?

[jkoritzinsky]

Yes, I think that would work well.