In reply to @6pak:matrix.org

dotnetCorePackages.dotnet_9.sdk

and accessing the sdk like that is lowkey an implementation detail

The issue actually seems to have been using dotnetCorePackages.dotnet_9.sdk instead of dotnetCorePackages.sdk_9_0. After changing that, it works.

But now I have the Read-only file system issue when trying to install workloads.

I know, I've had this issue before and that's also the reason I was using dotnet_9.sdk. Because I had read this

Would it theoretically be possible to install the workloads using nix?

In reply to @6pak:matrix.org
while sdk_9_0 currently aliases to the binary one

In reply to @6pak:matrix.org
.

With this workaround I can install the workloads, but they are still ignored by dotnet restore

In reply to @ortolanbunting3002:tchncs.de

In reply to @6pak:matrix.org
.

With this workaround I can install the workloads, but they are still ignored by dotnet restore

Ah, how do I use them then?

It seems that nuget2nix doesn't support spaces in the projectFile value, from what I can tell?

  dotnet-sdk = dotnetCorePackages.sdk_9_0;
  dotnet-runtime = dotnetCorePackages.runtime_9_0;
  nugetDeps = ./deps.json;
  projectFile = "mbundle extractor/mbundle extractor.csproj";
  selfContainedBuild = false;
  dotnetBuildFlags = [ "--framework net9.0" ];
  dotnetInstallFlags = [ "--framework net9.0" ];

$ ./fetch-deps deps.json
fetching dependencies for rune-factory-4-special-mbundle-extractor-unstable-2021-12-30
Running phase: unpackPhase
unpacking source archive /nix/store/knnjxlszi45ylm5m4hj8lkjfjyrx09vj-source
source root is source
Running phase: patchPhase
Running phase: configureNuget
The template "NuGet Config" was created successfully.

Processing post-creation actions...



Running phase: updateAutotoolsGnuConfigScriptsPhase
Running phase: configurePhase
Executing dotnetConfigureHook
MSBUILD : error MSB1009: Project file does not exist.
Switch: mbundle

Just a 5min guess: Could the output of binwalk help here?

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             ELF, 64-bit LSB shared object, AMD x86-64, version 1 (SYSV)
14137         0x3739          Unix path: /usr/share/dotnet

I did not investigate what's stored at that offset or if it even is at the same offset but this seems like it might be a bit more reliable...