6
Vote

GalleryDetailsUrl is incorrect when publishing to feed

description

If you look at the OData feed for RouteMagic 0.1.0, you can see:

<d:GalleryDetailsUrl>http://localhost:777/Packages/Packages/Details/RouteMagic-0-1-0 But in RouteMagic 0.2.2 it becomes:

<d:GalleryDetailsUrl>http://localhost:777/Packages//Details/RouteMagic-0-2-2 Note that the difference is I used the website for the first version, but the NuGet.exe command line for the second one.

comments

kevink wrote Apr 14, 2011 at 6:25 PM

Just following up on the open issues - this is kind of old now but do you know if you're still seeing an issue with this? The GalleryDetailsUrl in the feed should not be different based on how the package was pushed. That field is not stored on a per package basis - it's generated dynamically based on a template in the AppSettings file.

davidebbo wrote Apr 18, 2011 at 10:32 PM

Yes, this is still an issue. e.g. go to http://packages.nuget.org/v1/FeedService.svc/Packages()?$filter=substringof('webactivator',Id) and look at the GalleryDetailsUrl. It's http://nuget.org/List//WebActivator/1.0.0.0

aldion wrote Apr 19, 2011 at 10:11 PM

I'm hitting this issue for some "Rate It" links in VS (Feature #930) (ex. FaceBookLinkMVC)

kevink wrote Apr 20, 2011 at 1:01 PM

David, I know why the GalleryDetailsUrl is incorrect - all of those packages have a null value for PackageType. What I don't know is how that happened in the first place. Any package that gets pushed should end up with a PackageType value of 'Package'. Can you query the NuGet database and find out how many packages have null for that field?

davidebbo wrote Apr 20, 2011 at 5:39 PM

There are 997 packages with a NULL Package type, so almost half. Could it be that it affects the packages submitted via nuget.exe without going through the gallery?

kevink wrote Apr 20, 2011 at 8:11 PM

Okay, then that's a problem. I suspect you're right - packages pushed via nuget.exe vs. uploaded through the gallery are probably ending up with a NULL package type. Thinking about it now, I believe I know how this was overlooked. The package type value didn't use to matter on the server side. When a new package syncs over to the Orchard side, we automatically select the package type value if there is only one term defined in the taxonomy, which is the case for NuGet. So on the front-end everything has a value.

At some point we added that GalleryDetailsUrl property to the feed - I think it was right before v1 was released. That was the first time that the value mattered for the feed, but we never considered the fact that packages pushed from nuget.exe won't have that value. I think this is something we'll need to add to GalleryServer. In the meantime, I can think of one workaround that should work for NuGet. Since you only have one type you could make 'Package' the default value in the database to handle new submissions, then just update all the existing null values.

davidebbo wrote Apr 20, 2011 at 8:48 PM

Ok, we'll look into that, thanks Kevin.

davidebbo wrote Jun 2, 2011 at 5:56 PM

I just did Kevin's suggest fix up in the DB. However, we still need to fix the code so that new instances of the DB get the proper schema, but that is now less urgent.

davidebbo wrote Jul 12, 2011 at 11:30 PM

For the record, the query I ran was: UPDATE PublishedPackage SET PackageType = 'Packages' WHERE PackageType IS NULL

Sign in to add a comment or to set email notifications