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.

Behind the scenes, that's the only difference in how they're stored (and has been for as long as I remember); but I do know that data directly in the database is not officially supported. But for a one-off thing it's fine to do IMO

Did you reset to the Built-In authentification options ? If so you can use the default Admin account with the Admin password. You can also browse the database, find the account value and add your user directly in the table.

Soon --- this is a known issue, but we are in the process of resolving it; please see InedoCore#96

Hello Antoine and Anton, I've filed this as PG-1376.

Hello Florian and Antoine, I've filed this as PG-1376.

The problem was our proxy. npm doesn't use the proxy exceptions that are configured in the system, so after updating them to include the ProGet server domain it works as expected.

Yes, that would fix the installer issue and we do recommend moving to SQL Server 2016. The bundled SQL 2005 instance in the old installer was intended more for quick setup for evaluation purposes rather than production use, but we did a very poor job of making that clear. We are fixing that now; we're working on updating all of our installers to detect the SQL Server version and suggest/require an upgrade. Here is the current article about SQL Server requirements - basically it's any version currently supported by Microsoft. Sorry for the confusion, and hope this helps!