dev/ci build bundled frameworks are not considered newer than previews

[tmds]

CI builds from the VMR have recently changed their versioning. For example, previously it built dotnet-sdk-10.0.100-preview.5.25263.6-fedora.41-x64.tar.gz, and now it builds dotnet-sdk-10.0.100-dev-fedora.41-x64.tar.gz.

When trying to build the runtime repo with the new verioning, this happens when running an app:

  You must install or update .NET to run this application.
  
  App: /home/tester/.nuget/packages/microsoft.dotnet.hotreload.utils.generator.buildtool/10.0.0-alpha.0.25255.1/tools/net10.0/Microsoft.DotNet.HotReload.Utils.Generator.BuildTool.dll
  Architecture: x64
  Framework: 'Microsoft.NETCore.App', version '10.0.0-preview.3.25171.5' (x64)
  .NET location: /tmp/tmp.OdOrIEAlJf/
  
  The following frameworks were found:
    10.0.0-dev at [/tmp/tmp.OdOrIEAlJf/shared/Microsoft.NETCore.App]
  
  Learn more:
  https://aka.ms/dotnet/app-launch-failed

The requirement for >= 10.0.0-preview.3.25171.5 was satisfied by 10.0.100-preview.5.25263.6, but is not by 10.0.100-dev.

cc @ViktorHofer @mmitche @omajid

[ViktorHofer]

@mthalman

[mthalman]

When trying to build the runtime repo with the new verioning, this happens when running an app:

Can you provide more details here? You're attempting to build https://github.com/dotnet/runtime, and not the runtime repo in the VMR, is that correct? What command are you using to build? What do you mean by running an app? Is the running of the app occurring during the build? Or are you using the output of the build to run an app?

[tmds]

I'm trying to build runtime repo with an CI built vmr SDK. The setup involves ppc64le machines, and we're building runtime to be able to run runtime tests on that architecture.

The issue can also be reproduced on x64:

$ dotnet --version
10.0.100-dev
$ dotnet tool install --global dotnet-ef --prerelease 
You can invoke the tool using the following command: dotnet-ef
Tool 'dotnet-ef' (version '10.0.0-preview.4.25258.110') was successfully installed.
$ dotnet ef
You must install or update .NET to run this application.

App: /home/tmds/.dotnet/tools/dotnet-ef
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '10.0.0-preview.4.25225.6' (x64)
.NET location: /home/tmds/Downloads/dotnet

The following frameworks were found:
  10.0.0-dev at [/home/tmds/Downloads/dotnet/shared/Microsoft.NETCore.App]

Learn more:
https://aka.ms/dotnet/app-launch-failed

To install missing framework, download:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=10.0.0-preview.4.25225.6&arch=x64&rid=fedora.41-x64&os=fedora.41

Note that our vmr CI builds still use /p:DisableDevBuildAsDefaultForSourceOnly=true. I'm mentioning it in case this might be triggered by that.

[tmds]

@mthalman as a workaround, do you have a suggestion on what properties we can set to go back to a version number that looks like 10.0.100-preview.5.25263.6?

[mthalman]

Yes, a workaround would be to set OfficialBuildId (e.g. /p:OfficialBuildId=20250521.1).

DisableDevBuildAsDefaultForSourceOnly doesn't need to be used anymore now that dotnet/dotnet#400 is merged, but removing it won't make this work either.

[mthalman]

This isn't specific to source build. You would get this same behavior when using the SDK from a non-source-only dev build in the VMR.

[tmds]

Is this something that should be fixed for dev builds? Or should we build something other than a dev build in our CI?

[mthalman]

@mmitche / @MichaelSimons - What are your thoughts on this? We either need to do versioning differently or provide specific guidance for downstream builders.

[mmitche]

There are two issues to deal with here

What should your CI be built with?

In this respect, I lean towards setting an OfficialBuildId, YYYYMMDD.N, where N is the number of builds that have happened on the day. This should mean you can download the built SDK and use it to build runtime, assuming that runtime has not gotten too far ahead. This would be roughly equivalent to today, and equivalent to MSFT's day to day practices.

What should we do about dev builds?

A dev build has a lower precedence than an official build, based on the chosen pre-release labeling that we've used forever, so it's totally expected that the dev build can't satisfy the frameworks that the applications or tooling are asking for. That's for sure the case in that dotnet ef tooling. You would need to install the dotnet-ef tool that was dev-built in the VMR....at that point it...should work (I think, global tools might be a bit weird here).

But when I build locally, I don't care about official build versioning. And I probably don't even care about the fact that my dev build of the framework may not exactly line up with what my application needs. I'm just interested in using the thing I built to build some other thing. I'm stepping outside the bounds of versioning, aside from major.minor.patch restrictions. I don't think there is an easy to force the ef tool to use the dev framework, aside from specifying a runtimeconfig (dotnet --runtimeconfig) that specifies your dev config should be used.

One option might be to update the dev pre-release label to be something that sorts after rtm. I'd like to hear someone from the runtime side of things take a look at this issue and give their thoughts. @jeffschwMSFT thoughts?

[ViktorHofer]

One option might be to update the dev pre-release label to be something that sorts after rtm

That's what @mthalman was originally doing: https://github.com/dotnet/arcade/pull/15728/files
@mthalman what were the reasons for abandoning this PR? I think it's the only correct solution but I also see the high risk here, given that repositories probably started depending on the existing suffixes.

[mthalman]

The changes to the pre-release labels were abandoned after feedback from @mmitche to instead address the underlying issues of package versions within the repos that was exposing this problem, which was done in dotnet/dotnet#400. The changes in dotnet/dotnet#400 were the right thing to do regardless of what value the pre-release label had. But yes, now we're running into another issue.

[mmitche]

Yeah, the two issues are distinct. I agree the changes in dotnet/dotnet#400 were the right way to go.