When I try to add a NuGet package via the dotnet cli I get an error that it can't access one of my custom NuGet sources. Is there a way to say "I don't care, restore from where you can"?
McMaster.Extensions.CommandLineUtils clearly it exists in NuGet.org and it finds it but then stops b/c it can't access a custom source 🤷♂️.
PS c:\Temp\blah-project> dotnet add package McMaster.Extensions.CommandLineUtils
info : Adding PackageReference for package 'McMaster.Extensions.CommandLineUtils' into project 'c:\Temp\blah-project\blah-project.csproj'.
info : Restoring packages for c:\Temp\blah-project\blah-project.csproj
info : GET https://api.nuget.org/v3-flatcontainer/mcmaster.extensions.commandlineutils/index.json
info : OK https://api.nuget.org/v3-flatcontainer/mcmaster.extensions.commandlineutils/index.json 147ms
error: Unable to load the service index for source https://myinstace.pkgs.visualstudio.com/_packaging/Blah/nuget/v3/index.json.
error: Response status code does not indicate success: 401 (Unauthorized).
The dotnet command has the option to specify --source. This allows you to only restore packages from a specific location, in this case you'd want to use
dotnet restore --source https://api.nuget.org/v3/index.json`
This should pull the packages down to your local NuGet store and solve the problem on your machine.
In order to add the package to your project you may need to manually add a <PackageReference> to your project like
<PackageReference Include="McMaster.Extensions.CommandLineUtils" Version="2.6.0" />
Then running the restore command above will get the package for you.
As a more-permanent fix, you should put a nuget.config file in the root of the project/repository where you specify the package sources for that specific project. There are settings that you can set to override your system's global nuget configuration/sources. See more information on nuget.config. You can create a starting nuget.config in your repo with dotnet new nugetconfig
while restoring packages, dotnet make a call to all the package sources to get the package and uses the one that responds first.
In your case, because of some authentication issue it is not able to access that source. That source can be disabled using the below command and then try to pull the package.
dotnet nuget disable source <NAME> [--configfile <FILE>]
You might be able use the --ignore-failed-sources option.
I'd recently encountered similar issues when having authentication problems on a private feed, this allowed me to install the packages (was actually a tool using dotnet tool install) and address my auth issue at a later date.
See https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-restore for more info and options.
Related
I am building a dotnet core tool and I am having trouble installing it globally. I can replicate the problem I am having but don't know how to fix it. Below are my steps
dotnet new console -o testconsole
Modify testconsole.csproj to include <PackAsTool> and <PackageOutputPath>
testconsole.csproj
dotnet restore testconsole.csproj
dotnet build testconsole.csproj
dotnet pack testconsole.csproj
dotnet tool install -g -v d --add-source ./nupkg testconsole
When installing I receive the below error
error NU1212: Invalid project-package combination for TestConsole 1.0.9. DotnetToolReference project style can only contain references of the DotnetTool type
install error
Here is a copy of testconsole.nuspec from the nupkg that includes
<packageType name="DotnetTool" /> per the suggestion from https://natemcmaster.com/blog/2018/05/12/dotnet-global-tools/
testconsole.nupsec
After finding the root cause, this error is hilarious, but also an indication of systematic issue.
Do you see this part of the warning in your output?
Package 'TestConsole 1.0.9' was restored using '.NETFramework,Version=v4.6.1' instead of the project target framework '.NETCoreApp,Version=v2.1'. This package may not be fully compatible with your project
What is this version 1.0.9? Where is .NET Framework 4.6.1 coming from? There's nothing like that in the .NET Core SDK (I looked through the sources) or under the testconsole directory on my disk.
Lets reduce the logging verbosity and re-run out install command:
$ dotnet tool install -g -v n --add-source ./nupkg testconsole
Build started 2018-09-26 7:16:47 p.m..
1>Project "/tmp/q2whkgqf.tbt/restore.csproj" on node 1 (Restore target(s)).
1>Restore:
Restoring packages for /tmp/q2whkgqf.tbt/restore.csproj...
CACHE https://api.nuget.org/v3-flatcontainer/testconsole/index.json
CACHE https://api.nuget.org/v3-flatcontainer/testconsole/1.0.9/testconsole.1.0.9.nupkg
Installing TestConsole 1.0.9.0.
Look at the last few lines carefully. dotnet tool install is trying to install https://www.nuget.org/packages/TestConsole/. Not your local testconsole nuget package!
You can work around it in a couple of ways:
Give your tools a really unique name that doesn't clash with anything on nuget.org or in your organization's nuget feed.
Add a nuget.config that <clear/>s the nuget feeds so only the ./nupkg directory is used as feed when looking to install testconsole.
Building on Omair's answer, the practical steps to solving this problem:
1. Create disable_nuget.config to disable reading from the global feed
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<disabledPackageSources>
<add key="nuget.org" value="true" />
</disabledPackageSources>
</configuration>
note: give it a special name so that it doesn't get picked up by nuget by accident when you don't want it to
2. Install the tool referencing the special nuget configuration
dotnet pack
dotnet tool install --global --configfile disable_nuget.config --add-source ./nupkg TestConsole
Some weeks ago, I followed this tutorial to get started with dotnet core + vue.js.
The steps to install the template were:
Install the SPA (Single Page Application) templates provided by Microsoft:
dotnet new --install Microsoft.AspNetCore.SpaTemplates::*
To get started and create a new Vue project, simply run the following commands on the console:
mkdir new-project
cd new-project
dotnet new vue
It worked perfectly (I repeat: that was some weeks ago).
Now I've repeated the same steps in the same machine and it says "There are no templates that match the name of the input template: vue" =>
Have the vue.js template been discontinued during the last weeks? Or am I doing something wrong?
After other comments saying it was working for them, and knowing that it worked for me some weeks ago, I've finally figured out what is going on:
On my "Available package sources" (NuGet config) in VS2017, I had the nuget nuget repository from work [work-repo]. I have to connect via VPN to be able to access it (and I wasn't during my tests). I didn't have it connected some weeks ago when the whole process worked perfectly.
Now, when I was executing dotnet new --install Microsoft.AspNetCore.SpaTemplates::*, the first lines were informing me that "I am not able to connect o [work-repo]". But then it seemed to continue as if nothing happened, and I ignored it because I didn't see it as something that would have anything to do with "not seeing vue".
Once I removed [work-repo] from the sources list, I have been able to see the "vue" template again. I have installed it via dotnet new vue and it works perfectly.
tl;dr: If you have "Nuget package sources" that are not accessible at the moment, the process "Install the SPA templates provided by Microsoft" doesn't work.
I had the same issue. In my case, the issue occured after installing Visual Studio 2019. After struggling for a while I found out that
the NuGet V2 package source was completely missing.
After going to Tools -> Options -> NuGet Package Manager -> Package Sources, adding https://www.nuget.org/api/v2/, the vue-template appreared after running that command:
dotnet new --install Microsoft.AspNetCore.SpaTemplates::*
I similarly found this wasn't working, and the problem was also having a private repository (that needed authentication rather than being completely inaccessible). The simplest solution for me was to list the nuget packages using 'nuget sources', check the name of the private repository, use 'nuget sources Disable -Name [privatereponame]' to temporarily disable the repo, then run 'dotnet new --install Microsoft.AspNetCore.SpaTemplates::*' to install the new templates, and finally 'nuget sources Enable -Name [privatereponame]' to re-enable the private repo that was causing the problem.
I had the same problem and it was Telerik source/package causing the issue. Once I removed iy from the "Available package sources" (just like Xavier suggests), the SpaTemplates install completed without error
Its so simple: just run
dotnet new search vue
then follow the instruction
and then select a template, enjoy
We have a Xamarin app running smoothly, but after latest update to Xamarin and Android Packages, we started receiving this error, the update changed Android Support version from 25.1.0 to 25.1.1:
Error: package android.support.v7.media.RemotePlaybackClient does not exist
check detail of error :
/Users/abd/Programming/Gits/Rental/Rental/Rental/Rental.Droid/obj/Debug/android/src/mono/android/support/v7/media/RemotePlaybackClient_OnMessageReceivedListenerImplementor.java(48,48): Error: error: package android.support.v7.media.RemotePlaybackClient does not exist
android.support.v7.media.RemotePlaybackClient.OnMessageReceivedListener
warning: unknown enum constant Scope.LIBRARY_GROUP
reason: class file for android.support.annotation.RestrictTo$Scope not found
Adding Xamarin.Android.Support.v7.MediaRouter and Xamarin.Android.Support.Media.Compat didn't solve the problem.
For these sort of errors the safest option is to do the following:-
1) Gather a list of all the installed packages with their versions.
2) Remove all packages. Some packages will require removing other packages first.
3) Install all packages again.
check dependencies for both packages.packageandroid.support.v7.media.RemotePlaybackClient,Xamarin.Android.Support.v7.MediaRouter because most of time dependecies should be updated.
go to the nuget package manager and select all the package and push the Update butron in top of the page
Point: There are two update button
A collegue is trying to install a nuget package into a simple default c# web application. It fails almost instantly.
Is there an argument I can provide to Install-Package <some nuget package> in the Visual Studio Package Manager Console to get some verbose information to help debug why the installation fails?
Error Message:
An error occurred while retrieving package metadata for '' from source 'MyGet'.
Info:
Visual Studio: V2015
NuGet extension: 3.4.4.1321
Nuget package source: MyGet
Sample NuGet.config file found in the root directory of the solution:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
<add key="MyGet" value="https://www.myget.org/F/<our package>/api/v2" />
</packageSources>
</configuration>
For myself, I can install the package fine. In fact, we have 5 packages in this MyGet public repo and I just installed 2 of the packages, just then .. when I test this out (again) before I created this SO question.
Anyone have a suggestion, please?
UPDATE
As stated above, this is using the PACKAGE MANAGER CONSOLE, not the CLI.
Using the -verbosity detailed in the PMC this is what happens..
PM> install-package xunit -verbosity detailed
Install-Package : A parameter cannot be found that matches parameter name 'verbosity'.
At line:1 char:23
+ install-package xunit -verbosity detailed
+ ~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Install-Package], ParameterBindingException
+ FullyQualifiedErrorId : NamedParameterNotFound,NuGet.PackageManagement.PowerShellCmdlets.InstallPackageCommand
You could try adding the -Verbose parameter to your PowerShell command.
install-package xunit -verbose
You can also try looking at the $error object to see if that has more information, such as an exception callstack.
$error.Exception.StackTrace
The above may or may not give you more information.
Looks like you are running into http://blog.myget.org/post/2016/02/21/Two-of-my-packages-are-treated-as-one-Help!.aspx. There is a 0.7.0-dev and a 0.7-dev version of the package on the feed, which NuGet treats as the same version.
The solution is to remove one of these two packages.
You can use the -Verbose switch in the PowerShell-enabled Package Manager Console to get more details.
To rule out client-connectivity issues to MyGet, can you try diagnosing client connectivity to the feed?
https://www.myget.org/F/<feedIdentifier>/api/v2
Try using Fiddler to retrieve a specific package from the feed on that user's machine using URL format:
https://www.myget.org/F/<feedIdentifier>/api/v2/package/<packageId>/<packageVersion>
If it is a private feed, you'll need to authenticate your request, e.g. using the pre-authenticated v2 endpoint:
https://www.myget.org/F/<feedId>/auth/<apiKey>/api/v2/package/<packageId>/<packageVersion>
Clearing the NuGet client's HTTP cache may also prove useful if something is corrupt in the cache. You can clear it using the NuGet commandline command:
nuget.exe locals http-cache -clear
If the package is already in local cache, then the NuGet client will resolve it from local cache instead. It may be that the package in local cache is corrupt, in which case you can use the following NuGet commandline command:
nuget.exe locals all -clear
Finally, it may also be worth looking at the nuget.config hierarchy. The most-local nuget.config will inherit config settings from higher up the chain (e.g. machine-wide settings), one of which is the <disabledPackageSources> element. To ensure this one is not acting up here, add the following to your most-local nuget.config and retry:
<disabledPackageSources>
<clear />
</disabledPackageSources>
If none of the above helps you in resolving the issue, feel free to use the nuget commandline (nuget.exe) with -verbosity detailed as it may provide more details, such as the actual HTTP requests being made.
Also, make sure you use the latest versions of the NuGet client tools (available here)
I have a solution which has a two projects. In the both the projects I have packages.config file which has the list of packages that the project uses. Whenever I build the solution I'm getting the below error
The command "*\Tools\nuget install \packages.config -o \Packages" exited with code 3.**
(replaced folder path with **)
I have installed all the packages manually using package manager console. The installation is successful. When I build the solution now i'm getting the below error
The command "*\Tools\nuget install \packages.config -o \Packages" exited with code 1.**
I have cleared the cache of packages. Still I get this error. Not sure why the solution build is trying to install the packages.
You can try adding -verbosity detailed to your command *\Tools\nuget install \packages.config -o \Packages to get detailed error message to help you investigate the cause.
This was happening in a new CI build I set up yesterday. The problem was that NuGet.exe wasn't at the specified path.
"exited with code 3." wasn't an error from NuGet.exe but from MSBuild.
If you were using TFS, be sure to include the location of the Nuget package in the Source Settings of build definition. This error can indicate it cannot access the files.