Nuget Package Manager lists no packages under 'Online' tab because Proget throws error

Guest

Strange, we are not able to reproduce this on any version of 3.4. Does it still happen if you try the query against a new feed with no packages in it?

Guest

Yes, I just tested by creating a new Nuget field (with all settings defaulted) and pointing the VS Nuget Package Manager to it. The logs show the same error as reported above.

Guest

How about if you go to that URL directly with a browser? I can't imagine why that would be different, but it may be worth a try.

Guest

Yeah, no difference. It just shows me an error page with the same error.

Guest

What version of SQL Server are you using?

Guest

We are using Sql Server 2008 and the database is on a different box than the Proget server.

Guest

You may want to try upgrading to 3.5.2 - it's possible this is due to an incompatibility with SQL server that we've fixed.

Guest

We upgraded to 3.5.3 but are seeing the same issue.
Over the last few days, we've tried installing different versions of Proget (from 3.3.7 onwards), as well as pointing them to a local SqlExpress instance, but nothing has worked. We get the same error everywhere.

However, we have narrowed down the issue to the $count parameter in the url.

If we run the original Search query with the $count parameter:
http://[ProGetServer]/nuget/Default/Search()/$count?$filter=IsLatestVersion&searchTerm=''&targetFramework='net40|net40|net40'&includePrerelease=false
we get the exception mentioned in the original post.

If we remove $count from that query
http://[ProGetServer]/nuget/Default/Search()?$filter=IsLatestVersion&searchTerm=''&targetFramework='net40|net40|net40'&includePrerelease=false
The query works fine and returns a list of packages.

Similarly, if we hit the server with a request for packages:
http://[ProGetServer]/nuget/Default/packages
the query runs fine and returns a list of all the packages

But if we modify it to include the $count parameter
http://[ProGetServer]/nuget/Default/packages/$count
We get the exact same exception mentioned in the first post.

So, it seems the issue is caused by a bug in the logic that returns package counts. The exception message 'Nullable object must have a value' is thrown in .net code that invokes the .Value property of a Nullable variable that is set to null.
Would it be possible for you to review that logic and see if this property is being invoked incorrectly anywhere?

Guest

Researching this issue further, we believe the cause is bad/unexpected data being returned from NuGet.org.

Can you try disabling/deleting the connector to verify? It may also be the connector filters you are using.

Guest

We've already removed the nuget.org connector, but that didn't make a difference. We have no filters or adapters configured either.

The settings for our Default package feed are:

Feed URL: /nuget/Default
Feed Disk Path: [Network share]
Bulk Import Drop Path: [Network share]
Cache Packages: NotApplicable
Active: Success
Type: NuGet

The feed is Active, and the 'Enable symbol and source server for this feed' option is enabled.

Guest

We just upgraded to v3.5.4 from v3.5.3 and the issue is now fixed.

Guest

We are still having this problem on v3.5.4. Given the following URL in a browser: http://myserver/nuget/Testing/Search()/$count?$filter=IsLatestVersion.

I tried it with a brand new feed (after removing the nuget.org connector).

It will always throw the InvalidOperationException error message:

System.InvalidOperationException: Nullable object must have a value. 
at System.Nullable`1.get_Value() 
at Inedo.ProGet.WebApplication.SimpleHandlers.NuGet.ODataHandler.ProcessVirtualRequest(ODataResponseContext context) 
at Inedo.ProGet.WebApplication.SimpleHandlers.NuGet.ODataHandler.ProcessRequest(HttpContext context) 
at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Guest

@Garo - What happens if (after you've deleted all connectors), you go to Admin > Advanced Settings > click Save without changing anything to restart the web application? Does it work then?

Guest

No change. Still get the error message. However, the error message only shows up for non-default feeds. My "Default" feed (also no connector) will process the query just fine. When I create a new feed is when there is a problem and it errors out.

Guest

I can confirm that we are seeing the same issue as Garo with 3.5.4. The Default feed works fine, the new feeds don't. The issue is still related to the $count logic. Remove that from the url and things work fine.

Luckily, we currently only use/need the Default feed at work, so this issue is no longer blocking us.

Guest

Upon further troubleshooting, I determined that if I turn off "Symbol and Source Server" on the extra feed (with no connectors), it will work with the clean empty feed that I had created. However, I have another feed that pulls from my TeamCity v8.1 server (using the v1 api) and it generates the same error, even when I turn off the "Symbol and Source Server" and caching and clear the cache. I also tried triggering a restart of the web application by saving the Advanced Settings, but no luck. Still getting the same error.

Guest

I've found a connector caching issue that could be to blame for this. Could you try restarting the web application after deleting the connector? You can do this pretty easily by going to the Admin->All Settings page and clicking Save.

Guest

It's definitely a connector issue. If I remove the connector and reload the web app, it works. If I bring the connector back in, it fails. So any connector it seems added to a non-Default feed doesn't allow a count request.

Guest

Upgrading to ProGet 3.5.5 does not resolve the issue. It works if there is no connector associated with the non-Default feed, but once I add a connector, the query fails again.

Guest

I have confirmed that this is still a problem in ProGet 3.5.6, even after rejiggering the web application and removing / readding the connector to the feed. Any ideas on when this could be fixed?