NuGet Connector not passing searches through to Nexus NuGet feed.

Guest

FYI -- for NuGet feeds, a "Healthy" connector means that the service was able to connect to the feed and query the total number of packages at the source. Other connectors (npm, maven), the entire index is downloaded, so "healthy" means there is an offline index. Unfortunately NuGet does not support an index download.

I have heard a few other reports of behavior like this from when connecting to a Nexus3 repository, but I never heard back regarding a resolution. I do know, for example, that connecting to a TeamCity feed can sometimes be problematic because it doesn't always support API v2. But upgrading to TC v9 and enabling the proper API is a resolution there.

Generally speaking, there are three possibilities:

ProGet is being blocked from making a request to the remote repository, by a firewall or some such; this should be logged
The remote repository is not returning the results; e.g. package not found, when it should be
ProGet is not interpreting the resulst correctly; e.g. package is in the results, but it's not shown to the user

Requests to connectors are not logged; there are simply too many and too much data. But, it's easy to capture them by attaching a proxy server, like Fiddler, between ProGet server and the remote repository. To do this, install Fiddler on the server, then configure ProGet's proxy settings (under Admin) to point to Fiddler. Soon enough, you should see the web requests that ProGet is making.

Once that's configured, you can now identify which scenario it is from above, and in the case of #3, we can certainly try to identify why that's happening.In the case of #1 or #2, it's difficult because it's probably a third-party feed, but we can try to help!

Guest

Alana,

It seems that the problem is #2 mostly, but there's another thing I noticed.

In all of these cases I'm simply using the 'Add Package' button under the Feed page to try and grab a package on the connector.

I search for the latest version of a package I know exists on the Nexus Repository. The outgoing headers are as follows -

GET http://artifacts.apprenda.local:8081/repository/nuget-group-dev/FindPackagesById()/?$filter=IsLatestVersion&id=%27Apprenda.API.Application%27 HTTP/1.1 Host: artifacts.apprenda.local:8081 Accept-Encoding: gzip

The response I receive from Nexus is a 404.

When I compare this with the call that the NuGet client makes, it appears that the difference is that ProGet is appending a / character between the call to FindPackagesById() and ?filter, whereas NuGet does not.

Guest

So just to confirm, Nexus returns the expected results when you omit the / from the URL, but gives a 404 when it is there?

We can change this easily enough. Actually, we only started appending a / to the end of these URLs because NuGet.org used to fail without them...

Guest

Dean -
Yeah, that's what we're seeing. For what it's worth, nuget v3 doesn't seem to suffer from this (but it has different routes). Interestingly enough, when I force my nuget client to install from the v2 route it works without the trailing /. Try nuget install Newtonsoft.Json -Source https://www.nuget.org/api/v2/, you should see something like:

GET https://www.nuget.org/api/v2/FindPackagesById()?id='Newtonsoft.Json'
OK https://www.nuget.org/api/v2/FindPackagesById()?id='Newtonsoft.Json' 94ms

Guest

Hi Austin,

So I've researched this a bit further. Here's our concern...

There's no sensible way to make this configurable; no one will really know what the option means, and it'd be some random configuration item on a connector.
Both with and without the "/" are apparently correct, but we definitely know some versions of NuGet only work with the "/"
We're concerned other repositories will require a "/", so while it will fix Nexus, it may break others that we don't know about
One possibility, we can retry with a "/" if there is a 404. But that could cause performance issues

Is it possible for Nexus to change this?

Alternatively, can you export all your packages, and then put them in a drop folder for ProGet to pick up and import?

Guest

Exporting the packages isn't the problem - our real issue is that we'd like to be able to do a gradual cutover to ProGet over a few days where our CI system continues to build out packages to the old artifact server, but devs can point VS to ProGet and packages that aren't found will be searched on the connector and cached.

It's not a showstopper, it's just an annoyance. I'll see if there's anything on the Nexus side that can be done.

Guest

Some more research for y'all...

Nexus doesn't seem to have a record of this issue, and they're usually slow as christmas anyway about fixing stuff, so I don't have much hope it'll get resolved on their side.
I decided to reverse proxy the Nexus server and then rewrite URLs as necessary to try and solve the problem. This works well for simply downloading packages and installing them onto the ProGet feed. However...
When attempting to nuget install a package only available on the connector, things go bad again. ProGet attempts to fetch /repository/nuget-group-dev/Packages(Id='Package.Id',Version='1.0.0')/ which isn't valid, although /repository/nuget-group-dev/Packages()?Id='Package.Id',Version='1.0.0' totally is.

Guest

Hmm, it's strange.

Actually, /repository/nuget-group-dev/Packages(Id='Package.Id',Version='1.0.0')/ is correct, according to the ODATA specification...

Are you saying, NuGet is requesting /repository/nuget-group-dev/Packages()?Id='Package.Id',Version='1.0.0' from ProGet?

Guest

Alana,

I just now figured out what's going on here. ProGet is sending the right request, but the Nexus NuGet feed doesn't understand it without the single quotation marks being urlencoded. So, /repository/nuget-group-dev/Packages(Id=%27Package.Id%27,Version=%271.0.0%27) works.

Disregard the other part of that message, I was actually getting the entire package list back from Nexus.

Guest

Alana- looks like this one is actually on me, the reverse proxy was stopping the single quotes. But, the extra trailing slash is what causes the issue with Packages(), same as it does with the earlier problem.

I have it sorted out now.