使用本地 NuGet 服务器时,每当我尝试从该服务器安装单个包时,我得到的只是以下错误:“远程服务器返回错误:(404) 未找到。 "
![在此处输入图像描述](https://i.sstatic.net/ubA78.png)
这些包都在文件系统中,并且 feed 本身可以正确地看到所有包。 我什至可以直接浏览包!
我错过了什么?
我刚刚从 NuGet 服务器 1.4 升级到 1.5,但我以前见过这种情况发生。过去接触包文件会有所帮助,但现在情况似乎并非如此。
编辑:实际上,我之前没有看到过确切的错误...我见过
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."
![enter image description here](https://i.sstatic.net/ubA78.png)
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.
发布评论
评论(7)
在 Windows Server 2008 上,我遇到了同样的问题。我将应用程序池从“ASP.NET v4.0 Classic”切换到“ASP.NET v4.0”。更改后 install-package 命令运行良好。
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.
叹息...
http://blogs.thesitedoctor.co.uk/tim/2011/09/02/Nuget+Server+On+IIS6+Returns+404+When+Downloading+Package+After+Upgrade.aspx< /a>
编辑: 万一链接失效...我在 IIS6 中托管我的 NuGet 服务器,该服务器未设置为正确处理无扩展名 URL。由于下载单个包的语义从直接文件链接更改为无扩展名路径,我开始收到 404 错误。添加文章中描述的通配符映射立即修复了它。
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.
我已经尝试解决这个问题几个小时了...
检查了 IIS 日志,发现 URLScan 阻止了路由:
GET /Rejected-By-UrlScan ~/api/v2/package/
URLScan 不接受任何不以“/”开头的路由。我能做的最好的事情就是从 IIS 管理器中网站的 ISAPI 过滤器列表中删除 URLScan。
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.
我在 Windows Server 2008 上遇到了同样的问题。
问题出在我自己保存的没有版本的包 MyPackage.nupkg 中。
MyPackage 在 PackageManager 中可见,但在安装时出现 404 错误。
使固定:
我将其保存为名称 MyPackage.1.0.0.nupkg(1.0.0 是当前版本),问题得到解决。
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.
我有同样的问题,srv 2008 R2。将应用程序池从经典更改为集成,现在一切正常。
我的问题与上图相同。我可以访问网址
http://localhost:3407/nuget/Packages 上的网站
但不是
http://localhost:3407/api/v2/package/{包名称}/1.0 .0.0
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
我在更新 Nuget 后尝试下载 Signal-R 时遇到此错误,但这只是因为我没有在包管理器设置中选中“允许 Nuget 在构建期间下载丢失的包”选项。一旦设置完毕,一切又恢复正常了。
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.
也可能是这样 -
您尝试引用如下网址: http://yourdomain/application/nuget /packages
那么你应该将其更改为:
http://yourdomain/application/nuget
这是一个常见的错误。
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.