 | Nix + dotnet | 120 Members |
| 23 Servers |
| Nix + dotnet | 120 Members |
| 23 Servers |
| Sender | Message | Time |
|---|---|---|
| 13 Aug 2025 | ||
 Whovian9369 | ... The answer is seemingly nothing due to the hook seemingly overriding it. | 18:10:24 |
 6pak | why would you want to disable selfContainedBuild on nix side? | 18:11:08 |
| Whovian9369 | You mean explicitly settings selfContainedBuild = false;? Honestly I think it's personal preference so I know exactly what's set where I can set stuff.I believe Nix does set it automatically anyway, so 🤷 | 18:21:06 |
| Whovian9369 | * You mean explicitly setting selfContainedBuild = false;? Honestly I think it's personal preference so I know exactly what's set where I can set stuff.I believe Nix does set it automatically anyway, so 🤷 | 18:21:56 |
| 6pak | I mean not setting it to true | 18:22:16 |
| Whovian9369 | Sorry, I'm afraid I'm missing the question then. You're asking why I'm setting selfContainedBuild = false; in the first place? | 18:22:51 |
| 6pak | yeah | 18:23:13 |
| Whovian9369 | I mean, as I said I think it's just personal opinion. I don't remember why I started doing it other than "Nix seems to automatically set this to false", but it might just be that I've seen it in Nixpkgs one time and preferred how it was laid out versus the output of selfContainedBuild = true; on "normal" (non-AoT) builds that I've done. | 18:26:12 |
| Whovian9369 | It seems that Nix defaults to selfContainedBuild = false; anyway, but I like having the feeling of extra control or knowledge that for me comes from having that option immediately exposed (especially for testing like this, where having it as false seems to show errors due to AoT wanting PublishTrimmed set to true, which is disabled by default by a hook as you pointed out). | 18:36:21 |
| 14 Aug 2025 | ||
 oatmealraisin | I have a project with a long tree of projectReferences, and I've got (most) building. I'm changing them to packNupkg=true, but I'm running into a common error between some of them: error NU5026: The file '/build/flake-build/src/Shared/bin/Release/net8.0/Shared.dll' to be packed was not found on disk. [/build/flake-build/src/Shared/Shared.csproj] | 19:01:03 |
| oatmealraisin | (Shared.csproj is the currently building project) | 19:01:15 |
| oatmealraisin | Any ideas why this might be happening? | 19:01:24 |
| 6pak | looks like a dummy csproj to house shared files | 19:02:15 |
| 6pak | are you sure it's projectreferenced by anything? | 19:02:26 |
| oatmealraisin | It's currently the package I'm trying to build, it references one other project (Util.csproj) which builds as a nupkg | 19:02:58 |
| oatmealraisin | Just for clarification, I'm trying to build an aspnet/blazor project in a flake, and so I'm making a default.nix in each project directory | 19:03:56 |
| oatmealraisin | currently just going through and making sure each builds with nix-build | 19:04:17 |
| oatmealraisin | Should I use a pastebin for this chat or can I just paste into the chat? | 19:04:40 |
| oatmealraisin | | 19:06:48 |
| oatmealraisin | * with import <nixpkgs> { }; let Utils = import ../Utils; in buildDotnetModule { pname = "Shared.csproj"; version = "0.1"; src = ../..; projectFile = "src/Shared/Shared.csproj"; referencedProjects = [ Utils ]; nugetDeps = ./deps.json; packNupkg = true; } | 19:06:57 |
| oatmealraisin | deps.json is generated for every project using nix-build -A passthru.fetch-deps | 19:07:21 |
| oatmealraisin | Every default.nix looks pretty much exactly like this | 19:07:52 |
| Whovian9369 | Anyone know if trying to build the Dotnet 10 Preview 6 dotnet-vmr is likely "worth it" for most users?I also noticed https://github.com/NixOS/nixpkgs/issues/431811 which is worrying me, since I'm on quite a lower end system. | 19:19:39 |
| Whovian9369 | * Anyone know if trying to build the Dotnet 10 Preview 6 dotnet-vmr is likely "worth it" for most users to build something?I also noticed https://github.com/NixOS/nixpkgs/issues/431811 which is worrying me, since I'm on quite a lower end system. | 19:19:51 |
| Whovian9369 | * Anyone know if trying to build the Dotnet 10 Preview 6 dotnet-vmr is likely "worth it" for most users to build something else?I also noticed https://github.com/NixOS/nixpkgs/issues/431811 which is worrying me, since I'm on a lower end system and I don't like the idea of waiting a while just for a failed build. | 19:21:04 |
 Corngood | That failure happens quite quickly (configure phase). We just merged a change today that provides debug symbols for VMR builds, so it would be useful if anyone can reproduce the crash and provide a core dump. So far I've never been able to reproduce it. The only caveat is that if stage0 isn't in the binary cache, but it builds and then stage1 crashes, that might take a while... | 19:33:12 |
| Whovian9369 | So it might be good for me to attempt the build anyway? | 19:33:45 |
| Corngood | Well if it's convenient for you, it would be nice to have more data about where it crashes and doesn't crash. You could always set it going and then use dotnetCorePackages.sdk_10_0-bin in the meantime. | 19:35:25 |
| Corngood | How lower end is your system? | 19:35:52 |
| Whovian9369 | Well for one it's running Windows 10 using NixOS-WSL, so ram's already limited there. Intel(R) Core(TM) i7-4770 (8) @ 3.40 GHz with 7.72 reported GB of RAM (supplied to WSL 2?) | 19:37:20 |