You can just back-up the database, and then restore it in the new SQL Server.

Hello Tom, You are correct that this is caused by the npm feed type not being found. I've filed this as PG-1073 and submitted a fix for review, so it should be fixed in the next version of ProGet.

Hello Srinivas, The Push to ProGet extension is specifically for Universal feeds. That error message appears to be coming from a NuGet feed. You can use a generic NuGet Visual Studio plugin to push to a NuGet feed on ProGet.

Oh god, worked ! Thanks a lot ! Would be super great if there could be a message or a log that says why the operation ended in a brutal closure of the program ;) Just a last remark: I may be wrong but it looks like you did not generate the "Full installer build" since a long time ago. If you look at the download page (http://inedo.com/proget/versions), event if full and small installer links do not lead to the same endpoint, the download size is the same wherever you click. It looks like the small version is deployed on all the endpoints. Thanks again for your help ;)

Thank you for the report - this issue (BM-2370) was fixed in a later version.

Hello I installed it using your integrated database installation.

Great! Thanks for the update Ben.

Tagging would indeed be the solution, now it's clear how we should have been working. Thanks for the fast feedback!

This means that the Otter Service or Inedo Agent doesn't have permissions to write to the host file. Typically this requires Administrative / LOCAL SYSTEM access.

I followed your suggestion of providing a Nuget API key, I got a different error. I found that if I unregistered the repository in PowerShell, and reregistered it, things work as expected when you provide an API key. It appears that Publish-Module does not work without an API key. Since ProGet will ignore it, (assuming the feed is not configured with one), you get the effect of just credential auth. (So might as well put an API key on the feed to avoid confusion.)

We don't support doing this sort of tweaking on the ProGet database; it might work, but we don't test it so I can't say.

Try: set $regExists = $PSEval("Test-Path $regPath");

Please refer to these documents from Microsoft: https://docs.microsoft.com/en-us/nuget/create-packages/creating-a-package https://docs.microsoft.com/en-us/nuget/create-packages/symbol-packages If the symbol files are inside of a package, then ProGet will index them.

The release/deploy API is secured by API keys, not by username/password. When you configure an API key, you can determine which access that API key has. Treat those API keys like passwords, and share them only with people you trust.

I haven't seen the error before, but it appears to be network related. I would suggest switching to IIS, so that you can debug those network problems a lot easier than the integrated web server.

Team member here. I'd like to let you know that we've moved to the public npm registry. See Retiring the Progress NPM Registry.

That is the requirement; the installer requires SQL_Latin1_General_CP1_CI_AS collation in the database, so if it's not that (and the installer can't change it), you won't be able to install ProGet.

Ben, That works. Thank you! TLDR; don't use "MultipartFormDataContent" when making this request.

Hello Sam, This should be fixed in version 4.6.4 of progetx-amazon, which is currently being tested.