ProGet can host a Bower repo, but a Bower repo is really nothing more than a name/url mapping that points to a Git repo. The packages themselves remain stored in a Git repo. To proxy everything, you'd need to set up a local Git repository and change the ProGet package URL for that package to refer to the local copy.

Good to know as well on this side. Now I know how not to have configuration errors drive me nuts. Now I just have to figure out how I'm going to do this ... Looks like my network will need two ProGet servers ...

For the database, that should work fine. If you have packages stored on the local filesystem of the server, they'll have to be migrated over and kept in the same structure, otherwise the feed storage paths would have to be updated. If the database PackagesRootPath is configured to a UNC path or mapped drive, then as long as that path is accessible from the new server you should be good to go.

On version 5.1.17 this setting is called Web.BaseUrl

Hi Tod, sorry my falled your workaround is working thx

This issue has been resolved in ProGet 3.8.1.

Please see ProGet Features By Edition for more information.

Thanks. Removing \SQLEXPRESS fixed it. -Michael

Upgraded to 3.7.4 and the problem is fixed. Thanks.

Yes, most definitely. See KB#1072 - ProGet vs. NuGet.Server

It's not possible to add a new feed type via the SDK, but it's for sure on our roadmap.

It would be good to clarify the "Symbol and Source Server" document you linked to explain that you don't actually just want to push the symbols package; you want to push a package that contains everything. The way the document currently reads, which is why I got hung up, is that it talks about the two different packages - non-symbols vs. symbols - and then later says to only push the symbol package which is wrong. Symbol packages built with -Symbols don't include content files. I recognize the race condition issue, but the description that symbols packages only differ by adding symbols and source is incorrect. The typical symbol package only has symbols and source.

We'll fix this in ProGet 3.7.4. For now, you can mark the feed as inactive to disable it. If you need to delete it, I can send you a patch to fix your installation.

Although the VS2015 release is around the corner, we don't believe the v3 API will be ready/stable for public consumption yet. There are no currently no API docs, and the codebase is still moving too much to try to guess what will it will be. We reverse engineered what we could with NuGet3RC2, and it seems to use a blend of v2/v3 API calls. Once the API is ready, we will likely use it to implement the "nuget.org cache" feature that's on our roadmap. That said, the NuGet team will need to (and plans to) support the v2 API in both their client and server components for many years to come, so we're in no rush. The v3 API will primarily offer performance improvements for reaching NuGet.org, but ProGet users aren't really impacted by performance problems anyway, due to local server caching.

ASP.NET 500 errors should appear in the Windows Event Log, check there for full details, though this sounds like an error with the nuget.exe client rather than ProGet.

You can set up a retention policy that will handle this feed cleanup.

Thanks Dean, I modded the regex inline to get around the validation issue. Thanks for getting back to us on this.

Maven connectors need to be indexed before they can be used from ProGet. If you go to the Admin->Scheduled Tasks page, you should see an entry for a MavenConnectorIndexing job, and you should be able to see a log of the last several attempts. Did it appear to complete successfully? Also, you may want to try actually performing a search for the Maven artifacts. When browsing, we only display local artifacts, but connectors are displayed when you search as well.

This is now in Admin > All Settings, under ReservationUrls

Thanks Dean - that was super helpful :) I resolved this issue by only promoting the symbols package if one existed. Many thanks!