Ah I think I see the problem. In Komponent.nuspec they have:

    <file src="bin\Release\net8.0\*.dll" target="lib\net8.0\"/>

But we build with --runtime, so the dll ends up being in e.g. bin/Release/net8.0/linux-x64, so no libs make it in the package.

There are various ways we could fix that, but I'm not sure what would be best. Probably giving more control over the default flags (e.g. --runtime) would be a good idea.

╭─whovian@nixos-wsl /nix/store/9j2s8kna0g37970d3s29blw20c6d5961-source/src/lib
╰─$  rg -NI "file src" | sort | uniq
    <file src="bin\Debug\net8.0\*.dll" target="lib\net8.0\"/>
    <file src="bin\Release\net8.0\*.dll" target="lib\net8.0\"/>
    <file src="..\..\..\kuriimu2icon.png" target="kuriimu2icon.png"/>

It looks like all of the nuspec files seem to use the same path, so if the others worked then Komponent should too?

In reply to @samuel:mnzn.dev
Any plans on upgrading to .NET 10 RC1?

Here to cause trouble again - I'm trying to bump a project from NET 8 to NET 9 in a derivation (without code changes, dev says it should work), but that Nuke build process seems to fail due to using a dynamically linked executable... Hapen to have any immediate ideas?

Could not start dynamically linked executable: /tmp/fetch-deps-hactoolnet-2024.08.29.Pzmhk6/source/build/bin/Debug/_build
(Then the message is about stub-ld etc)

Here to cause trouble again - I'm trying to bump a project from NET 8 to NET 9 in a derivation (without code changes, dev says it should work), but that Nuke build process seems to fail due to using a dynamically linked executable... Hapen to have any immediate ideas?

Could not start dynamically linked executable: /tmp/fetch-deps-hactoolnet-2024.08.29.Pzmhk6/source/build/bin/Debug/_build

(Then the message is about stub-ld etc)

Alternatively, is there a way to keep the in-progress /tmp/fetch-deps-... path even after a failed run? I feel like that would be good for testing.

The same process works fine on Net 8 but not Net 9, so I'm stumped from what I can tell.

preConfigure = ''
  dotnet --version > DotnetCliVersion.txt
  patchShebangs --build build.sh
  for rid in $dotnetRuntimeIds; do dotnet restore --runtime "$rid" "build/_build.csproj"; done
  ./build.sh Codegen --configuration ${buildType}
'';

Alternatively, is there a way to keep the in-progress /tmp/fetch-deps-... path even after a failed run? I feel like that would be good for testing.

The same process works fine on Net 8 but not Net 9, so I'm stumped from what I can tell.

{
preConfigure = ''
  dotnet --version > DotnetCliVersion.txt
  patchShebangs --build build.sh
  for rid in $dotnetRuntimeIds; do dotnet restore --runtime "$rid" "build/_build.csproj"; done
  ./build.sh Codegen --configuration ${buildType}
'';
}

Alternatively, is there a way to keep the in-progress /tmp/fetch-deps-... path even after a failed run? I feel like that would be good for testing.

The same process works fine on Net 8 but not Net 9, so I'm stumped from what I can tell.

{
  preConfigure = ''
    dotnet --version > DotnetCliVersion.txt
    patchShebangs --build build.sh
    for rid in $dotnetRuntimeIds; do dotnet restore --runtime "$rid" "build/_build.csproj"; done
    ./build.sh Codegen --configuration ${buildType}
  '';
}

In reply to @whovian9369:matrix.org

Alternatively, is there a way to keep the in-progress /tmp/fetch-deps-... path even after a failed run? I feel like that would be good for testing.

---

The same process works fine on Net 8 but not Net 9, so I'm stumped from what I can tell.

{
  preConfigure = ''
    dotnet --version > DotnetCliVersion.txt
    patchShebangs --build build.sh
    for rid in $dotnetRuntimeIds; do dotnet restore --runtime "$rid" "build/_build.csproj"; done
    ./build.sh Codegen --configuration ${buildType}
  '';
}