I wonder is there a way to make VS 2019 work with nuget repositories?
Usually it works fine, but sometimes occurs the following.
I pushed a package into my nexus enterprise repository, waited a while (package is already in repo), than opened a .csproj file and entered pushed version. VS cannot load a package with error
Failed to retrieve information about '%packagename' from remote
source
'https://nexus****/repository/nuget-group/FindPackagesById()?id='%packagename'&semVerLevel=2.0.0'.
Of course, if a copy the link to browser, it opens ok. I do have access to both nexus and nuget.org, but VS cannot get any package from them - neither through .csproj nor Nuget Manager UI is VS!
Restart machine doesn't matters. dotnet restore also produces the error.
The only thing helpful is to install VS update through the VS Installer.
Today I already installed an update, so I can't do this now.
Is there any way to make this work?
You could try to use nuget.exe to register the source in your machine.
nuget.exe sources Add -Name "source" -Source {Path to the package(s) source}
Then re-start your visual studio.
I looked at Package Manager Output and saw that sometimes a message appeared. The message was someting like 'cannot connect to host because it reject or already has a connection error at xxx.xxx.xxx.xxx'. (My dirty translate from Russian)
But the point is: this IP is neither nexus host nor any intermediate host. I found that is was our old enterprise proxy (because the new one had no access to nuget.org), which is obsolete and unsupported. So, I just deleted proxy section from %APPDATA%/Roaming/Nuget/Nuget.config and at least local nexus became always available for me.
Related
I have setup my own nuget feed and have hosted that on our dev server.
When I try to push my packages from my local machine to dev machine as below:
dotnet nuget push C:\MyProjects\Common.2.0.0.nupkg -k myapi -s https://mydev.com/AENuget/
I get the error as:
Response status code does not indicate success: 405 (Method Not Allowed).
Now I have read and tried many settings like adding
<remove name="WebDAV" /> <remove name="WebDAVModule" />
Giving permissions to my nuget packages folder, adding app pool account but still I am not able to resolve this issue.
Secondly instead of pushing if I just copy my nuget package file to the package folder being hosted in our dev server and then in visual studio I add the new server source I get the below error:
[Package Source] The V2 feed at 'http://mydev.com/AENuget/Search()?$filter=IsLatestVersion&searchTerm=''&targetFramework=''&includePrerelease=false&$skip=0&$top=26&semVerLevel=2.0.0' returned an unexpected status code '404 Not Found'.
So looks like neither the push from nuget nor the copy is working. Looks like some permission issue which I am not able to resolve.
Would appreciate if someone can provide any inputs to this.
FYI: This works fine if I host this on my local machine.
The problems you are having seem to indicate you are having issues with the NuGet.Server and the system itself. These can be problems with the firewall, hosting configuration (IIS), or a wide variety of problems.
If you are on a very small team, you might just create a shared folder on a network server (with read/write access for the team). You can add the package source to Visual Studio by following this article. The source will be the UNC path to the directory (e.g. \\servername\path\to\nuget\folder).
NuGet.Server is a package provided by Microsoft and NuGet. This is used widely so I do not believe you have a problem with the package. If you encounter a specific problem, we may be able to help.
I want to create a NuGet package from a machine that is on the office intranet, but blocks all connections to the internet.
Both NuGetPackageExplorer.application and NuGet.exe will show the exception that "No connection could be made because the target machine actively refused it".
Installing packages works fine as we have a local network folder with the .nupkg packages we use.
Is there a tool I can use to create a NuGet package on that machine?
Update:
I created a issue on codeplex for this: https://nuget.codeplex.com/workitem/3196
What I ended up doing is downloading the source code from CodePlex, going into the CommandLine project, deleting UpdateCommand.cs, and rebuilding the project. I then grabbing the exe which I renamed NuGetOffline.exe and put it along with NuGet.Core.dll to somewhere in the Path.
Update
The download page for NuGet does not have the current version of NuGet.exe. As of writing this, none of the three downloads on the page work offline and the Other Downloads have several version of Nuget.Tools, but not the current version of NuGet.exe. Go here instead for nuget.exe. Use that instead of that custom build.
The Package Explorer link on the download page is just the ClickOnce installer which does work offline. You need to find the local executable here.
I haven't been able to get "Enable NuGet Package Restore" to work on the intranet. This closed work item describes the problem. The last comment says that "2.0 should no longer run into this issue", but I am using NuGet Package Manager 2.2.400116.9051.
My aim is to have package restore working on a build server so that I don't have to check in binaries. At the moment, I'm simply trying to get it to work on my own machine using Visual Studio.
Here's what I've done so far:
Followed the instructions here http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages, including both setting the Tools-Options flag and the environment variable (belt and braces)
Installed the NuGetEnablePackageRestore package as suggested here NuGet package restore consent without NuGet
Checked everything in (the .nuget solution folder and its contents), but not the binaries I want to reference, because that's the whole point of the exercise
Here's what I'm doing:
Check out solution
Verify that nunit.framework.dll and moq.dll are not present in the checked out solution
Build the solution
Visual Studio complains that Moq is missing. I search for the dlls in the solution directory and find that:
nunit.framework.dll is present in the appropriate bin folders
Moq.dll is nowhere to be found
But there's more. This is truly mysterious, but if I do a fresh checkout, disconnect from the internet and build, I get precisely the same results - nunit.framework.dll is there, but moq.dll is not. The build process has conjured nunit.framework.dll literally from nowhere.
So it's something of an understatement to say that I am completely baffled. Can anyone suggest answers to the following questions:
Why is package restore not downloading Moq?
Where on earth is the build process getting nunit.framework.dll, if not the internet?
In vs, Options, Package Manager... there's a section "Package Cache", if you click on the "Browse" button it will take you to the location of the nuget cache in your machine.
Okay, I noticed in the documentation that enabling package restore was supposed to modify project files in order to add a new target. My project files did not have this change. Right-clicking the solution title in VS and selecting 'Manage NuGet packages...' then added the required changes and everything built as it should.
I checked, and package restore still appears to work when I have no internet access, so I'm still mystified about that. Does NuGet maintain some kind of cache of binaries outside the solution?
Is there a way to load a package from an alternative server when Visual Studio Package Manager (NuGet) is responding with a "The remote server returned an error: (503) Server Unavailable" message?
This is an obscure condition that will likely only occur on an "enterprisy" network environment. If these conditions apply you:
you are required to access the Internet via an HTTP proxy server
the HTTP proxy server requires a valid user ID & password (or AD authentication) to allow requests to proceed
you've been messing with cool developer tools that were ported to Windows from a Linux/Unix environment
the new cool tool(s) work after adding the HTTP_PROXY (or possibly HTTPS_PROXY or both) environment variable(s)
you can access the NuGet servers from a browser without getting a 503 error
Then it's likely you broke NuGet by inadvertently invoking this configuration feature. I'm not sure exactly how the environment variable breaks NuGet but I suspect NuGet is detecting & using the http_proxy URL but sending an empty user ID & password which causes the HTTP proxy to reject the request.
Fix: remove the environment variable(s) you added and see if the cool tool can be configured to use an HTTP proxy without them.
Update: Ran into a version of this issue with the NuGet config file referenced in the "this configuration feature" link above. Open this file:
%appdata%\nuget\nuget.config
in your favorite editor. If it contains elements with http_proxy or https_proxy then removing these elements may fix the issue too.
PS: Hopefully I'll get an up vote from Colonel Panic :-)
If you have used the package in the past it is probably in your cache. You can add the local cache as an available package source by going into the Library Package Manager Settings under the Tools menu in Visual Studio. For Visual Studio 2012, choose Tools, Library Package Manager, Package Manager Settings, and then click on Package Sources.
In the Available package sources section, type a name like "Cache" and then in for the source, browse to %LocalAppData%\NuGet\Cache. You may need to use Windows Explorer to translate %LocalAppData%\NuGet\Cache into the full path (usually C:\Users\YourAccountName\AppData\Local\NuGet\Cache).
Once you have the Cache as an available source, you can now use the Package Manager Console (found under the View menu under Other Windows or also under the Tools menu under Library Package Manager).
From the Console (which is a PowerShell window with commandlets for NuGet) you can type "get-help NuGet" to see available commands.
Then using Get-Package, you can get a list of Package ID's. Make sure the "Package source" is set to "Cache" (or whatever you called it) and the Default project is set to the project you need manipulate, both of these are dropdowns located at the top of the Page Manager Console. You can also use the Get-Project to verify you are working against the correct project in your solution.
Finally, you can type Install-Package and when prompted enter the Package ID from the output of the Get-Package commandlet.
i had also this problem, it was becouse of my network.
if you have any blocking on your Internet, (like in companies internet or etc..)
you may not allowed to download the nuget package.
try to download the package in another network, maybe it can help you!
Talbott's answer did not work for me, as my cache was empty. However, if you have used the package in another solution, you can copy the items you want from the "packages" folder in the other solution to a packages folder in your target solution.
If you have no packages installed in the target solution, you may need to add the following to a repositories.xml file in the packages folder:
<?xml version="1.0" encoding="utf-8"?>
<repositories>
</repositories>
After doing that, the packages appeared to be installed in my solution and I was able to add them to projects.
Additional Note: I had to use the "Manage NuGet Packages for Solution" option at the solution level to add the package to individual projects. Using Install-Package from the console still returns a 503 even though the packages is already installed in the solution.
You can also get this error if you are using a VPN client (e.g. Cisco AnyConnect) and you have recently renewed your VPN certificate. The issue can occur after you have updated your certificate, but before you have rebooted. A reboot resolves the issue.
It is a pretty old question, but I have just encountered the same problem. In my case it occurred because I had more than one nuget package source configured in the Visual Studio Package Manager. In my company we use NuGet to get mainstream packages and MyGet for our own stuff.
When I attempted to pull a pretty big package it failed with a 503 code and the error link looked pretty odd, it had MyGet in it istead of NuGet. Turns out Visual Studio package manager tried to pull it from another source despite having NuGet chosen as a current source. Disabling other sources and then proceeding with a download fixed it.
Hopefully it will help somebody who stumbled upon this thread just like I did.
Another possible reason for recieving 503: If you're using Azure DevOps feed, then NuGet packages are limited to 500 MB.
When using a local NuGet server, whenever I try to install an individual package from that server, all I get is this error: "The remote server returned an error: (404) Not Found."
The packages are all there in the filesystem and the feed itself sees all the packages appropriately. I can even browse the package directly!
What am I missing?
I did just upgrade from NuGet server 1.4 to 1.5, but I've seen this happen before. Touching the package files used to help, but that does not appear to be the case now.
EDIT: Actually, I hadn't seen that exact error before...I've seen this one, intermittently, that touching the package tended to fix.
On Windows Server 2008, I was having the same issue. I switched the Application Pool from "ASP.NET v4.0 Classic" to "ASP.NET v4.0". The install-package command worked fine after the change.
sigh...
http://blogs.thesitedoctor.co.uk/tim/2011/09/02/Nuget+Server+On+IIS6+Returns+404+When+Downloading+Package+After+Upgrade.aspx
EDIT: In case the link ever dies...I am hosting my NuGet server in IIS6, which wasn't set up to properly handle extensionless URLs. And since the semantics of downloading individual packages changed from a direct file link to an extensionless route, I started getting 404s. Adding the wildcard mapping described in the article fixed it instantly.
I've been trying to figure this for a couple of hours...
Checked the IIS logs and discovered that URLScan was blocking the route:
GET /Rejected-By-UrlScan ~/api/v2/package/
URLScan doesn't accept any route not starting with '/'. The best I could do was to remove the URLScan from the list of ISAPI filters for the website in the IIS Manager.
I was having the same issue on Windows Server 2008.
Problem was in my own package MyPackage.nupkg that I saved without version.
MyPackage was visible in PackageManager but it was getting 404 error on install.
Fix:
I saved it with name MyPackage.1.0.0.nupkg (1.0.0 is current version) and problem was fixed.
I had the same problem, srv 2008 R2. Changed the application pool to Integrated from Classic and all works fine now.
My problem was same as image above. I could go to the site on url
http://localhost:3407/nuget/Packages
but not
http://localhost:3407/api/v2/package/{package name}/1.0.0.0
I encountered this error while trying to download Signal-R after update Nuget, however it was just that I had not checked the "Allow Nuget to download missing packages during build" option in package manager settings. Once that was that set it all worked fine again.
It could be this as well -
You are trying to refer to a url like : http://yourdomain/application/nuget/packages
Then you should change it to :
http://yourdomain/application/nuget
This is a common mistake.