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.)

Unfortunately Microsoft does not provide this information available in the feed; it's only available for viewing on NuGet.org through a special partnership with third-party software vendor SonaType. This information is proprietary, and only available when purchasing software from SonaType.

Thanks, Tod. That works. I appreciate it!

In our testing, we couldn't get the maven feed to crash, but I was able to get an "invalid response" error in Google Chrome when requesting a snapshot from a connector, and I did notice that requesting an old version of a snapshot 404s because ProGet finds the correct version number and then overrides it with the latest version number. We're still investigating...

ProGet will not give this error code, so it's coming from another tool/service in between NuGet.exe and ProGet software. Please disable WebDAV, and any other things sitting in front of the ProGet server that would issue a 405 before relaying the request to ProGet.

Unfortunately there's not enough information.. or a question here.. for us to be able to provide a meaningful answer. If this just happens as a one off, please ignore it. if it's preventing you from doing something, please describe in deatail what you're trying to do. I already see some strange things, such as "port 44300" that make the set-up seem not very obvious, so please describe that too.

It's certainly planned on our end, but because it would require a major change to the way we do package indexing, which is a significant risk and thus could impact a lot of our enterprise customers.

Generally, you "subscribe" to a feed to get notifications; however, there will be a "webhook" feature coming soon that will allow you to send webhook notifications to other tools. We will be posting more information about it soon... stay tuned.

Sorry on the delayed response, but a re-written directory provider is now available in ProGet 4.8; this should support multiple domain searching, and is in the open source InedoCore extension, so it should be a lot easier to see precisely what's going on how to debug it.

As far as we can tell, ProGet has never returned a 409 response from that endpoint. A quick Google search reveals this NuGet bug: https://github.com/NuGet/Home/issues/2910 You can fix this by upgrading to NuGet.exe 3.4.5, NuGet.exe 3.5.0-beta2, or a later version.

It sounds like your load balancer is somehow trying to interact with the Docker protocol in some manner... there's nothing on the ProGet side that should cause that message in the client. It's hard to say, however, given that the load-balancer is forwarding requests to the ProGet software..

You are using it correctly; there is a bug in that particular endpoint that ignores the variables for non-legacy plans, see: Issue BM-3077