I do like the idea of being able to compose many sdk's. I will have to take a closer look when I get back from work

I can confirm this is something a Dot Net developer could need : I'm currently working on some legacy projects (2.2) and some new projects that are working with 3.0 only features (Like some Generic Hosts extensions).

I'll will give a try to this PR this week.

I've been using this work in a project of mine with no issues on Ubuntu, Windows WSL2, and a modified version of it for macOS. Excellent work and IMO exactly what I think the dotnet package should look like. @baracoder thank you!

I've only tried it with v3.1 (stable) of the SDK yet but that has been working without any issues for quite a few project.

Since 3.1 is stable by now it should also be added to the list.
To save you some time this is what I've used:

sdk_3_1 = buildNetCoreSdk {
  version = "3.1.100";
  sha512 = "0hvshwsgbm6v5hc1plzdzx8bwsdna2167fnfhxpysqs5mz7crsa4f13m4cxhrbn64lasqz2007nhdrlpgaqvgll6q8736h884aaw5sj";
};

Thank you all for the suggestions. I have updated the branch with the changes and replaced sdk_3_1_preview with sdk_3_1.
When using Rider, I had to run dotnet clean and invalidate cache to catch up.

Great! Maybe update the default version in pkgs/top-level/all-packages.nix too?

-  dotnet-sdk = dotnetCorePackages.sdk_2_2;
+  dotnet-sdk = dotnetCorePackages.sdk_3_1;

I am not sure about this change. This could break some of the packages, which depend on the current version of dotnet-sdk:

% grep -irnl dotnet-sdk
..
pkgs/applications/blockchains/wasabiwallet/default.nix
pkgs/development/python-modules/dotnetcore2/default.nix
pkgs/development/tools/build-managers/msbuild/default.nix
pkgs/servers/nosql/eventstore/default.nix
pkgs/servers/jellyfin/default.nix
pkgs/top-level/python-packages.nix

I am not sure about this change. This could break some of the packages, which depend on the current version of dotnet-sdk:

% grep -irnl dotnet-sdk
..
pkgs/applications/blockchains/wasabiwallet/default.nix
pkgs/development/python-modules/dotnetcore2/default.nix
pkgs/development/tools/build-managers/msbuild/default.nix
pkgs/servers/nosql/eventstore/default.nix
pkgs/servers/jellyfin/default.nix
pkgs/top-level/python-packages.nix

Ah, right. Never mind then - I suppose updating (which includes checking each of these and possibly fixing them to 2.2) warrants a separate issue in any case.

@worldofpeace do you see anything out of the ordinary? it LGTM

the reason why such a construction is necessary is:

dotnet makes the assumption that it's able to download missing sdk's/runtimes to a directory relative to the executable, which ends up being in the nix store, but if the sdk/runtime is already available, then it skips this step. By allowing the sdks/runtimes to be composed through the dotnetPackages.combinePackages function, we can make sure the packages are available, even from mismatching versions (e.g. dotnet_3_1 sdk needs to build a package with dotnet-sdk_2_2).

@baracoder I still haven't forgot this PR, I just keep getting sidetracked with other things :(

the problem with linking to sdk's as "runtimes" is that you don't really get any closure benefit, you bring in the whole other closure once you do that.

Thank you for testing and the input.

with dotnetCorePackages; combinePakcages { cli=sdk_3_1; withRuntimes=[ sdk_3_1 ]; withSdks=[ sdk_3_1 ]; }

Using the same sdk package in runtimes won't increase the closure size, as the directories are just linked.

I had the wrong assumption that explicitly specifying the runtime would decrease closure size for built packages, but this is false, because the cli from the combined package would be used and pull in all SDKs.
combinePackages is only be useful for development environments.

I will update the PR tomorrow.

also, I don't think the cli argument is necessary, could order the sdks and runtimes first by sdk, then by version, then just choose the first one.

I did not have time to update the pull request, but stumbled today on a nice nixpkgs function buildEnv. Which makes it look like I have tried to reinvent the wheel:

  latestCombined = buildEnv {
    name = "dotnet-combined-latest";
    paths = [ sdk_3_1 sdk_2_2 sdk_3_0 sdk_3_1 ];
    pathsToLink = [ "/host" "/packs" "/sdk" "/shared" "/templates" ];
    ignoreCollisions = true;
    postBuild = ''
      cp ${sdk_3_1}/dotnet $out/dotnet
      mkdir $out/bin
      ln -s $out/dotnet $out/bin/
    '';
  };

It works a little bit different but simplifies the process a lot.

This change pleases me greatly.

Sorry, for the delay, I forgot to ping.

I have updated the merge request. You can now get a combined package like this:

with dotnetCorePackages; combinePackages { packages = [ sdk_3_1 sdk_2_2 sdk_3_0 sdk aspnetcore_2_1 ]; }

The cli tool will be used from the first entry.

I have smuggled in another commit to fix the apphost binary, which is used to create executable files for projects with OutputType=exe. There is a catch though: If a library specifies a patch version of the environment like 3.0.1, it might download a nuget package containing a copy of apphost, which is not patched.

% find ~/.nuget/packages -iname apphost  
/home/bara/.nuget/packages/microsoft.netcore.app.host.linux-x64/3.0.1/runtimes/linux-x64/native/apphost

I'm happy with this for the time being. If it needs to be revisited we can do so in another PR.

This is a much needed improvement to nixpkgs, thanks @baracoder for up-streaming this :)

hydra built it https://hydra.nixos.org/eval/1565649#tabs-new . Once a successful release is done, we'll be able to use this on unstable :)

I made a pull request to add the missing runtimes and use it with Jellyfin : #77961

How would I go about using this combinePackages from nix-env? Do I need to create a .nix file and install that or put it in my nix config instead?

@Jumblemuddle I am using nix repl to intsall it in my profile:

$ nix repl /path/to/nixpkgs
nix-repl> :i with dotnetCorePackages; combinePackages [ sdk_3_1 sdk_2_2 sdk_3_0 aspnetcore_2_1 ]

Don't know if it is possible with nix-env

I would probably use a shell.nix in the repository that you need it:

with import <nixpkgs> {};

mkShell rec {
  name = "dotnet";
  buildInputs = [
    (with dotnetCorePackages; combinePackages [ sdk_3_1 sdk_2_1 ])
  ];
}

doing nix-shell will then read in the shell.nix and give you a dotnet with:

$ dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   3.1.100
 Commit:    cd82f021f4

Runtime Environment:
 OS Name:     nixos
 OS Version:  20.03pre209250.7184df6beb8
 OS Platform: Linux
 RID:         linux-x64
 Base Path:   /nix/store/cdns908qgng8rk0ngm1dqrd5q1qqnhqa-dotnet-sdk-3.1.100/sdk/3.1.100/

Host (useful for support):
  Version: 3.1.0
  Commit:  65f04fb6db

.NET Core SDKs installed:
  2.1.509 [/nix/store/sdsv8i00h54iii9j8wsrxkjplvmc8z3m-dotnet-core-combined/sdk]
  3.1.100 [/nix/store/sdsv8i00h54iii9j8wsrxkjplvmc8z3m-dotnet-core-combined/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.13 [/nix/store/sdsv8i00h54iii9j8wsrxkjplvmc8z3m-dotnet-core-combined/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.13 [/nix/store/sdsv8i00h54iii9j8wsrxkjplvmc8z3m-dotnet-core-combined/shared/Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.0 [/nix/store/sdsv8i00h54iii9j8wsrxkjplvmc8z3m-dotnet-core-combined/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.13 [/nix/store/sdsv8i00h54iii9j8wsrxkjplvmc8z3m-dotnet-core-combined/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.0 [/nix/store/sdsv8i00h54iii9j8wsrxkjplvmc8z3m-dotnet-core-combined/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

once #77961 gets merged, and I write up some documentation, the I'll probably backport this to 19.09 so they can use it as well

🤦‍♂️ I have made an error in copying things from src: cp ./ will copy env-vars which pulls the source tar.gz package into the runtime closure

% nix why-depends /nix/store/8w7566287q3zalhn0xixl9610ssqirfx-dotnet-sdk-3.1.100 /nix/store/cc94mviqcb0wpqq5488p7a0ggp8v3hny-dotnet-sdk-3.1.100-linux-x64.tar.gz
/nix/store/8w7566287q3zalhn0xixl9610ssqirfx-dotnet-sdk-3.1.100
╚═══env-vars: …=".".declare -x src="/nix/store/cc94mviqcb0wpqq5488p7a0ggp8v3hny-dotnet-sdk-3.1.100-linux-x64.ta…
    => /nix/store/cc94mviqcb0wpqq5488p7a0ggp8v3hny-dotnet-sdk-3.1.100-linux-x64.tar.gz

noDumpEnvVars=true; should fix this. I will create a PR

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/why-cant-i-install-dotnet-in-my-rust-build-environment-shell/5786/1

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/what-are-your-goals-for-20-03/4773/16