Microsoft.AspNetCore.App.Ref needs to be produced and versioned correctly in servicing for source-build

[MichaelSimons]

Currently building release/6.0 for 6.0.1 doesn't produce a Microsoft.AspNetCore.App.Ref package. This is because the package wasn't serviced in 6.0.1. 6.0.0 is the active version yet the build doesn't produce it. This breaks source-build which needs to produce the entire product.

In previous versions, source-build handled this by treating the package as a reference package via https://github.com/dotnet/source-build-reference-packages. This is no longer an option in 6.0 with the introduction of roslyn analyzers (e.g source) in the package.

dotnet/runtime made changes in 6.0 to support this here.

[MichaelSimons]

cc @dougbu, @wtgodbe

[MichaelSimons]

@wtgodbe - I see this is in Next sprint can you give a rough idea of when we could expect a fix? I ask as this is currently a blocker for source-build.

[wtgodbe]

We're going to discuss it at standup today. It looks like the change is needed in 6.0, which means the earliest we could do it is likely 6.0.3 (March patch) as the February builds are already underway. Is it also needed in main? We can do it ASAP if there's an additional time constraint beyond the 6.0 releases

[MichaelSimons]

Yes a change is needed in 6.0 and it should be backported to main. We need a fix for 6.0.2 but if you have a fix, we can create a source-build patch for 6.0.2.

[wtgodbe]

@MichaelSimons we're actually servicing the ref pack again in 6.0.2, with version 6.0.2 - will that unblock source build? If so we can have the patch ready for 6.0.3 so that it continues producing the 6.0.2 targeting pack for source build. If not we'll get a fix ASAP and see if we can merge it for 6.0.2

[MichaelSimons]

@wtgodbe - That will work for 6.0.2 but source-built Fedora 6.0.1 was unable to release because of this issue. It would be most helpful if you could provide a fix that we could apply as a source-build patch to unblock.

[dougbu]

We're confused by this issue @MichaelSimons. The runtime code just sets a property for the previous version of the targeting pack. Does something else rebuild the targeting pack w/ that version in every servicing build (when doing a source build)❔

In any case, we already have a property w/ the version of the last targeting pack -- $(TargetingPackVersionPrefix). Our preference is to rebuild the targeting pack only when the contained ref/ assemblies or source generators require a fix. But, we could either always release a targeting pack everywhere or switch between shipping it (giving it a stable package version) or not for servicing releases. Today, the targeting pack (though not the installers) packing is turned on or off and the App.Ref project always builds.

It would be confusing to look at a build of 6.0.2 and see a 6.0.0 or 6.0.1 targeting pack. I also worry doing that would mess up the release. Is this exclusively about source-builds❔

I guess the general question is why Fedora and so on need a targeting pack every time. I thought their requirement was strictly runtime components❔

[MichaelSimons]

Does something else rebuild the targeting pack w/ that version in every servicing build (when doing a source build)❔

Yes - When building source-build this prevents SkipBuild from getting set.

Our preference is to rebuild the targeting pack only when the contained ref/ assemblies or source generators require a fix.

This does not work for source-build because it needs to build the full product. Pre-6.0 source-build was able to handle the targeting packs not getting built during servicing by treating them as ref packs (e.g. adding them to https://github.com/dotnet/source-build-reference-packages). With the introduction of the analyzers, this is no longer an option. I have no objection to your proposal to always release a targeting pack. It feels like this behavior is something that would ideally be the same between the runtime and aspnetcore.

cc @safern ^

It would be confusing to look at a build of 6.0.2 and see a 6.0.0 or 6.0.1 targeting pack. I also worry doing that would mess up the release. Is this exclusively about source-builds❔

This is specific to source-build at this time. This is something that would be needed if/when we move towards having reproducible builds. Also this would be the default behavior if/when we get to the point where source-build is the open build and then the MSFT build is a closed build. The last two have no concrete plans as of now.

I guess the general question is why Fedora and so on need a targeting pack every time. I thought their requirement was strictly runtime components❔

This is not Fedora specific rather it affects all source-build. I won't go into the details on why this is blocking Fedora and not RedHat here as it doesn't feel pertinent. The Microsoft build works because it is able to pull the previously build targeting pack from nuget. Source-build has to build the entire product stand-alone offline so it can't access artifacts from previous releases.

cc @crummel, @omajid - to correct anything I may have mis-stated.

[dougbu]

🆗 I can see why building our stuff in the aspnetcore repo against the previous targeting pack would break source-build.

Do you specifically need

1. A build that doesn't require the previous targeting pack i.e. remove reliance on the old ref/ assemblies❔
2. A .nupkg for Microsoft.AspNetCore.App.Ref in every build (stable-versioned or not)❔
3. A targeting pack installer (.rpm file) that's always built at least when doing source-build❔

[MichaelSimons]

Do you specifically need

We need #2

[wtgodbe]

Does it need to match the last stable version on nuget.org, or could we create a new non-stable version each month? I lean towards doing the former if it doesn't break maestro, as the latter would mean upstream repos ingesting new non-stable targeting packs every month. If we do the former we'd only do it in source build (@mmitche would that wind up in the asset manifest/dependency flow?)