Nix + dotnet | 114 Members | |
| 23 Servers |
| Sender | Message | Time |
|---|---|---|
| 14 Aug 2025 | ||
| 19:53:55 | |
| * { 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 | |
*
| 19:54:32 | |
Could you see if dotnetPackFlags = [ "-p:RuntimeIdentifier=linux-x64" ]; fixes it? | 19:55:12 | |
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 | |
| It fixed it | 19:56:09 | |
|
That would be slightly less hacky. | 20:00:15 | |
| *
That would be slightly less hacky. | 20:01:03 | |
| *
That would be slightly less hacky. (*edited) | 20:01:17 | |
| And that PR should fix it... | 20:02:12 | |
| slnx is a thing now | 20:03:42 | |
| 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
I guess I'll test a few things | 20:06:42 | |
| Actually looks like dotnet 9+ no longer try to guess, and just give:
dotnet 8 will prefer .sln, but not .slnf and doesn't understand .slnx | 20:12:47 | |
| It would be nice to have a portable way of not duplicating that logic... | 20:14:01 | |
| btw vmr10 builds fine for me | 20:13:43 | |
maybe we should turn that into a warn | 20:13:49 | |
| since we'll drop support for 8 eventually | 20:13:56 | |
| Turn what into a warn? | 20:14:47 | |
| using just a directory when there are multiple files (or at all, since we'd rather not duplicate the logic) | 20:15:12 | |
and also, to add to this problem.... we don't check for .vbproj either nor .fsproj | 20:15:24 | |
This is all it does in the PR. It just wants to know if you're attempting to build a solution | 20:16:16 | |
There's no more csproj bit. I don't think we need to check for multiple files because dotnet itself will just fail | 20:17:34 | |
yeah, but if there's .slnx and .slnf it'll fail, and to not duplicate that logic, wouldn't it be better to just explicitly demand a specific file? | 20:18:24 | |
I'll add slnx/f there as well. I'd rather not require an explicit file because I feel like if you set up a project where dotnet build works, you should be okay. Along the lines of Makefile. | 20:21:08 | |
| that'll just add more maintenance churn for us though, and usually building the whole solution is the wrong path anyways because for solutions where there are external tools and etc, projects just build the CLI/UI and its dependencies | 20:21:53 | |
| I have stumbled upon packages in nixpkgs before where people where restoring and building the whole solution unnecessarily when building the csproj for only the CLI/UI would've sufficed | 20:22:25 | |
ok, now I'm getting an unrelated error? error NETSDK1152: Found multiple publish output files with the same relative path: /build/bshmhbaaawknnvv0bnrm5sk2zvprrdq3-source/src/WebUI/deps.json, /build/bshmhbaaawknnvv0bnrm5sk2zvprrdq3-source/src/API/deps.json. [/build/bshmhbaaawknnvv0bnrm5sk2zvprrdq3-source/src/API/API.csproj] | 20:22:39 | |
| `{ pkgs ? import <nixpkgs> {} }: let Application = import ../Application { pkgs = pkgs; }; DataMatrixGenerator = import ../../utils/DataMatrixGenerator { pkgs = pkgs; }; Infrastrcture = import ../Infrastructure { pkgs = pkgs; }; WebUI = import ../WebUI { pkgs = pkgs; }; in pkgs.buildDotnetModule { pname = "API.csproj"; version = "0.1"; src = ../..; projectFile = "src/API/API.csproj"; buildInputs = [ Application DataMatrixGenerator Infrastrcture WebUI ]; dotnetPackFlags = [ "-p:RuntimeIdentifier=linux-x64" ]; nugetDeps = ./deps.json; packNupkg = false; } ` | 20:24:21 | |
| how 2 into matrix markdown | 20:24:31 | |
*
| 20:24:45 | |