Ok, thanks. I understand what you're saying now.

Hi Dean - apologies, other priorities came up and I lost track of this. I see your point regarding those extensions. I would be interested in getting our custom extension running if possible, so yes if you can contact me directly that would be great

These are available on the All Versions page: https://inedo.com/proget/versions

Could this be related to Quirks mode? https://inedo.com/support/documentation/proget/feeds/nuget#legacy

I'm not sure if I totally understand the question, but packages are designed to be immutable, and as such you really can't "update" them. You can delete or overwrite a package if you have permissions, but it's inadvisable and you should not make this part of your workflow. In addition to being against the fundamental package workflow/design guidelines, packages are cached by clients like Visual Studio, and won't see a "new version" of a "version" of a package.

There are no changes in ProGet that would cause this. Most likely the package file is invalid, something is cached, you're using the wrong URL, etc. If you can provide a very specific reproduction case using a new (empty) feed, and a specific set of packages that, when uploaded in a specific order, cause this behavior, we can investigate it further.

Ok, recursive search enabled, it still doesn't assign the rights based on my group membership. I'll create a ticket with a few screenshots, I'd rather not post names of our internal groups on the wider internet :)

So between running the 'ProGetInstaller.exe' after deleting keys and directories... didn't realize the unpack directory gets recreated each time. So once I knew I deleted the 'unpack' directory... I never checked again for it. Now that I removed that directory and ran 'ProGetInstaller.exe'... looks like I can now install the application. Yes something simple and stupid. Thank you all for you help!

Please refer to KB#1090 for how to grant service control permissions and avoid this service control error. If you're getting a 404, then you're not using the proper API Endpoint URL. I'm guessing, you're using whatever URL in your browser? Please refer to this tutorial for how to configure this in Visual Studio.

You need to create an API in the ProGet UI; API Access and API keys

Your server is configured to disable the use of .NET's MD5 processing libraries, which means ProGet cannot read or write Maven index files. You can disable this at the server level: https://www.schneider-electric.com/en/faqs/FA282064/ You can also edit the configuration file; https://docs.microsoft.com/en-us/dotnet/framework/configure-apps/file-schema/runtime/enforcefipspolicy-element

This is a property of the service. Just go to "Services" on your computer, edit the service, and change the Auto-recorvery options.

Hi Alana, Thanks so much for the update and the workaround solution. I'll be sure to upvote the linked issue. Best, Michael

This was a result of a imcompatable script with 2005, but it has been fixed as of 5.1.11. We are also displaying warning if you're using unsupported version of SQL

You can reset the Admin user account password by stopping the ProGet Windows service, then running ProGet.Service.exe and selecting the "ResetAdminPassword" option. Make sure to restart the Windows service when finished.

This seems to be related to a specific package that you have in your repository. Most likely it's bad/invalid metadata, and the specifics were not anticipated and thus it's crashing trying to read it. Unfortunately we would need to know a bit more about that package, and why it's causing this problem.

Hello George, thanks for your quickly answer. Well, I tried to change the proget configuration ports on docker from 6580:80 to 80:80 and the problems have resolved. I Understand that although proget resolve correctly the url request http://proget.local:6580 and redirect the answer to 80 port when i tried to download a package with choco pack -source http://proget.local (previusly correctly uploaded on proget trought the portal) this query always bound to 80 ports and because of this it´s not possible to find the package and download it. I reinforced these arguments when later saw in the dockerfile details that mount the proget image te next string: (/bin/sh -c ([ -f /usr/share/Inedo/SharedConfig/ProGet.config ] || echo '<?xml version="1.0" encoding="utf-8"?><InedoAppConfig>ConnectionString>'"$PROGET_DATABASE"'</ConnectionString><WebServer Enabled="true" Urls="http://*:80/"/></InedoAppConfig>' > /usr/share/Inedo/SharedConfig/ProGet.config) && mono/usr/local/proget/db/bmdbupdate.exe Update /Conn="$PROGET_DATABASE" /Init=yes && exec mono /usr/local/proget/service/ProGet.Service.exe run --mode=both) I hopesfuly to correctly understanded that the issue was here. In any case now I have two current proget running. One on docker on 80/80 ports and other on windows. Thanks for your help.

Hi Alana, Yeah but that seems to be a bit to much. It removes some settings like the connection string. And requires you to have made a backup with each upgrade (it seems I don't have backups since switching to Inedo Hub).

Hello Jeremy, It seems that the Maven feed code in ProGet is incorrectly identifying all prerelease Maven package versions as snapshot versions. I've filed this as PG-1380.

Hi, thanks for your reply. Fortunately, this particular feed contained low amount of packages, so i've just backuped them for ProGet ProgramData folder, deleted this feed via Proget UI, recreated feed and uploaded packages back, and now it works. I agree with you and suppose that there were some MSSQL issue, but decided to solve this issue using easiest and fast way for me.