.NET Core SDK and debugging unit tests in IDE

Guides
1

When using a dotnetCorePackages.sdk_3_1 based “dotnet” in the debugger in Rider I have been unable to find symbols and show frames in the debugger when debugging test code. Have anybody using dotnet-sdk and rider any experience with such problems?

The problem is only present when debugging ‘test-runner’ code. When debugging console app, the debugger works fine. When creating xUnit test project (using Microsoft.NET.Test.Sdk, xunit, xunit.runner.visualstudio (nuget) packages) the tests cannot be debugged with symbols and frames from within the IDE.

I would be greatfull if anybody have a fix for this unfortunate situation.

2

I am not running NixOS, so I can verify that the official debian based (i.e. MS provided ubuntu installer) does work. Also the dotnet-sdk have recently been ported to darwin, and on darwin the dotnet executable , native binaries (aka apphosts) and all shared libs (*.so) of the downloaded tarball is not patched. If it is any help I have verified that debugging in the IDE (both vscode using vsdbg) and rider (using jetbrains own debugger) does work on mac os x, when using the nixpks-provided dotnet-sdk (sdk_3).

@jonringer Sorry to ping you, but being new to nixpkgs, you are the only person I have been able to find connected to the dotnetPackages subtree of nix expressions…and you work at Microsoft, so maybe you know some of the internals of the vsdbg debugger running in vscode (and maybe also some of the internals of the jetbrains debugger?)

It has to be some impurity, but I have no idea how to enhance my nix-based .NET SDK, and right now my only option is to stop using nix/nixpkgs for .NET developer tooling

3

I think the main issue is that we strip the binaries when building the sdks. It probably makes sense to also include derivations which include debugging symbols:

rewriting symlink /nix/store/drzlw6fx8wqhgq4j8jh8vnl3kgcfvjx5-dotnet-sdk-3.1.102/bin/dotnet to be relative to /nix/store/drzlw6fx8wqhgq4j8jh8vnl3kgcfvjx5-dotnet-sdk-3.1.102
strip is /nix/store/0x8pbk0578knfpxf9gbl0lhmpynh2947-binutils-2.31.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/drzlw6fx8wqhgq4j8jh8vnl3kgcfvjx5-dotnet-sdk-3.1.102/bin
patching script interpreter paths in /nix/store/drzlw6fx8wqhgq4j8jh8vnl3kgcfvjx5-dotnet-sdk-3.1.102

to get you temporarily unblocked, you may be able to try:

dotnetCorePackages.sdk_3_1.overrideAttrs(oldAttrs: { dontStrip = true; })

I’m not sure what the “api” would be, but my first inclination would be:

dotnetCorePackages.debugPackages.sdk_3_1

another alternative would be to just not strip the sdk’s as they are likely to be used in dev scenarios anyway.

4

I tried doing dontStrip, and it doesn’t seem to change the derivation size. I will need to look into this more. Unfortunately I also have a lot on my plate, and don’t have a current need for a dotnet dev kit.

For now I would recommend not using nix/nixpkgs if you need a local dev workflow. However, I would be open to reviewing a PR if you have improvements to the tooling.

5

Have anybody using dotnet-sdk and rider any experience with such problems?

For what it’s worth, I’m seeing the same. Rider debugger gives “Frame not available” in xUnit tests when dotnet is installed via Nix, both on NixOS and non-NixOS. dontStrip does not make difference, as expected. Console apps are fine.

6

After moving from NixOS at 22a81aa5fc1 to a45f68ccac47, I’m not able to reproduce this anymore. This includes upgrading dotnet from 3.1.2 to 3.1.5 - maybe that did the trick?

EDIT: Sorry, this doesn’t seem to be related to any of those updates. Nevertheless, I currently don’t have any problems debugging .NET Core with Rider on NixOS. Tested with Rider 2019.3.4 and 2020.1.4, .NET Core SDK 3.1.2 and 3.1.5 and nixos-unstable at 22a81aa5fc1 and a45f68ccac47.