[release/6.0] DotNetHost packages are not created during source-build #60577
Conversation
The subset `host.pkg` is not producing the DotNetHost* NuGet packages. This is because the "Pack" target is getting invoked on the pkgprojs, but pkgprojs expect the "Build" target to be called. Since the "Pack" target is overriden in the Directory.Build.targets to be empty, no one is calling the "Build" target on the pkgprojs. In an official build, a later subset `packs.tests` comes through and builds `Microsoft.DotNet.CoreSetup.Packaging.Tests.csproj`, which explicitly calls "Build" on the pkgprojs. So official builds still get these packages produced. In source-build, we are no longer building the `packs.tests` subset, so the packages are not produced.
ghost
added
the
This should only be necessary until dotnet/runtime#60577 is merged.
|
I don't think we need this for In source-build, we have taken this change as a "patch" in 6.0.0 - dotnet/installer#12434 |
|
I thought that we don't use git patches anymore, especially now that every repository has their own source build leg and infrastructure? |
It's definitely not the preferred option - but it is still used to get unblocked, and in cases where the change shouldn't/can't be flown into the repos: https://github.com/dotnet/installer/tree/release/6.0.1xx/src/SourceBuild/tarball/patches |
|
@eerhardt Is this needed for 6.0? |
|
@mmitche - No, we have a source-build patch with these changes. Hopefully this will flow in 6.0.1 and we can remove the patch. |
|
I was concerned that this change could affect the official build somehow, so I was reluctant to get it merged into release/6.0 this late. The same change was merged into Since this isn't "required" for |
Backport of #60575 to release/6.0
/cc @eerhardt
Customer Impact
DotNetHost* packages are not created during source-build. So source-build is not valid since the SDK can't pick these packages up.
Testing
I tested source-build with this change, and it causes the packages to be built.
Risk
There is a risk this could break the official build. Given where we are in the release cycle, I would suggest we take this in the first servicing release. For source-build, we can use a patch for 6.0.0 to take this change - see dotnet/installer#12434.