Go To Declaration doesn't consider RID for a Nuget package
I'm developing a OS-specific library with bunch of #if directives. As an example, consider the following method:
and for that library, my
.nupkg
consists of the following files/folders:
- lib\net9.0\MyLib.dll -> fallback binary if no suitable runtime is found. Call to Method1()
throws PlatformNotSupportedException
- ref\net9.0\MyLib.dll -> reference-assembly for API surface
- runtimes\win-x64\lib\net9.0\MyLib.dll -> binary for Windows. Call to Method1()
outputs Win
- runtimes\linux-x64\lib\net9.0\MyLib.dll -> binary for Linux. Call to Method1()
outputs Linux
When the library is imported and the method Method1()
is called — everything works as expected.
Issue:
When I Ctrl+Click (Go To Declaration) on the method to explore its internals, it does not consider RID
and displays the fallback-binary from lib\
folder, where the method just throws, making "Go To Declaration" useless.
Whereas during debugging, stepping into the method DOES work, displaying the correct, decompiled, runtime-specific binary.
Desired behavior:
"Go To Declaration" considers RID
and decompiles runtime-specific binary from runtimes\
folder.
Tried:
Specifying RID
during package restore: dotnet restore -r win-x64
, and unfortunately, it didn't do the trick.
Question:
Is that me who packed binaries incorrectly, or I have to dig into Rider's behavior?
12 Replies
Attaching
.csproj
(library project file) and .nuspec
(used for packing)why proprocessor directives instead of
OperatingSystem.IsWindows()
(etc)?to avoid runtime checks, since the entire lib is going to be OS specific
OperatingSystem
does not do runtime checks
the check is compiled outI know, I meant runtime checks of
.IsWindows()
, etcyes, that is compiled out
sharplab compilation targets windows

as such, the call is completely elided
well, I don't know then. This is my first time writing OS-specific library, so I'm a complete noob in it
then i would recommend using that instead :)