| 21 Oct 2025 |
| Andrew Zah set a profile picture. | 09:49:41 |
| 23 Oct 2025 |
| Manuel Bärenz joined the room. | 15:45:21 |
Manuel Bärenz | I'm using nixpkgs for years now, and dotnet for the first time. I need to package a web service somepkg that a third party offers on their own nuget server nuget.thirdparty.com/somepkg/nuget. I can't figure out how to properly override buildDotnetGlobalTool (I guess) to accept the custom nuget url. I'm trying something like this:
buildDotnetGlobalTool.override ({
fetchNupkg = dotnetCorePackages.fetchNupkg.override {
url = "..."
But that seems to be wrong:
error: function 'anonymous lambda' called with unexpected argument 'url'
at /nix/store/jbjpzwqzf0vq989s6y302jy1dff4z321-source/pkgs/build-support/dotnet/fetch-nupkg/default.nix:1:1:
Is there a standard way to do this? (Or else I probably need to dig deep into how dotnet is implemented in nixpkgs?)
| 15:49:10 |
Manuel Bärenz | I managed something like this:
let
pname = "IBPkernelSimplifiedHS";
version = "v1";
customNugetServer = "https://nuget.thirdparty.com/somepkg/nuget";
url = "${customNugetServer}/${pname}/${version}";
in
dotnetCorePackages.buildDotnetGlobalTool.override {
fetchNupkg = args: dotnetCorePackages.fetchNupkg (args // {
inherit url;
});
} {
inherit pname version;
}
And it actually attempts to download from the third party server 🎉 but the URL schema is still wrong. I'm not sure what the standard url schema would be in this case.
| 16:06:47 |
Manuel Bärenz | I managed to grasp the URL schema, so that's fixed. I now have have a somepkg.nupkg archive with this structure:
_rels -> .rels
_lib -> net8.0 ->
somepkg.dll
somepkgFoo.dll
...
package ->
services -> metadata -> core-properties -> 12341234.psmdcp
[Content_Types].xml
somepkg.nuspec
It seems that buildDotnetGlobalTool can't deal with this structure:
Unhandled exception: System.IO.DirectoryNotFoundException: Could not find a part of the path '/nix/store/58w6rl6al5f1yq4ckmg4qm7a8r1r7rz9-somepkg-1.0.98/lib/somepkg/.store/somepkg/1.0.98/somepkg/1.0.98/tools
| 16:32:50 |
Manuel Bärenz | * I managed to grasp the URL schema, so that's fixed. I now have have a somepkg.nupkg archive with this structure:
_rels -> .rels
lib -> net8.0 ->
somepkg.dll
somepkgFoo.dll
...
package ->
services -> metadata -> core-properties -> 12341234.psmdcp
[Content_Types].xml
somepkg.nuspec
It seems that buildDotnetGlobalTool can't deal with this structure:
Unhandled exception: System.IO.DirectoryNotFoundException: Could not find a part of the path '/nix/store/58w6rl6al5f1yq4ckmg4qm7a8r1r7rz9-somepkg-1.0.98/lib/somepkg/.store/somepkg/1.0.98/somepkg/1.0.98/tools
| 16:33:11 |
GGG | it seems like it isn't a dotnet tool, but just a plain .NET assembly instead | 17:32:28 |
GGG | you'll probably need to extract everything in lib, fetch its deps (if it has any) and then use makeWrapper to wrap it in a dotnet exec somepk.dll call | 17:33:03 |
GGG | * you'll probably need to extract everything in lib/net8.0, fetch its deps (if it has any) and then use makeWrapper to wrap it in a dotnet exec somepk.dll call | 17:41:55 |
Manuel Bärenz | Thanks, I'll try that! | 17:48:48 |
| 24 Oct 2025 |
Manuel Bärenz | I can't quite figure out how to pass dependencies properly to the dll. Right now I have this:
...
nupkg = dotnetCorePackages.fetchNupkg {
inherit url version pname;
sha256 = "sha256-Cq2t0TkGtmGpMcFrz9m0FJ14F4knfDoGaUFda9dijik=";
};
in
stdenvNoCC.mkDerivation {
inherit version pname;
nativeBuildInputs = [
makeWrapper
# dotnetCorePackages.runtime_8_0
dotnetCorePackages.sdk_8_0
];
buildInputs = [
dotnetCorePackages.runtime_8_0
# dotnetCorePackages.sdk_8_0
];
src = nupkg;
installPhase = ''
runHook preInstall
mkdir -p $out/bin
makeWrapper ${lib.getExe dotnetCorePackages.runtime_8_0-bin} $out/bin/${pname} \
--add-flags "exec ${nupkg}/share/nuget/packages/${lib.toLower pname}/${version}/lib/net8.0/${pname}.dll"
runHook postInstall
'';
But it says:
A fatal error was encountered. The library 'libhostpolicy.so' required to execute the application was not found in '/nix/store/yjszifiind26c7vpvyg4c3m49lgksv0z-somepkg-1.0.98/share/nuget/packages/somepkg/1.0.98/lib/net8.0/'
| 09:02:33 |
Manuel Bärenz | I tried to shuffle sdk and runtime around, sometimes getting this error:
> Running phase: configureNuget
> The command could not be loaded, possibly because:
> * You intended to execute a .NET application:
> The application 'new' does not exist.
> * You intended to execute a .NET SDK command:
> No .NET SDKs were found.
But I'm assuming that's because nuget is getting confused depending on what's on the path
| 09:03:38 |
Manuel Bärenz | Maybe I shouldn't use fetchNupkg at all, and just use fetchUrl? | 09:04:08 |
Manuel Bärenz | Anyways I would have assumed that libhostpolicy.so is in either the standard runtime or sdk, but I'm not passing dependencies in the right way | 09:06:09 |
Corngood | Are you able to share the whole thing somewhere? | 11:58:16 |
Manuel Bärenz | Unfortunately not, it's closed source :/ I'll try and work out a completely parametrized thing and share that | 12:55:08 |
Corngood | I think the problem is that makeWrapper is moving the dotnet executable? | 13:17:10 |
Corngood | can you share the contents of the wrapper script? | 13:17:41 |
Manuel Bärenz | I guess I'm a step further. Instead of trying to package the dlls directly, I'm now trying to package a simple web service for which I have the source code (including .csproj, NuGet.config and .sln) which depends on the dll | 13:17:43 |
Manuel Bärenz | * I guess I'm a step further. Instead of trying to package the dlls directly, I'm now trying to package a simple web service for which I have the source code (including .csproj, NuGet.config and .sln) which depends on the dlls | 13:17:46 |
Manuel Bärenz | (I needed to do this anyways at some point, but I thought it was smarter to leave out that part for later. Probably wasn't.) | 13:18:14 |
Manuel Bärenz | Either way this is what I have right now:
{
lib,
dotnetCorePackages,
makeWrapper,
stdenvNoCC,
}:
let
url = "${customNugetServer}(Id='${pname}',Version='${version}')/Download";
dlls = dotnetCorePackages.fetchNupkg {
inherit url version pname;
sha256 = "sha256-xEPmYA0wkQrDBl82HDa6khIMltNUV5gdzayt6J1Lwpw=";
};
in
with dotnetCorePackages;
buildDotnetModule {
inherit pname version;
src = webapi-src;
buildInputs = [
aspnetcore_9_0
dlls
];
dotnet-sdk = sdk_9_0;
dotnet-runtime = runtime_9_0;
}
| 13:19:08 |
Manuel Bärenz | And it gets me this far:
> Running phase: configureNuget
> The template "NuGet Config" was created successfully.
>
> Processing post-creation actions...
>
>
> Running phase: updateAutotoolsGnuConfigScriptsPhase
> Running phase: configurePhase
> Executing dotnetConfigureHook
> Determining projects to restore...
> /build/myAPI/myApi.csproj : error NU1101: Unable to find package Swashbuckle.AspNetCore. No packages exist with this id in source(s): _nix
| 13:20:12 |
Manuel Bärenz | I would have thought that the package is part of aspnet, but either it isn't or I'm adding dependencies incorrectly | 13:20:42 |
Corngood | You probably need to add nuget deps: nugetDeps = ./deps.json, and then run $(nix-build -A [pkg].fetch-deps) | 13:23:59 |
Corngood | Also putting aspnetcore_9_0 in buildInputs is unusual. You might just want to use it for dotnet-runtime. | 13:26:10 |
Manuel Bärenz | That seems like some great piece of tooling. Right now it fails because of some proprietary dependency from our partner, but it did download a bunch of packages that seemed sensible | 13:32:39 |
Manuel Bärenz |
That seems like some great piece of tooling.
Sorry, that sounded sarcastic, I meant it seriously 😅 and thanks for your help so far
| 13:41:53 |
Manuel Bärenz | Can I point the fetch-deps to a custom nuget server for some packages? Or at least pass it a NuGet.config that has the custom server configured? | 13:46:14 |
Manuel Bärenz | Ohh. I think if I name it properly (nuget.config instead of NuGet.config) it detects it automatically. | 13:53:13 |