Runtime: Unable to build a custom version of the dotnet/runtime repository with a suffix.

[gleocadie]

Description

At Criteo, we build our own custom CLR. We do this because we have changes in the CLR that are specifics to our use-cases and it won't be accepted upstream (already discussed).

To have my _dotnet-runtime-5.0.0-criteo1.tar.gz_ artifact, I use the command:
./build.sh -c Release /p:VersionSuffix=criteo1

Then I looked at the _artifacts/packages/Release/Shipping/_ folder to get the artifact and use it.

Steps to reproduce (without applying the patches):

git clone https://github.com/dotnet/runtime
cd runtime
git checkout -b 5.0.0-rtm-criteo1 v5.0.0-rtm.20519.4
./build.sh -c Release  /p:VersionSuffix=criteo1

Since the RTM, I got these errors

Build FAILED.

/build/runtime/src/installer/pkg/projects/netcoreapp/sfx/Microsoft.NETCore.App.SharedFx.sfxproj : error NU1605: Detected package downgrade: Microsoft.NETCore.DotNetHostPolicy from 5.0.0 to 5.0.0-criteo1. Reference the package directly from the project to select a different version. 
/build/runtime/src/installer/pkg/projects/netcoreapp/sfx/Microsoft.NETCore.App.SharedFx.sfxproj : error NU1605:  unused -> Microsoft.NETCore.App.Internal 5.0.0-criteo1 -> Microsoft.NETCore.DotNetHostPolicy (>= 5.0.0) 
/build/runtime/src/installer/pkg/projects/netcoreapp/sfx/Microsoft.NETCore.App.SharedFx.sfxproj : error NU1605:  unused -> Microsoft.NETCore.DotNetHostPolicy (>= 5.0.0-criteo1)
/build/runtime/src/installer/pkg/projects/netcoreapp/sfx/Microsoft.NETCore.App.SharedFx.sfxproj : error NU1605: Detected package downgrade: Microsoft.NETCore.DotNetHostResolver from 5.0.0 to 5.0.0-criteo1. Reference the package directly from the project to select a different version. 
/build/runtime/src/installer/pkg/projects/netcoreapp/sfx/Microsoft.NETCore.App.SharedFx.sfxproj : error NU1605:  unused -> Microsoft.NETCore.DotNetHostPolicy 5.0.0-criteo1 -> Microsoft.NETCore.DotNetHostResolver (>= 5.0.0) 
/build/runtime/src/installer/pkg/projects/netcoreapp/sfx/Microsoft.NETCore.App.SharedFx.sfxproj : error NU1605:  unused -> Microsoft.NETCore.DotNetHostResolver (>= 5.0.0-criteo1)
/build/runtime/src/installer/pkg/projects/netcoreapp/sfx/Microsoft.NETCore.App.SharedFx.sfxproj : error NU1605: Detected package downgrade: Microsoft.NETCore.DotNetAppHost from 5.0.0 to 5.0.0-criteo1. Reference the package directly from the project to select a different version. 
/build/runtime/src/installer/pkg/projects/netcoreapp/sfx/Microsoft.NETCore.App.SharedFx.sfxproj : error NU1605:  unused -> Microsoft.NETCore.DotNetHostResolver 5.0.0-criteo1 -> Microsoft.NETCore.DotNetAppHost (>= 5.0.0) 
/build/runtime/src/installer/pkg/projects/netcoreapp/sfx/Microsoft.NETCore.App.SharedFx.sfxproj : error NU1605:  unused -> Microsoft.NETCore.DotNetAppHost (>= 5.0.0-criteo1)
/build/runtime/src/installer/pkg/packaging/installers.proj(50,5): error MSB4181: The "MSBuild" task returned false but did not log an error.
    0 Warning(s)
    4 Error(s)

Configuration

• We use the Centos7 docker image to build the CLR

Regression?

I was able to build and publish the dotnet-runtime-5.0.0-criteo1.tar.gz artifact until the RTM release (example: for the RC1 https://github.com/criteo-forks/runtime/releases/tag/v5.0.0-rc1-criteo1)

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[jeffschwMSFT]

cc @agocke

[LakshanF]

I believe this behavior is by design due to semantic versioning rules where the label VersionSuffix, criteo1, is considered a package downgrade from the stable package version 5.0.0 (>5.0.0-creteo1) and triggers the Nuget error NU1605.

RC build success is likely fortunate due to the label ordering alphabetically (creteo1>rc)

I'll look more to find guidance for this situation

[LakshanF]

One option to workaround this is to set the StabilizePackageVersion to false. This can be directly done in the file in the new branch or by passing /p:StabilizePackageVersion=false to the build command

[safern]

To add to this, this was because the branch was created from release/5.0 branch when the branch was already stabilizing packages, so building 5.0.0 without a version prefix. The reason why this affects the specific scenario, is because our dependency calculation for packages built within the repo depend on this property to know if we're building a stable package or not and if so, it just uses the version without a prefix to calculate the dependencies.

[gleocadie]

Thank you all for your answers (sorry for the delayed response).
@LakshanF It worked. I added _/p:StabilizePackageVersion=false_ to my command line and I got my artifact with the prefix.
And thank you for looking more into it for guidance.

[LakshanF]

Happy to hear that and thanks for letting us know.

The flag guidance and the additional context on the reason above are from @safern