How to best handle OS-dependent packages and packages.lock.json

[rvdginste]

Hello,

In one of my projects, I have an indirect dependency on the SkiaSharp package. After this dependency was added, I needed to add the nuget package SkiaSharp.NativeAssets.Linux.NoDependencies to make the code work on a linux platform.

I added the package conditionally by using the following Condition attribute on the PackageReference element in the csproj file: $([MSBuild]::IsOSPlatform('Linux')).

The consequence is that on a Linux machine, this package will show up in packages.lock.json, but it does not show up when the build is done on a Windows machine. Aside from the Linux platform, we also build in the OSX platform and a similar conditional package reference was added there too.

Is there a better way to approach these OS-dependent package dependencies that would allow us to keep the packages.lock.json consistent across platforms?

Thanks,
Ruben

[akorda]

Hey! Did you manage to find a solution to this problem?

[rvdginste]

Hi, I don't know whether that counts as a "solution", but I removed the "Condition" on the PackageReference, and included the dependency unconditionally. For my concrete use case, that is ok: the package SkiaSharp.NativeAssets.Linux.NoDependencies contains Linux specific native assets but these are not used on non-Linux hosts and have no impact.

I do believe that using $([MSBuild]::IsOSPlatform('Linux')) as condition on PackageReference elements is a bad idea.

MSBuild (or dotnet) also supports the properties RuntimeIdentifier and RuntimeIdentifiers. On projects where you target for example both Windows and Linux, you could specify the RuntimeIdentifiers property in the csproj file as <RuntimeIdentifiers>win-x64;linux-x64</RuntimeIdentifiers>. When you make those explicit, the package.lock.json files will contain specific dependency trees for each specified runtime identifier (like net8.0/linux-x64). Then you could use that inside the condition, something like '$(RuntimeIdentifier)' == 'linux-x64'. That might be a way to handle it. I did not explore that option, so I don't know how usable that is. (Note that specifying a runtime identifier means that the compiler will make a runtime specific build instead of a default "portable" build.)

If you can live without conditions on PackageReference, that is definitely preferable. Conditions based on the TargetFramework used, work fine. If you really need conditions based on OS, I think it is best to look at RuntimeIdentifiers.

[akorda]

Thanks for your reply. Me, too, I concluded that the best way to move forward is:

• to add all package references unconditionally
• add <RuntimeIdentifiers>win-x64;linux-x64</RuntimeIdentifiers> in csproj files
  just like you said

Having & managing multiple package.lock.json e.g. using NuGetLockFilePath property like here:
https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#lock-file-extensibility
for different configuration was too much work for my case and it didn't worth the effort.

Thanks!