!bxVOQwsVoHhZcmNDGw:nixos.org

Nix + dotnet

114 Members
23 Servers

Load older messages

SenderMessageTime
14 Aug 2025
@corngood:corngood.comCorngood I think you can even just do nix build nixpkgs/master#dotnetCorePackages.dotnet_10.vmr? 19:43:56
@whovian9369:matrix.orgWhovian9369Good call19:44:16
@6pak:matrix.org6pak wait, can you do that without github:NixOS/? 19:44:50
@whovian9369:matrix.orgWhovian9369 
$  nix flake metadata nixpkgs/master
Resolved URL:  github:NixOS/nixpkgs/master
Locked URL:    github:NixOS/nixpkgs/092e4bc79e0a9c5bdec004bd0d94c8f1e1ad001b
Description:   A collection of packages for the Nix package manager
Path:          /nix/store/8026yxg4phch8nb857a8p4nfxa85dj2v-source
Revision:      092e4bc79e0a9c5bdec004bd0d94c8f1e1ad001b
Last modified: 2025-08-14 15:37:05

Seemingly so, huh.

19:45:42
@6pak:matrix.org6pakTIL19:45:53
@corngood:corngood.comCorngood

I'm not exactly sure how that works when you have a pinned one like:

$ nix registry list
system flake:nixpkgs path:/nix/store/z7gkn604dsdfdybi16hlkidj0ipnw2ia-source
global flake:nixpkgs github:NixOS/nixpkgs/nixpkgs-unstable
19:45:56
@corngood:corngood.comCorngoodit must fall back to the global one when there's a branch specified19:46:11
@whovian9369:matrix.orgWhovian9369 
$  nix registry list | rg -i nixpkgs
system flake:nixpkgs path:/nix/store/c39q7pww80997lz0fyqxpvsr29q6f7ld-source
global flake:nixpkgs github:NixOS/nixpkgs/nixpkgs-unstable

That seems to match more or less what I'm seeing too then, interesting.

19:46:58
@oatmealraisin:matrix.orgoatmealraisin Seems the pack phase isn't using the correct directory, build phase output is Utils -> /build/afbw66jz03aj2fa6cllz2aa4qrf9ay69-source/src/Utils/bin/Release/net8.0/linux-x64/Utils.dll but then the pack phase is erroring with /build/afbw66jz03aj2fa6cllz2aa4qrf9ay69-source/src/Utils/bin/Release/net8.0/Utils.dll' to be packed was not found on disk. 19:47:18
@oatmealraisin:matrix.orgoatmealraisin sry, unrelated to the dotnet_10.vmr discussion 19:47:37
@corngood:corngood.comCorngood Sorry I mean to reply to this earlier. Should referencedProjects be projectReferences? Note that the latter is essentially an alias for buildInputs now, so I'd probably just use that. 19:48:56
@corngood:corngood.comCorngood * Sorry I meant to reply to this earlier. Should referencedProjects be projectReferences? Note that the latter is essentially an alias for buildInputs now, so I'd probably just use that. 19:49:41
@oatmealraisin:matrix.orgoatmealraisinyes :/ oops19:49:55
@whovian9369:matrix.orgWhovian9369 Just confirmed with a local nixpkgs clone that 092e4bc7... would have been the relevant commit until about a minute before I ran the command, so it seems to do what it says on the tin. Very nice, thanks for that info, Corngood! 19:50:11
@oatmealraisin:matrix.orgoatmealraisin But the currect project, Utils, doesn't have any projectReferences 19:50:13
@corngood:corngood.comCorngoodThis sounds sort of like: https://github.com/NixOS/nixpkgs/pull/43257119:50:45
@oatmealraisin:matrix.orgoatmealraisin

Current default.nix looks like this, ```{ pkgs ? import <nixpkgs> {} }:

pkgs.buildDotnetModule {
pname = "Utils.csproj";
version = "0.1";

src = ../..;

projectFile = "src/Utils/Utils.csproj";

nugetDeps = ./deps.json;
packNupkg = true;
}

19:53:17
@oatmealraisin:matrix.orgoatmealraisin * Current default.nix looks like this, 19:53:50
@oatmealraisin:matrix.orgoatmealraisin
19:53:55
@oatmealraisin:matrix.orgoatmealraisin* { pkgs ? import <nixpkgs> {} }: pkgs.buildDotnetModule { pname = "Utils.csproj"; version = "0.1"; src = ../..; projectFile = "src/Utils/Utils.csproj"; nugetDeps = ./deps.json; packNupkg = true; } 19:53:59
@oatmealraisin:matrix.orgoatmealraisin * 

pkgs.buildDotnetModule {
  pname = "Utils.csproj";
  version = "0.1";

  src = ../..;

  projectFile = "src/Utils/Utils.csproj";

  nugetDeps = ./deps.json;
  packNupkg = true;
}```
19:54:32
@corngood:corngood.comCorngood Could you see if dotnetPackFlags = [ "-p:RuntimeIdentifier=linux-x64" ]; fixes it? 19:55:12
@corngood:corngood.comCorngood Doing it in a less hacky way is annoying because it calls restore/build/pack in a loop over dotnetRuntimeIds, although typically pack would only be run for one. 19:56:09
@oatmealraisin:matrix.orgoatmealraisinIt fixed it19:56:09
@corngood:corngood.comCorngood

preInstallPhase = "dotnetPackFlags=-p:RuntimeIdentifier=$dotnetRuntimeIds";

That would be slightly less hacky.

20:00:15
@corngood:corngood.comCorngood *

preInstall = "dotnetPackFlags=-p:RuntimeIdentifier=$dotnetRuntimeIds";

That would be slightly less hacky.

20:01:03
@corngood:corngood.comCorngood *

preInstall = "dotnetPackFlags=-p:RuntimeIdentifier=$dotnetRuntimeIds";

That would be slightly less hacky. (*edited)

20:01:17
@corngood:corngood.comCorngoodAnd that PR should fix it...20:02:12
@6pak:matrix.org6pakslnx is a thing now20:03:42
@corngood:corngood.comCorngood

I suppose that should be treated identically to .sln. I don't know which takes precedence, but it probably doesn't matter here.

There's also .slnf. I'm not sure if those take precedence over .proj files.

https://learn.microsoft.com/en-us/visualstudio/msbuild/solution-filters?view=vs-2022

In the case where you're using the .slnx solution file format, supported in MSBuild 17.12 and later, the .slnx file takes priority over the .slnf file.

I guess I'll test a few things

20:06:42

Show newer messages

Back to Room ListRoom Version: 9