FreeBSD RIDs started to have the OS major version in it

[arrowd]

The .NET 9 package on FreeBSD installs the following file:

share/dotnet/packs/Microsoft.NETCore.App.Host.freebsd.14-x64/9.0.1/runtimes/freebsd.14-x64/native/apphost

The same file installed by the .NET 8 package is named differently:

share/dotnet/packs/Microsoft.NETCore.App.Host.freebsd-x64/8.0.6/runtimes/freebsd-x64/native/apphost

Notice the added OS major version suffix (freebsd.14-x64 vs. freebsd-x64).

I'm not sure which variant is more corrent, but FreeBSD doesn't indeed guarantee ABI compatibility between major releases. So, appending the .14 part feels right.

However, it is now unclear what consumer projects should now do wrt. to RID being used. For example, what shoud PowerShell put in there /~https://github.com/PowerShell/PowerShell/blob/master/src/powershell-unix/powershell-unix.csproj#L12 ?

[elinor-fung]

@wfurt @Thefrank @sec any ideas what changed with the FreeBSD package here, if it was intentional, and what the expectation is going forward?

[Thefrank]

The behavior of adding MAJORVERSION is correct for non-portable SDKs (e.g., those builds from VMR or using /p:Portablebuild=false). If the OS version was not included in prior VMR builds for FreeBSD that was likely in error.

I am not aware of any consumer products that explicitly build against a non-portable SDK, but something like freebsd-x64 should be enough. These should resolve down in the RID graph:

runtime/src/libraries/Microsoft.NETCore.Platforms/src/runtime.json

Lines 1714 to 1718 in 7e82ad9

	"freebsd.13-x64": {
	"#import": [
	"freebsd.13",
	"freebsd.12-x64"
	]

Words not code version: https://learn.microsoft.com/en-us/dotnet/core/rid-catalog

[wfurt]

AFAIK the Linux binaries published by MS use the portable build e.g. they are not specific to particular OS version.
So as macOS and I don't think there is ABI promise either. But on FreeBSD this comes from ports for a particular FreeBSD version so I don't see the major version as problem. Unless you start mixing binaries for different version.

[sec]

I think the question was more like, that when using, ex. <RuntimeIdentifiers>freebsd-arm64</RuntimeIdentifiers> this is not resolved and fails with:

/home/sec/a/a.csproj : error NU1101: Unable to find package Microsoft.NETCore.App.Runtime.freebsd-arm64. No packages exist with this id in source(s): /usr/local/share/dotnet/library-packs, nuget.org
/home/sec/a/a.csproj : error NU1101: Unable to find package Microsoft.AspNetCore.App.Runtime.freebsd-arm64. No packages exist with this id in source(s): /usr/local/share/dotnet/library-packs, nuget.org
/home/sec/a/a.csproj : error NU1101: Unable to find package Microsoft.NETCore.App.Host.freebsd-arm64. No packages exist with this id in source(s): /usr/local/share/dotnet/library-packs, nuget.org

But, under FreeBSD 14, using freebsd.14-arm64 is ok, becuase we have bundled those nuget's with SDK (ex. Microsoft.NETCore.App.Host.freebsd.14-arm64.9.0.0.nupkg, those are produced during VMR build under ports/packages).
Using freebsd.13-arm64 is also not working, but I would expect this to work.

So maybe, the question was, should (or more how) freebsd-arm64 be resolved to freebsd.MAJOR-arm64 or how should this be handled? Maybe we're missing something in our builds/patches for FreeBSD builds?

[Thefrank]

The portable version should be used instead of a non-portable version where possible: https://learn.microsoft.com/en-us/dotnet/core/rid-catalog#using-rids

The portable SDK will not understand freebsd.14-arm64 should map down to freebsd-arm64. The non-portable SDK should understand that RID and have freebsd.14-arm64 in its RID graph.

Non-portable builds of the SDK should automagically put the non-portable RID into the RID graph so the SDK will know how to use the non-portable RID

[sec]

In ports/packages we have non-portable builds, right (from VMR) - so that's the one that end-user are using

Non-portable builds of the SDK should automagically put the non-portable RID into the RID graph so the SDK will know how to use the non-portable RID

So looks like this is not the case or we miss something?

[jkotas]

<RuntimeIdentifiers>freebsd-arm64</RuntimeIdentifiers> says that you want this exact RID. No magic is going to override it.

You may need to use <RuntimeIdentifier>$(NETCoreSdkRuntimeIdentifier)</RuntimeIdentifier> to set the RID to the current non-portable RID.

[sec]

You may need to use <RuntimeIdentifier>$(NETCoreSdkRuntimeIdentifier)</RuntimeIdentifier> to set the RID to the current non-portable RID.

@arrowd That should do the trick for building under different FreeBSD releases - or patch this into proper number based on build system then, right?

[arrowd]

I haven't built PowerShell myself, and honestly I still didn't get it - what should be patched in the PowerShell project files to make it work?

[sec]

I did my try on pwsh build using one of the wip ports we had, and had success, but hit one thing on the road.

[sec@vm14 ~/a]$ dotnet publish -r freebsd.14-x64 --sc -p:PublishReadyToRun=true
    /home/sec/a/a.csproj : error NU1101: Unable to find package Microsoft.NETCore.App.Crossgen2.freebsd-x64. No packages exist with this id in source(s): /usr/local/share/dotnet/library-packs, nuget.org

This must be something wrong set inside RIDs in SDK ?
When not doing Crossgen, it works

[sec@vm14 ~/a]$ dotnet publish -r freebsd.14-x64 --sc -p:PublishReadyToRun=false
Restore complete (0.5s)
  a succeeded (1.3s) → bin/Release/net9.0/freebsd.14-x64/publish/

[Thefrank]

@sec
That might be related: dotnet/sdk#45566
If yes, looks like it should be fixed in v9.0.2xx

[sec]

@sec That might be related: dotnet/sdk#45566 If yes, looks like it should be fixed in v9.0.2xx

edit: nope, it's not fixed in 9.0.2, SDK 9.0.103, but that's what compiled when using VMR build - looks like this should be fixed in 9.0.200 ...