4.0 is available for download now; we've tested it about as far as we can, the main reason it's still considered "beta" is to see how the Docker/installation process works in the wild. So, please give it a try. Depending on the requirements of non-AD LDAP, if it's easy to do, we can implement it quite soon.

VPN will occur at a much lower level than ProGet operations (which is HTTP/IIS), so I suggest you use a tools like Wireshark to dig a little further and see where the problem might be.

All of our installers are signed, our build process is isolated, and we do frequent network scans -- so it's definitely not a virus. If you want to verify it yourself, you're welcome to use a tool like .NET Reflector; it's just managed code and is not obfuscated in any way. It's just a self-contained SQL change script distribution package generated by our BuildMaster product. Still, every once in a while we get some part of the installer flagged by an AntiVirus scanner. Usually it's bmdbupdate.exe, since that does some "questionable-looking" things to an antivirus engine, such as embedding its dependency assemblies as resources. Please let them know about the false positive; the more people who do, the greater the chance they won't flag these in the future. Thanks for letting us know!

The story continuous :) Because I set TeamCity to create source packages as well (it's a checkbox called: Include sources and symbols) it was overwriting the packages in ProGet (I have all the PDB and sources in my nuspec files as well). This was causing the issue with the config file being gone, because TeamCity strips those files out for the symbols packages. So... I was doing things twice... Must be user error ;)

As of 3.5, these are the features not available in the free edition: Active Directory / LDAP Integration Filter Packages by Name & License Load Balancing & High Availability Granular Privileges & Security (scoping by individual feeds) MyGet Feed Sync

Hi Just wondering if this issue was resolved ? Pod

Hi Dean, Sorry I continued trying and found out the problem was caused because I had to include the -k flag (for HTTPS) and to include the username and password in the URL. Problem solved. Thanks. Kevin

You can just back-up the database, restore it on the new server, and edit the connection strings in the appSettings config files for the web and service.

Thank you for the cache tip. I've included -NoCache modifier to a command, and ProGet asked me about credentials.

Hi Dean Restarting the ProGet service solved the problem. Thanks!

It seems to be more stable now, or I can at least see the NuGet page on ProGet. Thanks.

Unfortunately not, but this would be a great place to post it if you are able to get it working! :) But before you do that, check under Advanced Settings to see if modifying the Base Odata URL field will solve the problem you're looking for.

I don't think you're doing anything wrong, but based on this, and your previous error... it sounds like you've got some server/network oddities. That could be any one of a THOUSAND things, but it's definitely not ProGet nor the NuGet clients. So, I'd suggest to put some wireshark or fiddler monitoring in between to see exactly what's happening, where they are coming from, and what the actual responses are.

This should be fixed in v4.5.7 (select NuGet or Chocolatey feed as the first option, and you can change the dropdown afterward). Note, we are considering deprecating the Deploy functionality in the next major version, so if you're looking to get started with deployment you should use BuildMaster instead.

So upon doing a fiddler trace and seeing nothing coming through when I used nuget.exe against our internal repo, I tried it against nuget.org and lo and behold that failed too. It turns out for prior things I had HTTP_PROXY and HTTPS_PROXY environment variables set and nuget.exe didn't like it. This carried over to Visual Studio as well. After removing those variables everything started working again. So, sorry this wasn't ProGet at all (thankfully).

Thanks for letting us know. At some point, we switched to doing connector searches in parallel, so the ordering was no longer consistent for identical packages. It seems to be an easy fix though, so it should be working again in 3.5.6, due out this week.

Thanks Alana. I upgraded to Proget v3.5.6 and updated the timeout period for the nuget feed source to 30s. Now I am no longer getting that issue but I am getting a different one. I logged it as a separate question: http://inedo.com/support/questions/2969

That worked! Definitely a big work around. We additionally had to set the AppPool for the new site to Classic and disable Forms Auth in the bindings.

Hi Dean, I ruled out the proxy since I know I'm getting to the server; I can see it in my IIS logs. What I did notice, is that when I tried to load the package from FeedB into FeedA again, the user the ProGet web app was using to authenticate was DOMAIN\MACHINENAME$ (e.g., NETWORK SERVICE). This account didn't have any rights to access ProGet, so the attempt was failing. My ProGet instance is hosted in IIS and the app pool was running using the application pool ID, so I first tried allowing DOMAIN\MACHINENAME$ access to the feed, but ProGet ignored that principal (I'm guessing you don't allow computer accounts to be added from AD). Next, since I have multiple service accounts lying around, I made the following configuration changes: Granted access to the service account to view FeedB in ProGet's Privileges & Roles Granted the service account access to the ProGet database, and put the user in the ProGetUser_Role role Changed the app pool of the site that the ProGet web app runs under to use the service account credentials Added my service account to the IIS_IUSRS group When I tried loading the package again, it worked correctly. So, the root cause here was that when ProGet is hosted in IIS using a built-in account that translates to DOMAIN\MACHINENAME$, you have to do some additional configuration to grant ProGet access to itself. Although this solved the problem, it would be handy to allow the specification of built-in accounts like BUILTIN\NETWORK SERVICE, or use the computer principal from AD such as DOMAIN\MACHINENAME$ when assigning privileges. Thanks!

You can disable the View privileges from Anonymous user, otherwise you'll have to upgrade to the Enterprise edition (a free trial is available) for more specific, feed-level privileges,