Nix + dotnet | 118 Members | |
| 23 Servers |
| Sender | Message | Time |
|---|---|---|
| 20 Dec 2024 | ||
| * Hey gang, me again :P Anyone up for helping me troubleshoot dotnet stuff that I brought up recently? I'm having issues with the Log showing the issue: https://termbin.com/kq8r | 21:31:22 | |
| 23 Dec 2024 | ||
| It looks like it's some sort of incompatibility with EntityFramework. Do you know which the upstream project was meant to build with? | 00:43:00 | |
| * It looks like it's some sort of incompatibility with EntityFramework. Do you know which SDK the upstream project was meant to build with? | 00:43:11 | |
| (Good timing, I was just about to close Element, haha.) iirc upstream's LTS ( v5.3.2) is meant to build with netcoreapp3.1, but can be forced into playing nice with Net 7 by swapping out the TargetFramework with the wanted version | 00:45:07 | |
Which I do to multiple csproj in the flake via substituteInPlace at https://github.com/Whovian9369/aaru-nix-flake/blob/620ef8866395544b5aad55b7dac83fa63a988731/lts.nix#L58-L78 | 00:46:01 | |
| (I remember consulting the upstream dev at the time, and that's what was suggested.) | 00:47:02 | |
| try updating efcore | 00:47:18 | |
| Sorry, what's efcore? | 00:49:03 | |
| EntityFrameworkCore, the package that's crashing in your log | 00:49:24 | |
| Ah I'll try to look into how to do that. Thank you for the suggestion! | 00:50:15 | |
| Well judging by the lock file it seems to be using the same version as pre release. So if anything I think maybe it was meant to work with an older version? | 00:51:01 | |
| wait why does it reference both ef6 and efcore | 00:51:38 | |
| it doesn't | 00:52:41 | |
| lts uses 3.1, prerelease uses 7.0 | 00:52:46 | |
| * lts uses 3.1.5, prerelease uses 7.0.1 | 00:53:01 | |
| the ef6 reference is just for decoration I guess | 00:53:23 | |
| Ah, I was looking at `pname = "EntityFramework"; version = "6.4.4"` | 00:53:47 | |
| I'm not familiar with these packages at all. I also don't remember what happened when it was left targeting netcoreapp3.1. that should be possible with a newer sdk, right? | 00:54:53 | |
| I'll see if I can play around with any of this at some point. Thank you both so much for the thoughts! | 01:05:25 | |
So this worked!
| 03:50:00 | |
(I removed a bunch from patchPhase for the above example) | 03:53:18 | |
I'd recommend using patch files whenever possible instead of substituteInPlace | 03:58:38 | |
| but if you've ensured that it only changes the versions of what you want then it should be fine | 03:59:01 | |
| That's a good tip, thanks | 03:59:59 | |
As far as I can tell, the only things that I'm changing are what I intend to, so I should be good. | 04:01:22 | |
(Honestly I just prefer substituteInPlace since it leaves a cleaner directory, but honestly I should just use patch files instead since that will make the actual derivation cleaner.) | 04:02:14 | |
| I myself prefer patch files because they ensure that things break if the file isn't the same anymore | 04:02:34 | |
| instead of just possibly silently changing things they shouldn't | 04:02:47 | |
| That's certainly a good point. Most of what I'm modifying (other than this) are hard to mis-patch so I'm not really worried, but hey that is still a very good reminder. https://github.com/Whovian9369/aaru-nix-flake/blob/620ef8866395544b5aad55b7dac83fa63a988731/lts.nix#L36-L79 | 04:07:20 | |
On prerelease and git I'm only doing --replace-fail '{chash:8}' "${substring 0 8 src.rev}" which I'm pretty confident aren't going to mis-match at all even between updates.(If those change at all, like if one gets removed, I'm sure that I'll figure it out pretty easily and add it to the extensive file list.) | 04:10:32 | |