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...

        /// <summary>
        /// hash value embedded in default apphost executable in a place where the path to the app binary should be stored.
        /// </summary>
        private const string AppBinaryPathPlaceholder = "c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2";
        private static readonly byte[] AppBinaryPathPlaceholderSearchValue = Encoding.UTF8.GetBytes(AppBinaryPathPlaceholder);

this might be an option. it gets replaced with the dll name, but there's a separate copy of it in two parts that stays in the executable for comparison

        /// <summary>
        /// hash value embedded in default apphost executable in a place where the path to the app binary should be stored.
        /// </summary>
        private const string AppBinaryPathPlaceholder = "c3ab8ff13720e8ad9047dd39466b3c8974e592c2fa383d4a3960714caef0c4f2";
        private static readonly byte[] AppBinaryPathPlaceholderSearchValue = Encoding.UTF8.GetBytes(AppBinaryPathPlaceholder);

this might be an option. it gets replaced with the dll name, but there's a separate copy of it in two parts that stays in the executable for comparison

it's also in singlefilehost