Nix + dotnet | 124 Members | |
| 24 Servers |
| Sender | Message | Time |
|---|---|---|
| 14 Aug 2025 | ||
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 | |
But the currect project, Utils, doesn't have any projectReferences | 19:50:13 | |
| This sounds sort of like: https://github.com/NixOS/nixpkgs/pull/432571 | 19:50:45 | |
| Current pkgs.buildDotnetModule { src = ../..; projectFile = "src/Utils/Utils.csproj"; nugetDeps = ./deps.json;
| 19:53:17 | |
* Current default.nix looks like this, | 19:53:50 | |
| 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 | |