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.

If you've removed the "Anonymous" pseudo-user from the privileges for the current user directory, then you will see "You are browsing as the anonymous user, therefore certain functionality may be missing. Click the User Icon in the top right to log in.". note that, if you've enabled Windows Integrated Authentication, you will always be logged in as yourself, so you will not be able to go "anonymous".

The NuGetExePath variable is used by the NuGet operations (like Install-Package). So you would need to use that ahead of MsBuild, and then not do the NUGet restore in your msbuild. Your MsBuild script most likely hard-codes a path to NuGet.

ProGet supports overwriting existing packages, provided the user has such a permission.

It's not supported under any hosting (IWS, IIS); our applications must be a "root" application.

If you want to extend the life of that directory so you can view it in process explorer you can do something like this in the deployment plan: with async { Git-GetSource( # ... ); } with async { Sleep 1000; } await; That will keep the directory around for long enough to examine the file locks, and the deployment can be cancelled when finished.

Unfortunately there's nothing for us to go on here; with the limited information we have here, everything appears to be fine (the 401 is to be expected when you have an authenticated feed). Because you're using the unsupported VS2013 NuGet Plugin (which we cannot test with), and you upgraded from an a two-year old version of ProGet with a ton of changes between, we have no idea what is going on. We would need to know precisely which requests worked before (request/response), and precisely what it's doing now. Otherwise, you should just consider rolling back to 3.8.6 until you can upgrade to a supported version of Visual Studio.

3 nodes are only required if the load is such that 2 nodes are needed to handle expected load That's pretty much it! Keep in mind, it's tough for us to generalize things because there are so many different usecases and usages levels. But generally speaking, LB of ProGet is about managing peak usage -- like, when a few developers run their npm builds (requesting thousands of packages) using their 32GB/8-core desktops, that can quickly overpower a server. One server is often not enough for situations like that. Two is probably good enough. Three is pretty good. This is why we say dropping from "probably good enough" to "not enough" is not HA. Also, it's almost always easier and more cost effective for organizations to add another server in the mix than it is to spend the time determining how much they might actually need and risks that not being enough.

I think I determined that the nodes need to reboot after enabling high availability. That seems to resolve the issue. It may also be possible that it just takes time for the servers to report in, and that the console will show an error state until things settle out. (I didn't test that.)