| 14 Dec 2024 |
 GGG | Definitely | 01:58:53 |
 6pak | when you can just do it once in the nuget overrides | 01:58:54 |
| 6pak | and by nuget overrides I mean https://github.com/NixOS/nixpkgs/blob/e0464e47880a69896f0fb1810f00e0de469f770a/pkgs/build-support/dotnet/fetch-nupkg/overrides.nix#L56 | 01:59:26 |
| GGG | Though if we can use the avalonia being built in nixpkgs, then we wouldn't need to patchcil it | 01:59:27 |
| 6pak | Redacted or Malformed Event | 01:59:30 |
| 6pak | * and by nuget overrides I mean https://github.com/NixOS/nixpkgs/blob/e0464e47880a69896f0fb1810f00e0de469f770a/pkgs/build-support/dotnet/fetch-nupkg/overrides.nix | 01:59:38 |
| 6pak | * and by nuget overrides I mean https://github.com/NixOS/nixpkgs/blob/e0464e47880a69896f0fb1810f00e0de469f770a/pkgs/build-support/dotnet/fetch-nupkg/overrides.nix, which I assume you know exists | 01:59:50 |
| GGG | In reply to @6pak:matrix.org
which I assume you know exists Yeah, I do, I wanted to make it possible for people to provide their own overrides actually | 01:59:59 |
| GGG | The way it is right now is kinda too carved in stone | 02:00:16 |
| GGG | But yeah, we could put it in the overrides for widely used packages, but adding some default excludes based on RID wouldn't harm anyone I think | 02:04:40 |
| GGG | Next step now is making an `autoPatchcilHook` in nixpkgs, but I'm out of steam so I'll need a while before I continue on it | 02:05:16 |
| GGG | If you want to try your hand at doing anything, feel free to shoot a pr or something | 02:05:31 |
| 6pak | leaving me with the bash dirty work smh | 02:06:34 |
| GGG | oh no, definitely not | 02:07:11 |
| GGG | I'm talking about the actual tool, you said you wanted to patch the assembly to add a ResolvingUnmanagedDll event listener | 02:07:37 |
| GGG | I'm also considering adding an option to patch which runtime an assembly depends on, to make it able to run on newer runtimes | 02:08:54 |
| 6pak | I'm not sure whether it's worth the extra complexity | 02:11:35 |
| 6pak | if a popular dependency like avalonia used dynamic loading then probably yes | 02:12:51 |
| 6pak | so you can just patch it in one place and reuse everywhere | 02:13:08 |
| 6pak | wdym? | 02:14:09 |
| 6pak | you can just force roll forward with an env variable | 02:14:27 |
| GGG | oh? I thought it needed a rebuild | 02:14:48 |
| 6pak | and fixing the subtle breaking changes in the few programs that are actually affected can't really be done in automated fashion | 02:15:10 |
| GGG | oh, I wasn't planning to fix anything | 02:15:24 |
| GGG | just change which runtime it wanted | 02:15:28 |
| GGG | I didn't know (or forgot) about the roll forward env var | 02:15:38 |
| 6pak | DOTNET_ROLL_FORWARD=LatestMajor | 02:17:25 |
| 6pak | https://learn.microsoft.com/en-us/dotnet/core/versions/selection#framework-dependent-apps-roll-forward | 02:17:32 |
| GGG | oh huh | 02:17:55 |
| GGG | even the apphost accepts that CLI arg | 02:17:59 |
