I am trying to use migrate-2017 to migrate some csproj files to the new more concise vs2017 project format. I installed the tool from https://github.com/hvanbakel/CsprojToVs2017 using the command:
dotnet tool install --global Project2015To2017.Migrate2017.Tool
When I try to use it I get this:
C:\projects\Trilogy\Main>dotnet migrate-2017 wizard
No executable found matching command "dotnet-migrate-2017"
However, it appears to exist....
C:\projects\Trilogy\Main>dotnet tool list -g
Package Id Version Commands
------------------------------------------------------------------------
project2015to2017.migrate2017.tool 4.0.0 dotnet-migrate-2017
The global.json looks fine....
C:\projects\Trilogy\Main>type global.json
{
"sdk": {
"version": "2.1.602"
}
}
And so does the version:
C:\projects\Trilogy\Main>dotnet --version
2.1.602
I'm using dotnet CLI tools for the first time, so what obvious thing am I missing?
I don't think you're missing anything, but here's a few things to try:
Does running dotnet-migrate-2017 work (no dotnet required first)?
Does the tool exist under %userprofile%\.dotnet\tools?
Have you tried restarting the command prompt to force refresh your %PATH%?
Have you tried uninstalling and reinstalling the package?
Related
I have installed the dotnet-ef and a number of other packages but for some reason, I can't use them.
I added $HOME/.dotnet/tools as shown here:
https://learn.microsoft.com/en-us/dotnet/core/tools/troubleshoot-usage-issues
but running dotnet tool list still shows no packages.
Please note that dotnet tool list command checks for local tools by default. Try dotnet tools list -g to look for globally installed tools. Make sure your PATH contains the global tools folder location before running the installed tool. You can check your PATH by running echo $PATH. You can also check globally installed tools by running dotnet tool list --tool-path $HOME/.dotnet/tools. Following steps work for me:
dotnet tool install --global dotnet-ef
export PATH="$PATH:$HOME/.dotnet/tools"
dotnet tool list -g
dotnet-ef
HTH
I'm trying to build a Release pipeline that is triggered by a new version of a published dotnet core tool. The trigger works fine, but I'm unable to install and run the tool in my Tasks.
CURRENTLY:
Running a Command Line Task results in a 401:
dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp
C:\Program Files\dotnet\sdk\3.0.100\NuGet.targets(123,5): error : Unable to load the service index for source https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json. [C:\Users\VssAdministrator\AppData\Local\Temp\h0g1c35v.eny\restore.csproj]
C:\Program Files\dotnet\sdk\3.0.100\NuGet.targets(123,5): error : Response status code does not indicate success: 401 (Unauthorized). [C:\Users\VssAdministrator\AppData\Local\Temp\h0g1c35v.eny\restore.csproj]
The tool package could not be restored.
Tool 'myapp' failed to install. This failure may have been caused by:
* You are attempting to install a preview release and did not use the --version option to specify the version.
* A package by this name was found, but it was not a .NET Core tool.
* The required NuGet feed cannot be accessed, perhaps because of an Internet connection problem.
* You mistyped the name of the tool.
For more reasons, including package naming enforcement, visit https://aka.ms/failure-installing-tool
This leads me to believe that I'm missing something here, making it more complicated than it needs to be, or thinking about this the wrong way. The tools in the feed can be installed locally, so I believe it's my release approach.
I'm currently looking into Personal Access Tokens (PAT)
PREVIOUSLY:
If I use the .Net Core task and the custom option:
The logs show a malformed command passed to dotnet.exe:
[command]"C:\Program Files\dotnet\dotnet.exe" "dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp"
or
[command]"C:\Program Files\dotnet\dotnet.exe" "tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp"
I've tried varying arguments and I tend to always see the same error message:
Could not execute because the specified command or file was not found.
Possible reasons for this include:
* You misspelled a built-in dotnet command.
* You intended to execute a .NET Core program, but dotnet-dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp does not exist.
* You intended to run a global tool, but a dotnet-prefixed executable with this name could not be found on the PATH.
Your custom dotnet command is quoted and dotnet is repeated : dotnet.exe" "dotnet tool install ..." so the command is misinterpreted.
You can use the Command Line task and set the dotnet command directly :
dotnet tool install -g --add-source=https://pkgs.dev.azure.com/<org-name>/_packaging/Tools/nuget/v3/index.json MyApp
Using the .Net Core task works perfect for us.
Since the dotnet command is quoted, you need to set tool as the command and update into arguments. NuGet credentials can be provided with NuGet Auth task if needed.
Here is my walkaround:
I firstly published my private dotnet tool nupkg file also as an universal package to the same Azure Artifacts feed.
I was able to then use Universal Package task to download the .nupkg file into $(System.DefaultWorkingDirectory)/nupkgs/. This task will handle the authorization to Azure Artifacts feeds.
steps:
- task: UniversalPackages#0
displayName: 'Download mytool.cli.universal'
inputs:
downloadDirectory: '$(System.DefaultWorkingDirectory)/nupkgs/'
vstsFeed: '63d4aa2f-3ae7-4c27-8c18-aa8e3a9ff353'
vstsFeedPackage: '916d9a27-2c07-4071-8631-377f2ac08ed7'
vstsPackageVersion: 0.2.0
I then had the DotNetCoreCLI task to install my nupkg locally in agents.
steps:
- task: DotNetCoreCLI#2
displayName: 'Install mytool as a dotnet tool'
inputs:
command: custom
custom: tool
arguments: 'install --global mytool.CLI --add-source ./nupkgs --version 0.2.0'
You need to add the nuget authenticate task before you try to access the nuget feed
I'm trying to use dotnet-warp as a global tool in my .NET Core Travis-CI build, because I like the idea of a single executable so much better than a folder full of 75ish files.
I can successfully add the tool and verify there's a tools/dotnet folder in the $PATH...
But the log indicates that because .NET Core has been added recently, I'll need to restart or logout before I can actually use the tool.
Is anyone aware of a way to make this work in the Travis-CI environment?
Ran into the same issue, using the info from the Travis CI Installing Dependencies page and this comment on an issue about it, adding the following following to to my .travis.yml solved the problem:
before_script:
- export PATH=$PATH:/home/travis/.dotnet/tools
My build log:
$ export PATH=$PATH:/home/travis/.dotnet/tools
$ dotnet tool install -g dotnet-warp
You can invoke the tool using the following command: dotnet-warp
Tool 'dotnet-warp' (version '1.0.9') was successfully installed.
The command "dotnet tool install -g dotnet-warp" exited with 0.
$ cd ./src/[my project]/
The command "cd ./src/[my project]/" exited with 0.
$ dotnet-warp
Running Publish...
Running Pack...
Saved binary to "[my project]"
The command "dotnet-warp" exited with 0.
I'm installing dotnet core on Linux ARM64 using tarball as explained here. After installing I followed the suggestion to set DOTNET_ROOT=$PATH:$HOME/dotnet. However global tools fail with A fatal error occurred, the required library libhostfxr.so could not be found.
I fixed by changing the env variable to DOTNET_ROOT=$HOME/dotnet.
Is this a bug in the docs ?
Yes, this appears to be a bug in the documentation. The code which interprets DOTNET_ROOT does not split the string on :. DOTNET_ROOT should be set to an absolute file path which points to the directory containing the dotnet executable. If dotnet is on your PATH already, you can set it like this in bash/zsh.
export DOTNET_ROOT="$(dirname $(which dotnet))"
came across this problem while working on porting .net libraries from Windows to Raspberry PI. On the Raspberry the .net core 3.1 installs in /opt/dotnet, and that's where DOTNET_ROOT ought to point at:
export DOTNET_ROOT="/opt/dotnet"
This should eliminate the "fatal error occurred. The required library libhostfxr.so could not be found." error when attempting to run portable code using the 'dotnet' command on the RPI
I was getting an error trying to execute the dotnet ef from the EF cli global tools install.
Added this to the bottom of my /home/<user>/.bashrc worked for me.
# User specific aliases and functions
export DOTNET_ROOT=$HOME/.dotnet
export PATH=$PATH:$DOTNET_ROOT:$DOTNET_ROOT/tools
Then the dotnet ef command worked correctly.
I had to add this to my ~/.zshrc
export DOTNET_ROOT=~/.dotnet
export PATH=$PATH:$DOTNET_ROOT
I found that I had different locations for different sdk/runtime versions. One was installed at "/home/{username}/.dotnet" and the other at "/usr/share/dotnet".
I found a post stating the default DOTNET_ROOT is "/usr/share/dotnet" and errors showed dotnet command was executing this location. I copied all files from "home/{username}/.dotnet" to "/usr/share/dotnet" with rsync.
sudo apt install rsync;
sudo rsync -a /home/{username}/.dotnet/ /usr/share/dotnet
I want to create custom build task, that would do invoke dotnet core CLI tool. I've used VSTS DevOps Task SDK/node to get or install the tool:
import tl = require('vsts-task-lib/task');
async function getLibmanTool() {
let libmanExePath = tl.which('libman');
if (!libmanExePath){
console.log("Libman CLI not found. Installing..")
var dotnet = tl.tool(tl.which('dotnet', true));
await dotnet.arg(['tool', 'install', '-g', 'Microsoft.Web.LibraryManager.Cli']).exec();
}
libmanExePath = tl.which('libman', true); //this line throws, see output
return tl.tool(libmanExePath);
}
However, when I use the tool in Build Pipeline:
I'm getting following error:
Libman CLI not found. Installing..
[command]C:\hostedtoolcache\windows\dncs\2.1.105\x64\dotnet.exe tool install -g Microsoft.Web.LibraryManager.Cli
Since you just installed the .NET Core SDK, you will need to reopen the Command Prompt window before running the tool you installed.
You can invoke the tool using the following command: libman
Tool 'microsoft.web.librarymanager.cli' (version '1.0.163') was successfully installed.
##[error]Unable to locate executable file: 'libman'. Please verify either the file path exists or the file can be found within a directory specified by the PATH environment variable. Also verify the file has a valid extension for an executable file.
It look like when I install .NET Core SDK in the pipleline, it is unable to find the dotnet tool
Question:
How do I install and then safely use the dotnet core tool? Is the any way to workaround following?
Since you just installed the .NET Core SDK, you will need to reopen the Command Prompt window before running the tool you installed
There isn't any workaround to avoid reopening the CMD as far as I know.
To get it work, you could specify the install path when installing the package and then call the full path to the liman.exe. Or if you want to install it globally with "-g", then the path to the liman.exe should be "%USERPROFILE%\.dotnet\tools\liman.exe".