Hi @paul_6112 - The screenshot shows Inedo Hub v1.3.6. Was all of the testing done on this version? We did finally get a fix for this in Inedo Hub v1.3.7 (see DH-63), but did not confirm 100% that this was the underlying issue as we were not able to reliably reproduce it.

Thanks for passing along this test data!

-Greg

Hi @jcardos_9259

We now have this fixed in ProGet 6.0.2, which is scheduled for release on Friday. If you'd like to try the fix right now, you can install the inedo/proget:6.0.2-ci.3 Docker image.

Thank you!

Hi @shiv03_9800,

We've now fixed this issue as well. It is logged as OT-439, and will be included in the v3.0.14 release. If you would like to try the fix right now, you can use the inedo/otter:3.0.14-ci.1 Docker image.

Thanks,
-Greg

Hi Igor,

Thanks for the help in tracking this down. We've now fixed this in an internal build (logged as OT-428) . The fix will be in Otter v3.0.12, scheduled for release on October 8.

If you'd like to test a prerelease build, you can pull the proget.inedo.com/productimages/inedo/otter:3.0.12-ci.1 image, which already contains the fix.

-Greg

Hi Nico,

You're doing nothing wrong as far as I can tell.

I can't reproduce the issue where the wrong latest version is shown for an uncached package. Does it only happen for that one package? How many versions of it are on the external feed?

Regarding the other issue - that cached packages in the browse list may show the incorrect latest version - there is not much we can do about that. The browse list both in ProGet web interface and in the VS NuGet dialog sort by popularity and so frequently return totally different packages. The only way we could guarantee an accurate "latest version" display for cached packages on there would be to individually query those packages from the connector, which would drastically slow down the results. That said, I agree this isn't great. I'll chat with the rest of the team and see if we can come up with a better way to handle this.

-Greg

Hi Dennis,

Thanks for the feedback! You should be able to delete files/folders using the Asset Directory Delete API. Using curl, it should look something like this:

curl -X POST http://proget/endpoints/<AssetDirName>/delete/<path to directory>

We are actually focusing on Asset Directory improvements for the upcoming ProGet v6.0 release, so if you see any gaps or problems be sure to let us know!

-Greg

I've merged this pull request and published v1.0.2 with the change. Thanks for the fix!

I'm glad you got it working! I had forgotten that flag was even added :/

I'll chat with the docs team to get things clarified in there, or maybe see if we can change the default to enable v3 by default from now on.

Thanks!
-Greg

Hi,

Try using the NuGet v3 API for your feed instead- just use https://proget.eschbach.com/nuget/nuget-internal/v3/index.json as the package source URL in NuGet. NuGet's handling of semantic versions in the old API can be inconsistent, so this may resolve the issue.

Looks like that was our mistake, and we missed that line in the spec. This has now been logged as PG-1964, and it will be fixed in ProGet 5.3.30, scheduled for release on May 28.

Thanks for pointing it out, and sorry for the inconvenience!

Hi,

It looks like that file isn't a valid debian package file. According to the .deb file specifications, a file named debian-binary should be the first item, but instead, there's one named debian-binary/. You can see this by opening the file with a text editor:

Do you know what was used to generate the package?

We've got a fix for this as OT-415. It will be included in Otter v3.0.6. If you'd like, I can publish a prerelease version for you. Thank you!

@brett-polivka So one more update. Implementing the workaround was easier than expected. This should now be resolved in v1.11.1 of the Azure extension, which you install from the Admin->Extensions page. You may need to restart the Docker container after installing.

@brett-polivka It looks like the underlying problem is likely that 100MB limit. When we published the Azure extension, we'd mistakenly believed the maximum block size to be 4000 MB, but because we're using the v11 client library to push to azure, it's limited to the older 100mb limit. We can't upgrade without dropping support for .NET 452 on windows, which we aren't prepared to do yet, so we'll work around using another means.

We're on it; hopefully will have an update included for tomorrow's release.

That's strange. We'll do some experimentation with trying to perform that upgrade in a test environment and let you know what we discover.

Hi,

Could you click the "Submit Error Report" button when this happens? If you'd prefer to look at the file that gets set to us first, you can use "Save Error Report" instead. The error report is a zip file that should have more information than this empty log in it.

Thanks!

This is unfortunately a documentation issue. We changed some of the environment variable names for ProGet 5.3 - so you'll need to use:

-e PROGET_DATABASE="Data Source=proget-sql; Initial Catalog=ProGet; User ID=sa;Password=<Secret>" \
-e PROGET_DB_TYPE=SqlServer

instead of -e SQL_CONNECTION_STRING=...

We'll update the docs to note this for ProGet 5.2.

Just following up- all of these issues should be resolved in ProGet 5.3.13, which will be released later today.

Thanks-

I've seen that anti-CSRF error appear if you try to perform certain tasks while not logged in- we're still investigating the cause.

Hi,

The lowercase file errors should be fixed in ProGet 5.3.13. So far we have not been able to reproduce authentication or activation issues, but we'll be adding additional logging in 5.3.13 to diagnose these issues.

Thank you!