| 9 Jan 2025 |
 GGG | Like roslyn-ls | 16:01:27 |
| GGG | But other than those, it's not really necessary | 16:01:36 |
 6pak | in that case you should have a custom bootstrapper that takes global.json into account | 16:02:22 |
| GGG | There's no global.json for programs in $PATH though | 16:02:48 |
| 6pak | I mean if you want roslyn-ls to use the same roslyn as the only that builds the project, then it would have to read the global.json | 16:03:49 |
| 6pak | becuase a normal apphost will use whatever version deps.json of the program specifies | 16:04:09 |
| 6pak | * because a normal apphost will use whatever version deps.json of the program specifies | 16:04:21 |
| GGG | Oh no, roslyn-ls is a language server, so the user uses it when already having a .NET SDK installed in their system | 16:04:28 |
| GGG | And not every project has a global.json | 16:04:37 |
| 6pak | it should imo | 16:05:01 |
| GGG | I don't see the need for it to exist imo | 16:05:16 |
| 6pak | but does roslyn-ls bundle it's own roslyn binary or uses one from .net sdk | 16:05:20 |
| GGG | In reply to @6pak:matrix.org
but does roslyn-ls bundle it's own roslyn binary or uses one from .net sdk I have no idea | 16:05:40 |
| 6pak | sdk major/feature-band updates can bring breaking changes | 16:05:55 |
| 6pak | wym by this | 16:06:06 |
| GGG | In reply to @6pak:matrix.org
sdk major/feature-band updates can bring breaking changes I mean, shouldn't TFM take care of that already | 16:06:19 |
| 6pak | I mean build system breaking changes | 16:06:34 |
| GGG | In reply to @6pak:matrix.org
wym by this Because some programs want to use whatever SDK(s) the user has installed on their system | 16:06:45 |
| GGG | Like roslyn-ls | 16:06:57 |
| GGG | Can't remember if there's others | 16:07:04 |
| GGG | But we have a flag for it in `buildDotnetModule` | 16:07:14 |
| 6pak | SDK or runtime | 16:07:52 |
| GGG | In reply to @6pak:matrix.org
SDK or runtime The runtime in the SDK really, since they'll use the SDK themselves as well | 16:08:28 |
| 6pak | it does bundle it's own | 16:11:35 |
| 6pak | so I'm not really sure why it would need this | 16:11:47 |
| GGG | I can't remember well myself honestly | 16:14:41 |
| GGG | @corngood:corngood.com maybe you can shine some light into this one? | 16:15:46 |
| 10 Jan 2025 |
 Corngood | I sort of skimmed the above, so sorry if I'm misunderstanding, but you're asking why roslyn-ls would need the ability to run against different runtimes/SDKs?
I'm more familiar with omnisharp-roslyn, but I imagine they are similar. It's important that it's able to use the same compiler (roslyn) used to build whatever project it's loading. It might not be important that it runs on a particular runtime, but I guess it ensures that the runtime can load the compiler.
| 13:01:26 |
| GGG | We were more discussing if there's even a need to keep around the apphost binaries in NixOS, since we can just use `makeBinaryWrapper` and make it call `dotnet run` or something similar | 13:06:45 |
| Corngood | You mean get rid of Microsoft.NETCore.App.Host.*? You'd have to fix any projects that try to build self-contained, right? | 13:43:02 |
