diff options
author | Ivar Scholten <ivar.scholten@protonmail.com> | 2022-09-09 01:01:14 +0200 |
---|---|---|
committer | Ivar Scholten <ivar.scholten@protonmail.com> | 2022-09-18 18:00:37 +0200 |
commit | 8e00d6ac269e87705141f817f619d82cf45b6e24 (patch) | |
tree | dc6ba63507adb14a81741b4550cd3eef681005fa /doc | |
parent | 03a1b62cb38cf6a60c496c896dbdccd4e4d9b03a (diff) |
buildDotnetModule: move nugetDeps throw to when its actually needed
Previously we had an assert that would complain when nugetDeps wasnt set, which also didnt allow any passthru attributes (like fetch-deps) to be build. That causes a cycle where you need nugetDeps to fetch the nuget deps, but arent able to build the script to do so.
Diffstat (limited to 'doc')
-rw-r--r-- | doc/languages-frameworks/dotnet.section.md | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/doc/languages-frameworks/dotnet.section.md b/doc/languages-frameworks/dotnet.section.md index 0927ce9146f91..1baa135ae5866 100644 --- a/doc/languages-frameworks/dotnet.section.md +++ b/doc/languages-frameworks/dotnet.section.md @@ -71,7 +71,7 @@ The `dotnetCorePackages.sdk` contains both a runtime and the full sdk of a given To package Dotnet applications, you can use `buildDotnetModule`. This has similar arguments to `stdenv.mkDerivation`, with the following additions: -* `projectFile` is used for specifying the dotnet project file relative to the source root. These usually have `.sln` or `.csproj` file extensions. This can be an array of multiple projects as well. +* `projectFile` is used for specifying the dotnet project file, relative to the source root. These usually have `.sln` or `.csproj` file extensions. This can be a list of multiple projects as well. Most of the time dotnet can figure this location out by itself, so this should only be set if necessary. * `nugetDeps` takes either a path to a `deps.nix` file, or a derivation. The `deps.nix` file can be generated using the script attached to `passthru.fetch-deps`. This file can also be generated manually using `nuget-to-nix` tool, which is available in nixpkgs. If the argument is a derivation, it will be used directly and assume it has the same output as `mkNugetDeps`. * `packNupkg` is used to pack project as a `nupkg`, and installs it to `$out/share`. If set to `true`, the derivation can be used as a dependency for another dotnet project by adding it to `projectReferences`. * `projectReferences` can be used to resolve `ProjectReference` project items. Referenced projects can be packed with `buildDotnetModule` by setting the `packNupkg = true` attribute and passing a list of derivations to `projectReferences`. Since we are sharing referenced projects as NuGets they must be added to csproj/fsproj files as `PackageReference` as well. @@ -100,7 +100,7 @@ To package Dotnet applications, you can use `buildDotnetModule`. This has simila * `dotnetPackFlags` can be used to pass flags to `dotnet pack`. Used only if `packNupkg` is set to `true`. * `dotnetFlags` can be used to pass flags to all of the above phases. -When packaging a new application, you need to fetch it's dependencies. You can set `nugetDeps` to an empty string to make the derivation temporarily evaluate, and then run `nix-build -A package.passthru.fetch-deps` to generate it's dependency fetching script. After running the script, you should have the location of the generated lockfile printed to the console. This can be copied to a stable directory. Note that if either `projectFile` or `nugetDeps` are unset, this script cannot be generated! +When packaging a new application, you need to fetch its dependencies. You can run `nix-build -A package.fetch-deps` to generate a script that will build a lockfile for you. After running the script you should have the location of the generated lockfile printed to the console, which can be copied to a stable directory. Then set `nugetDeps = ./deps.nix` and you're ready to build the derivation. Here is an example `default.nix`, using some of the previously discussed arguments: ```nix |