We have a private nuget repository for sharing internal components. For now, we are just using a network share.
I am running into some problems though:
Everything works fine if I use the Package Manager Dialog box -- I can search for my packages, install them, and build.
However, if I use the Package Manager Console command: install-package My.Package (where My.Package is the exact string in the <id> tag of the nuspec file, I get an error indicating the nuget could not find the package.
If I include the version number in install-package: install-package My.Package.1.0.0, then it works from the console.
BUT, our build server fails to download our packages with the same error I get from install-package. (our build server uses package restore)
I have compared my nuspec files with some publicly available packages that work find. The only difference I can find is that our nuget packages are on a network share, but public ones are on a web server.
Is there a behavior difference if you use a network share?
I figured out what the problem was -- it was mostly user error.
I went through my nuget config, and I found this:
<activePackageSource>
<add key="nuget.org" value="https://www.nuget.org/api/v2/" />
</activePackageSource>
That setting tells nuget to only search nuget.org, and not our private feed. Had to change it to this:
<activePackageSource>
<add key="All" value="(Aggregate source)" />
</activePackageSource>
I'm still not sure why it worked before (sometimes) if you included the version number (maybe it had to do with whether the package was already locally cached?? It seems as though it should not have worked at all until I made this change. This fixed it though.
Related
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.
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
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 am trying to change ServiceStack in my service from 3.9.43 to 4.0.9.
I had to change several things in my code and mostly followed the release notes for this.
There were a couple of weird things for me, like not finding anything to replace ServiceStack.WebHost.Endpoints or AppHostHttpListenerLongRunningBase but I could check those things after and was able to make my code to compile.
The problem is that when I run my code I get this exception in the very begining and it just kills the service:
Method 'ExecuteMessage' in type 'ServiceStack.Host.ServiceController' from assembly 'ServiceStack, Version=4.0.9.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.
I get this when hitting the base:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using ServiceStack;
using ServiceStack.Text;
//using ServiceStack.WebHost.Endpoints;
using ServiceStack.Web;
namespace ThisService {
public class AppHost : AppHostHttpListenerPoolBase { //AppHostHttpListenerLongRunningBase {
public AppHost(int wthreadMax)
: base("This Service " + VcsInfo.ChangesetId, wthreadMax, typeof(ThisService).Assembly) {
}
...
I am referencing in my project:
ServiceStack (4.0.9.0);
ServiceStack.Client;
ServiceStack.Common;
ServiceStack.Interfaces;
ServiceStack.Text
I am sure I am doing something wrong changing to version 4.* and am lost with what is trying to call the Execute Message since I think removed everything from the previous version. Any suggestion to where I should be looking to?
By the way, this a simple service: get json -> math + stuff -> return json.
I want to find out if a bug I found the version 3.9.43 still happens in version 4.0.9 (can't find anything specific about that bug but I believe one fix there is related) to see if I should actually re-factor my code for this version.
Update in v4.10
This should now be resolved in ServiceStack v4.10 where now all NuGet packages specify a minimum version for all dependencies matching the current version. This will force NuGet to pull down the latest packages instead of the oldest matching ones.
NuGet seems to have the weird behavior that it will pull in the lowest dependencies when you install a package, so if you install the latest version of ServiceStack, e.g:
PM> Install-Package ServiceStack -Version 4.0.9
It will pull in the lowest matching dependenices, e.g:
<package id="ServiceStack.Client" version="4.0.3" targetFramework="net45" />
<package id="ServiceStack.Common" version="4.0.3" targetFramework="net45" />
<package id="ServiceStack.Interfaces" version="4.0.3" targetFramework="net45" />
<package id="ServiceStack.Text" version="4.0.3" targetFramework="net45" />
Which is an unexpected surprise. Unfortunately ServiceStack assumes that it's always working with the latest dependencies with the same version it was built with.
So after installing ServiceStack you will need to update all your packages which will bring them in-line with the latest versions, which you can easily do in the Updates tab in the NuGet UI, or in the NuGet Package Console Manager with:
PM> Update-Package
Manually remove any assembly redirects
Installing the previous v4.02 of ServiceStack (now removed) created new assembly redirects for ServiceStack.Interfaces in the Web.config which you should also manually remove if they exist. These now shouldn't be created for new projects.
I had the same problem as well. Therefore I tried installing an older v4 version from Nuget and managed to make it work.
Using Scott's example I can get this to work correctly if I install 4.0.4:
install-package servicestack -Version 4.0.4
If I use version 4.0.5 then it runs but the example web page reports
Method not found: 'Void ServiceStack.Web.IResponse.set_Dto(System.Object)
If I use version 4.0.6 or above then I get the error reported by RGPT.
So, for now it may be a case of using the 4.0.4 version until someone with more knowledge than me replies with a better answer. I've only just starting using ServiceStack today so I don't know much yet ;)
Update: I don't have high enough ServiceStack reputation to post a comment so felt best to edit my original post. The answer below by mythz had the key bit of information. Immediately update your nuget packages after installing and then check the web/config / app.config to see if any dependentAssembly bindingRedirects are hanging around - if so then remove them and away you go :)
I've had a similar problem as well. I followed the upgrade path, first via the Beta channel before upgrading to the offical channel. What I soon realised was that the Beta libraries had version numbers greater than the official channel.
NuGet will check for a more up-to-date version locally first, before pulling in the libraries remotely. Of course, it will pull in ServiceStack v4.0.x from the official channel, but all the dependencies will come from the already downloaded Beta (i.e. locally).
What I did to resolve it:
Uninstall all ServiceStack dependencies from the Solution via NuGet
Deleted the Solution's Nuget '/packages' folder, and to re-import it using NuGet package restore
Re-added the ServiceStack references via NuGet, and checked the 'packages.config' for correct versions
I have installed dotless via Package Manager in VS2012 in to an existing mixed C# solution (Class libraries and MVC2 apps), however now when I build it (F5) I get the following two errors:
The command ""C:\#GitRepos\EBS\SolutionFiles\.nuget\nuget.exe" install
"C:\#GitRepos\EBS\\packages.config" -source "" -o
"C:\#GitRepos\EBS\SolutionFiles\packages"" exited with code -1.
and
The system cannot find the path specified.
After adding dotless to the solution a ".nuget" folder with "NuGet.exe and "NuGet.targets" has been added.
I have also tried adding dotless to a new MVC2 project and other than having to add a mime type to the web.config it all works well. There isn't however a ".nuget" folder.
I also noticed that the same happens if I create a new NServiceBus solution (after installing it). The paths in the message change but the error is the same.
If I take
"C:\#GitRepos\EBS\SolutionFiles\.nuget\nuget.exe" install
"C:\#GitRepos\EBS\\packages.config" -source "" -o
"C:\#GitRepos\EBS\SolutionFiles\packages"
and run it via a command prompt then I get:
All packages listed in packages.config are already installed.
So after giving up on this and then a few days later looking in to it again, I found the answer. I came across david-martos.blogspot.co.uk. After opening my command prompt and finding it also said "The system cannot find the path specified" I went looking in the registry. I found in "HKEY_CURRENT_USER\Software\Microsoft\Command Processor" that there was an AutoRun key for "c:\ansi140\x64\ansicon.exe -p ". After deleting this and trying one of my NserviceBus solutions again I found it built fine. I hope this helps others.
Here is a direct link to David Martos post.
This was also likely a nuget package restore consent that you had to set. http://blog.nuget.org/20120518/package-restore-and-consent.html
For anyone who wants to permanently have the consent accepted, take a look at installing http://nuget.org/packages/NuGetEnablePackageRestore - it will be accepted on all machines automatically.
I solved this problem by opening up the Package Manager Console and clicking on the "Restore" button on the warning that popped up. Here's a pick of what it looked like. This is similar to the other solutions, but from a different angle.
Just execute the command below from NuGet Package Manager Console. It worked for me:
PM> Install-Package NuGetEnablePackageRestore
I had the same error:
"The command "" exited with code -1." and "The system cannot find the path specified."
I tested all the possible solutions I found and nothing worked, at the end what I did was take the NuGet.exe from another project and replace it in the project inside the .nuget folder that was generating the error and is working now.
For me, I had accidentally deleted the NuGet.Config file from the root of my project directory. Fortunately, I could restore it with source control.
Here's the content of my file if anyone have done the same mistake as me and doesn't have a backup:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="repositorypath" value="NuGet Packages" />
<add key="globalPackagesFolder" value="NuGet Packages" />
</config>
<packageRestore>
<add key="enabled" value="True" />
</packageRestore>
</configuration>