NixOS / nixpkgs

Nix Packages collection & NixOS
MIT License
17.15k stars 13.42k forks source link

Limited documentation on the dotnet/mono framework #28294

Open wizzup opened 7 years ago

wizzup commented 7 years ago

Issue description

While the dotnet framework is documented in the nixpkgs manual, it is currently not very thorough. The internals of the framework used for building dotnet applications (buildDotnetModule) are mostly undocumented right now.

Documentation for using mono is also completely missing.

disassembler commented 7 years ago

It would be great to have some documentation, although I'm guessing there aren't a whole lot of people using dotnet on nixos. Here's a slide deck I found that has some info that might help you out though.

https://www.slideshare.net/sandervanderburg/vanderburg10-dotnetnix

baracoder commented 5 years ago

Stumbled on this issue by accident (triage). By now we have in addition to mono a dotnet-sdk package. I am interested in building and running dotnet-sdk on Linux, which seams to be a different use case then described in the mentioned slides. I have started working on a tool which could help building dotnet-sdk projects with NuGet dependencies. https://github.com/baracoder/dotnet2nix

teto commented 5 years ago

I was interested in packaging the microsfot python LSP server but I hit the absence of doc too.

stale[bot] commented 4 years ago

Hello, I'm a bot and I thank you in the name of the community for opening this issue.

To help our human contributors focus on the most-relevant reports, I check up on old issues to see if they're still relevant. This issue has had no activity for 180 days, and so I marked it as stale, but you can rest assured it will never be closed by a non-human.

The community would appreciate your effort in checking if the issue is still valid. If it isn't, please close it.

If the issue persists, and you'd like to remove the stale label, you simply need to leave a comment. Your comment can be as simple as "still important to me". If you'd like it to get more attention, you can ask for help by searching for maintainers and people that previously touched related code and @ mention them in a comment. You can use Git blame or GitHub's web interface on the relevant files to find them.

Lastly, you can always ask for help at our Discourse Forum or at #nixos' IRC channel.

r-k-b commented 4 years ago

still important to me; the kind of documentation I'm looking for would cover what to do with errors such as MSB4242: The SDK resolver "Microsoft.DotNet.MSBuildSdkResolver" failed to run and You must add a reference to assembly netstandard, Version=2.0.0.0

stale[bot] commented 3 years ago

I marked this as stale due to inactivity. → More info

jonringer commented 3 years ago

I added some initial documentation here: https://github.com/NixOS/nixpkgs/blob/master/doc/languages-frameworks/dotnet.section.md

jonringer commented 3 years ago

contributions are welcome.

stale[bot] commented 3 years ago

I marked this as stale due to inactivity. → More info

YoshiRulz commented 3 years ago

I'm interested in packaging libraries, but there's little documentation or pre-existing code to reference, and .NET Framework (Mono runtime) isn't "first-class" alongside .NET Core. (Is there a better term for that?) I think .NET language support could use some direction at a high level.

jonringer commented 3 years ago

I'm interested in packaging libraries, but there's little documentation or pre-existing code to reference, and .NET Framework (Mono runtime) isn't "first-class" alongside .NET Core. (Is there a better term for that?) I think .NET language support could use some direction at a high level.

Agreed, but in nixpkgs, it largely just takes one person with some domain expertise and will to implement something.

IvarWithoutBones commented 2 years ago

Here is some documentation for the new buildDotnetModule framework, in case that helps: https://nixos.org/manual/nixpkgs/unstable/#packaging-a-dotnet-application.

It's not very thorough just yet, but I'll add to it in the future.

kirinnee commented 2 years ago

Here is some documentation for the new buildDotnetModule framework, in case that helps: https://nixos.org/manual/nixpkgs/unstable/#packaging-a-dotnet-application.

It's not very thorough just yet, but I'll add to it in the future.

How does this work with fetchNuget functionality? Are there easy ways to convert already publish Nuget packages (such as global tools)?

Apologise ahead of time, I am not too familiar with Nix itself

IvarWithoutBones commented 2 years ago

How does this work with fetchNuget functionality?

It doesn't use fetchNuget right now, instead we create our own nix-based lockfile containing version information and hashes for all nuget dependencies instead of fetching them manually.

Are there easy ways to convert already publish Nuget packages (such as global tools)?

You could set the packNupkg attribute if you can compile it from source, but installing it as a dotnet tool might take a bit more effort. We currently don't have any setup in place for it, although I do plan to get on that in the future. Would you mind sharing what tool you need, and how you would like to use it? I'd be happy to test it while adding the functionality to install global tools to buildDotnetModule.

Apologise ahead of time, I am not too familiar with Nix itself

No need to apologise! Always feel free to ask any questions :blush:

Knowing what functionality the community needs is very benefitial for developing our dotnet framework, I'd heavily encourage anyone to open up an issue and tag me if you have any requests or questions.

kirinnee commented 2 years ago

Thank you so much for your reply!

I'd like to use dotnet-ef and I've already made a packaging request about it here. Personally, I have been testing on how to package the simplest CLI tool, dotnetsay.

I am fairly limited in my knowledge of the inner workings and best-practice of .NET landscape, but would it be possible to use makeWrapper and use ${pkgs.dotnet}/bin ${self}/lib/..../tool.dll where self is the fetchNuget already builds all dll. I assume this would make it platform and OS independent. What would be the caveats around this method?

Here is my current implementation:

{ nixpkgs ? import <nixpkgs> { } }:
with nixpkgs;

{
  dotnetsay = (
    let src = fetchNuGet {
      pname = "dotnetsay";
      baseName = "dotnetsay";
      version = "2.1.7";
      sha256 = "sha256-wZ/w1d4STZrOeeQQJH1EXF7LUhNLCodXmghEFUYhN4g=";
      outputFiles = [ "*" ];
      postUnpack = ''
        chmod -R +r .
      '';
    }; in
    pkgs.writeShellScriptBin "dotnetsay" ''
      ${nixpkgs.dotnet-runtime}/bin/dotnet "${src}/lib/dotnet/dotnetsay/tools/netcoreapp2.1/any/dotnetsay.dll" $@
    ''
  );
}
IvarWithoutBones commented 2 years ago

I am fairly limited in my knowledge of the inner workings and best-practice of .NET landscape, but would it be possible to use makeWrapper and use ${pkgs.dotnet}/bin ${self}/lib/..../tool.dll where self is the fetchNuget already builds all dll. I assume this would make it platform and OS independent. What would be the caveats around this method?

That would use the cross platform executable, instead of a native one. Not a huge issue, but it means startup times will be a bit slower. It's also not building from source, but instead using a fetched DLL. Should work fine as a temporary workaround though :+1: