Enable servicing features without stabilizing the build in blazor-wasm

[wtgodbe]

WIP of using servicing features without stablizing.

Right now, every build of the blazor-wasm branch is marked stable, which means every build publishes packages to a unique feed. The goal is to have all blazor-wasm packages published to one feed (except when we actually want to build stable packages). We still need to enable servicing features, though, because we need to always build against the latest stable packages available (that is, what's in the baseline).

This PR does the following things:

• Always build against what's in the baseline for implementation assemblies (never use latestPackageReference or ProjectReference)
• Add explicit ProjectReferences between Blazor projects
• Update the baseline to 3.1.1
• Use baseline package versions for projects trying to determine PackageVersions of other projects

[dougbu]

Looks good but two template test failures look real e.g.

error NU1603: Microsoft.AspNetCore.Components 3.1.0-ci depends on Microsoft.AspNetCore.Authorization (>= 3.1.0-ci) but Microsoft.AspNetCore.Authorization 3.1.0-ci was not found. An approximate best match of Microsoft.AspNetCore.Authorization 3.1.0-preview1.19465.3 was resolved.

[wtgodbe]

CC @pranavkm @javiercn @JunTaoLuo - this should let us publish all the blazor-wasm stuff to the blazor-wasm feed, once I get the tests working. Note that you'll have to manually flip the "stable" bit back to true when you want to ship stable.

[pranavkm]

I guess. I don't know what this PR means 😿

[JunTaoLuo]

Theoretically this should work but the template tests says otherwise.

[wtgodbe]

error NU1603: Microsoft.AspNetCore.Components 3.1.0-ci depends on Microsoft.AspNetCore.Authorization (>= 3.1.0-ci) but Microsoft.AspNetCore.Authorization 3.1.0-ci was not found. An approximate best match of Microsoft.AspNetCore.Authorization 3.1.0-preview1.19465.3 was resolved.

This would be because the package for Microsoft.AspNetCore.Authorization isn't getting built. Will look into how these tests work when non-stable

[wtgodbe]

It's because when we're stable, the packages in the template tests depend on stable versions, which exist on nuget.org. I believe we always want that to be the case, correct @javiercn @pranavkm?

[wtgodbe]

Likely related to

aspnetcore/src/Components/Components/src/Microsoft.AspNetCore.Components.csproj

Lines 34 to 44 in 05f2430

	<Target Name="_GetNuspecDependencyPackageVersions">
	<MSBuild Targets="_GetPackageVersionInfo"
	BuildInParallel="$(BuildInParallel)"
	Projects="../../Analyzers/src/Microsoft.AspNetCore.Components.Analyzers.csproj;../../../Security/Authorization/Core/src/Microsoft.AspNetCore.Authorization.csproj">
	<Output TaskParameter="TargetOutputs" ItemName="_ProjectPathWithVersion" />
	</MSBuild>
	<ItemGroup>
	<NuspecProperty Include="@(_ProjectPathWithVersion->WithMetadataValue('PackageId', 'Microsoft.AspnetCore.Components.Analyzers')->'componentAnalyzerPackageVersion=%(PackageVersion)')" />
	<NuspecProperty Include="@(_ProjectPathWithVersion->WithMetadataValue('PackageId', 'Microsoft.AspnetCore.Authorization')->'authorizationPackageVersion=%(PackageVersion)')" />
	</ItemGroup>
	</Target>

, looking into it

[wtgodbe]

Something more sinister going on here - we're not building against baseline versions because IsServicingBuild isn't resolving to true. We just build against what the repo thinks it's producing, which is 3.1.0, which happens to be on nuget.org. I'll get this fixed up so that we don't produce stable versions, but do build against the baseline.

[javiercn]

@wtgodbe I'm not super sure how this works, tbh. I'm looking at you for ideas/proposals. As long as the assemblies we build reference the latest released patch for the 3.1 train, we are good.

[wtgodbe]

I'm not super sure how this works, tbh. I'm looking at you for ideas/proposals. As long as the assemblies we build reference the latest released patch for the 3.1 train, we are good.

I have an idea for a fix here, which will involve updating the baseline files, enabling servicing features in this branch, and fixing package version resolution for the template tests. I understand today is code complete for preview1, so I'll get the fix in for preview2. Preview1 is built against 3.1.0 packages.

[wtgodbe]

@dougbu can you PTAL? Might be some more to be done here to achieve the goal, which is to always build against the baseline, except for blazor projects referencing each other.

[dougbu]

Suspect you need to back up a bit on our various servicing changes

1. restore PatchConfig.props and update it to contain the packages we actually want to ship from this branch (I suggest unconditionally so the file doesn't need to change unless we add new packages)
2. set $(IsPackageInThisPatch) using that file (restoring old logic in Directory.Build.*)
3. change the condition at https://github.com/dotnet/aspnetcore/blob/blazor-wasm/Directory.Build.targets#L73 to use the baseline version in this branch -- despite $(IsServicingBuild) being false

[dougbu]

Please ping when the validation builds start looking better

[wtgodbe]

F:\workspace_work\1\s.dotnet\sdk\3.1.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.PackageDependencyResolution.targets(234,5): error NETSDK1004: Assets file 'F:\workspace_work\1\s\artifacts\obj\Microsoft.AspNetCore.Routing\project.assets.json' not found. Run a NuGet package restore to generate this file. [F:\workspace_work\1\s\src\Http\Routing\src\Microsoft.AspNetCore.Routing.csproj]

Could be that References that weren't resolved to ProjectReferences before, now are, and the projects in question never run Restore because they're not in ProjectsToBuild. Lookin' into it

[wtgodbe]

Looks like the projects in question were transformed to ProjectReferences both before and after my change, but before my change, they did have Restore run in them early enough for the build to find their assets files. That's no longer the case after my change. Looking at why.

[wtgodbe]

Before my change, calling _GetAllRestoreProjectPathItems on Microsoft.AspNetCore.Components.Authorization returns a list of 6 AspNetCore projects, while after, it returns only Microsoft.AspNetCore.Components.Authorization itself. Still investigating

[wtgodbe]

Ah, it's because I've moved the conversion of References into ProjectReferences from a static location in ResolveReferences.targets, to within the ResolveCustomReferences target, which comes after the Restore target. Need to figure out a way to work around that, given our desire to use Baseline references where possible in favor of ProjectReferences.

[wtgodbe]

Superseded by #18894