Fix publishing symbols for dotnet and hostpolicy
#58844
Conversation
|
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov Issue DetailsThe symbols for It looks like we are currently relying on the symbol packages for The That package includes a target that sets the However, the targets of that package are imported before the project's As a result, the symbol packages built by This was an unfortunate side effect of #57036. This change goes back to having
|
|
/backport to release/6.0 |
|
Started backporting to release/6.0: https://github.com/dotnet/runtime/actions/runs/1218613773 |
ghost
locked as resolved and limited conversation to collaborators
2 participants
The symbols for
dotnetandhostpolicyare not being published to the public Microsoft symbol servers.It looks like we are currently relying on the symbol packages for
Microsoft.NETCore.DotNetHostandMicrosoft.NETCore.DotNetHostPolicyto get symbols fordotnetandhostpolicypublished.The
pkgprojprojects in installer have aPackageReferencetoMicrosoft.DotNet.Build.Tasks.Packaging:runtime/src/installer/pkg/projects/Directory.Build.props
Line 129 in f7b441d
That package includes a target that sets the
SymbolPackageOutputPathbased on thePackageOutputPath.https://github.com/dotnet/arcade/blob/main/src/Microsoft.DotNet.Build.Tasks.Packaging/src/build/Packaging.targets#L63
However, the targets of that package are imported before the project's
Directory.Build.targets, which imports Arcade targets that set the default forPackageOutputPath:https://github.com/dotnet/arcade/blob/main/src/Microsoft.DotNet.Arcade.Sdk/tools/ProjectDefaults.targets#L22
As a result, the symbol packages built by
src/installer/pkg/projects/*.pkgprojend up in the wrong directory - For example, underartifacts\bin\<project_name>\Releaseinstead ofartifacts\packages\Release\Shipping- such that they do not get uploaded and published.This was an unfortunate side effect of #57036.
This change goes back to having
SymbolPackageOutputPathexplicitly set. It is not really intuitive / great, but given the desire to stop having these packages (#35244, which will also need to make sure symbol publishing is covered by other things) and my expectation that we should backport to 6.0, I went with the simply bringing back the previous behaviour.cc @dotnet/runtime-infrastructure @jkoritzinsky @vitek-karas