Nix + dotnet | 126 Members | |
| 24 Servers |
| Sender | Message | Time |
|---|---|---|
| 17 Dec 2024 | ||
I would like to move away from buildDotnetModule personally, and use something based on dotnet-sdk hooks. The avalonia package was a bit of a test case for this. | 22:16:25 | |
| you can't easily linux-x64 publish one project and nuget pack another from one solution | 22:16:31 | |
because from one side buildDotnetModule properties are global for all projects | 22:16:43 | |
| and from another you can't easily break up subprojects into multiple nix derivations because of how msbuild projectreferences work | 22:16:59 | |
| Yeah, but that's a non-objective really, most `buildX` that I know of don't let you have multiple outputs | 22:17:04 | |
I see a projectReferences property in buildDotnetModule which sounds nice in theory, but in practice msbuild treats projectreferences very differently to packagereferences | 22:17:25 | |
| which is a pet peeve of mine | 22:17:30 | |
| but ^ | 22:18:32 | |
| if we can't nicely break up subprojects into nix derivation because of how msbuild works | 22:18:43 | |
| imo exposing procedural bash helpers instead is the way to go | 22:18:56 | |
| Like, if you build both a program and a nuget package, you'd want them in separate packages, because it makes no sense to have a single package with both as a user of either doesn't need the other | 22:18:59 | |
| so you can just decide what you want to build in buildPhase | 22:19:02 | |
| and have a flexible way to gather nuget deps | 22:19:13 | |
In reply to @6pak:matrix.orgThat's not the standard in nixpkgs currently though | 22:19:14 | |
| It'd be very confusing | 22:19:18 | |
projectReferences is just buildInputs now | 22:19:28 | |
| And inconsistent with the rest of nixpkgs | 22:19:29 | |
| I'd rather have buildDotnetModule but also be able to use individual helpers to do the more complicated stuff if people want. | 22:19:59 | |
| yeah I just mean you can't easily replace ProjectReference with PackageReference in msbuild | 22:20:22 | |
| both have their own quirks | 22:20:26 | |
| with former you can specify a different target to build and do crazy stuff | 22:20:58 | |
| Yeah, .NET really wasn't made to work like this, were really trying to shove a square cube into a circle | 22:21:00 | |
| * Yeah, .NET really wasn't made to work like this, were really trying to shove a square cube into a circle hole | 22:21:08 | |
| * with former you can specify a different target to build and do crazy stuff, the latter auto imports stuff like build.props and analyzers which the former doesn't annoyingly | 22:21:25 | |
| * Yeah, .NET really wasn't made to work like this, we're really trying to shove a square cube into a circle hole | 22:21:26 | |
| So it looks like my current issue is that some language details that I'm unfamiliar with (as I'm not a C# dev) For example, /build/source/Aaru.Images/AaruFormat/Write.cs(4356,58): error CS9194: Argument 2 may not be passed with the 'ref' keyword in language version 8.0. To pass 'ref' arguments to 'in' parameters, upgrade to language version 12.0 or greater. [/build/source/Aaru.Images/Aaru.Images.csproj] | 22:22:55 | |
| * So it looks like my current issue is that some language details that I'm unfamiliar with (as I'm not a C# dev) Edit: Sorry for interrupting! | 22:23:10 | |
| So this is something meant to build with an older SDK? You may just have to fix things like that unfortunately. | 22:24:51 | |
| Or maybe you just need to set an explicit language version? | 22:25:52 | |
| 22:26:38 | |