Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

relative/absolute path issues in shim after installing donet tool

See original GitHub issue

After installing dotnet-sdk-2.1.300-rc1-008673 on Linux, Installed packages using --tool-path produces a shim that cannot locate the actual tool dll correctly.

Steps to reproduce

sudo apt-get install dotnet-sdk-2.1.300-rc1-008673 -y
dotnet tool install --version 1.0.0-beta0003 --tool-path tools
.\tools\csmacnz.Coveralls --help

Example Results on appveyor:

Expected behavior

The application dll executes via the shim application (equivalent to dotnet csmacnz.Coveralls.dll)

Actual behavior

The shim trys to use the wrong path on linux

The application to execute does not exist: '/home/appveyor/projects/dotnettoolsbugrepro/tools/..//home/appveyor/projects/dotnettoolsbugrepro/tools/.store/'.
Command exited with code 154

This path looks like it is incorrectly appending an absolute path in place of a relative one. (I don’t know about the ../ part though.)

Broken build example here

I have also verified that /home/appveyor/projects/dotnettoolsbugrepro/tools/.store/ does exist.

Note also that this worked fine on build dotnet-sdk-2.1.300-preview2-008533 on Linux (see Previous passing build in test repo) and this also works with the rc1 version running under windows

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.300-rc1-008673
 Commit:    f5e3ddbe73

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  16.04
 OS Platform: Linux
 RID:         ubuntu.16.04-x64
 Base Path:   /usr/share/dotnet/sdk/2.1.300-rc1-008673/
Host (useful for support):
  Version: 2.1.0-rc1
  Commit:  eb9bc92051

.NET Core SDKs installed:
  1.1.5 [/usr/share/dotnet/sdk]
  1.1.6 [/usr/share/dotnet/sdk]
  1.1.7 [/usr/share/dotnet/sdk]
  2.0.0 [/usr/share/dotnet/sdk]
  2.0.2 [/usr/share/dotnet/sdk]
  2.0.3 [/usr/share/dotnet/sdk]
  2.1.2 [/usr/share/dotnet/sdk]
  2.1.3 [/usr/share/dotnet/sdk]
  2.1.4 [/usr/share/dotnet/sdk]
  2.1.101 [/usr/share/dotnet/sdk]
  2.1.300-rc1-008673 [/usr/share/dotnet/sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0-rc1-final [/usr/share/dotnet/shared/Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0-rc1-final [/usr/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 1.0.8 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.0.9 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 1.1.6 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.0 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.3 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.4 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.5 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.6 [/usr/share/dotnet/shared/Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.0-rc1 [/usr/share/dotnet/shared/Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:

Issue Analytics

  • State:closed
  • Created 5 years ago
  • Comments:22 (11 by maintainers)

github_iconTop GitHub Comments

peterhuenecommented, May 29, 2018

Closed as fixed with dotnet/cli#9330. Thanks again @csMACnz for reporting this issue for us! It made it a little too late to get it into the RTM of 2.1.300 (the upcoming .NET Core 2.1 release), but we hope to port this fix from release/2.1.4xx into a service release for 2.1.3xx. For now, the workaround is to use an absolute path for the --tool-path option on macOS and Linux.

@livarcocc do we have a place to record 2.1.3xx servicing fixes?

peterhuenecommented, May 21, 2018

I was also able to reproduce and I suspect you’re right that something is tripping up GetRelativePath. Assigning this over to you for now.

Read more comments on GitHub >

github_iconTop Results From Across the Web

relative/absolute path issues in shim after installing donet tool
I have a repo. Use full path as workaround can mitigate it for now. dotnet tool install --version 1.0.0-beta0003 --tool- ...
Read more >
Troubleshoot .NET tool usage issues
If you're trying to run a global tool, check that the PATH environment variable on your machine contains the path where you installed...
Read more >
Found multiple publish output files with the same relative ...
Issue : The issue raises after .NET 6 migration. There's a new feature that blocks multiple files from being copied to the same...
Read more >
Builds fail when path to csproj is really long
The dependency project's csproj has the 192 character absolute path. When the build process enters the build step for the main project, it...
Read more >
Importing third-party issues - SonarQube Docs
This page lists analysis parameters related to the import of issues raised ... the following properties accept both absolute paths and paths relative...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found