This is correct, bower packages are not packages but simply URLs that point to a git repo. The git repo is the "source" of the package so without continually syncing the entire git repo it wouldn't be very useful. We may in the future add this (so no outside repos are requested similar to npm's and maven's indexing), but it's a ways off.

You can install a separate website in IIS that points to the same home directory, which supports forms authentication, then use that separate URL for npm & bower. With a separate IIS site, upgrading won't touch it so it will upgrade as per normal with the installer.

This is a bug in the Release_PurgeReleaseData stored procedure that was fixed in a later version. You can patch it by editing it and removing these lines: /* 2c) Configuration */ DELETE [ChangeControls] WHERE [Application_Id] = @Application_Id AND [Release_Number] = @Release_Number NOTE: make sure it's the 2c) line and the 2 following you delete... the 2d) one is correct. (The delete from the ChangeControls table is in there twice for some reason, which is the cause of this bug.)

Hi Just wondering if this issue was resolved ? Pod

Hi Riko Was this issue resolved for you I am facing similar issues with ldap in my company.

You can visit this directly (it'll look a bit strange since it's designed to be a modal page): http://{proget-server}/administration/security/users/change-password Apparently you're correct that the link to that is missing, it's supposed to be in the dropdown beneath the user icon - we'll add it back in the next maintenance version.

This means that packages with the same ID/version are being added to the feed, the only way to prevent this is either grant the privilege as described or don’t push the same unique package more than once.

Thanks for the report, we will investigate this further. We already know of an issue where there is disparity in the UI if the service is in the process of stopping/starting.

There have been a few modifications since the version you're running to the symbol/source server that will likely fix the behavior you're experiencing. There is one issue in particular that involved reverse sorting of the symbol file's age value that I believe is related. When you upgrade to the latest, it should resolve the issues.

Ok, it worked. If after created a connector the app asked to index and redirect to the scheduled task, it will be nice.

I would use .NET 4.5 with NuGet.exe to be safe.

Nevermind, apparently, the installation was messed up because of the failed previous upgrades (due to the antivirus). The program was not registered anymore so the installer didn't detect it for upgrade. I simply installed over the previous installation and it worked! Now running on 4.0.9! Thanks a lot for the info and help!

I assume, you are looking to deploy a package for deployment later? If this is the case, take a look at this guide, which goes over how to package and deploy an application for deployment using Otter. Otherwise, you can just use standard NuGet.exe client tools to package and publish your packages to the ProGet feed

The privileges are cached; if you "invalidate cache" on the privileges page or restart the web application, that should fix it.

ProGet supports the latest versions of all the major browsers. However, please note that only IE v11 is supported by Microsoft. We do test in IE9, and offer limited support. IE8 and earlier will probably exhibit some issues, but will mostly work most of the time; we do not test with those anymore.

I was able to get this working. I had to change the license key to something else and save it, then change it back to the proper key and save it again. Once I did that, it asked me to manually validate.

Hi TJ, That upgrade path is fine, and quite common; as long as the shared storage is the same (I assume it's already a UNC path), then when you start everything up again (webserver, indexing service), it should be the same. There isn't so much risk going from 3.5 -> 4.0, but please do read the ProGet upgrade notes just to see what's coming. Just make sure to do a quick test on the current (2005/single server) set up as 4.0 before moving that to new servers. You can always rollback if there is a realy big issue (though, we haven't seen any yet!) Best, Alana

In short, don't use the wizard, we have decided to remove them in v5 anyway because of problems like this. Instead, simply create a Standard Application, and then visit the Workflows tab, and add a Build Step that imports from TFS. That's actually all the wizard is supposed to do anyway.

This is a pretty common deployment for BuildMaster; there are a lot of options, but the easiest thing we've seen is to do the "exploded WAR" strategy -- basically, unzip the war file into the catalina_home directory, and kick the tomcat service. This saves a lot on initial load time as well.

Not in particular, but you might find limitations on intermediate network equipment when you try to download very large files (just like you might from over any web/HTTP point).