| 14 Aug 2025 |
Corngood | 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 | * 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 | yes :/ oops | 19:49:55 |
Whovian9369 | 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 | But the currect project, Utils, doesn't have any projectReferences | 19:50:13 |
Corngood | This sounds sort of like: https://github.com/NixOS/nixpkgs/pull/432571 | 19:50:45 |
oatmealraisin | 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 | * Current default.nix looks like this, | 19:53:50 |
oatmealraisin |
| 19:53:55 |
oatmealraisin | * { 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 | *
pkgs.buildDotnetModule {
pname = "Utils.csproj";
version = "0.1";
src = ../..;
projectFile = "src/Utils/Utils.csproj";
nugetDeps = ./deps.json;
packNupkg = true;
}```
| 19:54:32 |
Corngood | Could you see if dotnetPackFlags = [ "-p:RuntimeIdentifier=linux-x64" ]; fixes it? | 19:55:12 |
Corngood | 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 | It fixed it | 19:56:09 |
Corngood | preInstallPhase = "dotnetPackFlags=-p:RuntimeIdentifier=$dotnetRuntimeIds";
That would be slightly less hacky.
| 20:00:15 |
Corngood | * preInstall = "dotnetPackFlags=-p:RuntimeIdentifier=$dotnetRuntimeIds";
That would be slightly less hacky.
| 20:01:03 |
Corngood | * preInstall = "dotnetPackFlags=-p:RuntimeIdentifier=$dotnetRuntimeIds";
That would be slightly less hacky. (*edited)
| 20:01:17 |
Corngood | And that PR should fix it... | 20:02:12 |
6pak | slnx is a thing now | 20:03:42 |
Corngood | 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 |
Corngood | Actually looks like dotnet 9+ no longer try to guess, and just give:
MSBUILD : error MSB1011: Specify which project or solution file to use because this folder contains more than one project or solution file.
dotnet 8 will prefer .sln, but not .slnf and doesn't understand .slnx
| 20:12:47 |
Corngood | It would be nice to have a portable way of not duplicating that logic... | 20:14:01 |
6pak | btw vmr10 builds fine for me | 20:13:43 |
GGG | maybe we should turn that into a warn | 20:13:49 |
GGG | since we'll drop support for 8 eventually | 20:13:56 |
Corngood | Turn what into a warn? | 20:14:47 |
GGG | using just a directory when there are multiple files (or at all, since we'd rather not duplicate the logic) | 20:15:12 |
GGG | and also, to add to this problem.... we don't check for .vbproj either nor .fsproj | 20:15:24 |
Corngood | _dotnetIsSolution() {
local -r projectFile="${1-}"
[[ $projectFile == *.sln || \
! -f $projectFile && \
-n $(find "${projectFile:-.}" -maxdepth 1 -name \*.sln -print -quit) ]]
}
This is all it does in the PR. It just wants to know if you're attempting to build a solution
| 20:16:16 |
Corngood | 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 |