Hi Mike, Apologies for the delay, but the problem is with the NuGet extension for BuildMaster. There is a new version (4.7.2) available that can be updated from within BuildMaster on the Admin > Extensions page.

I was only able to reproduce the difference in packages returned when the casing of the id was different than the actual ID of the package, i.e. for jQuery: http://proget/nuget/Default/Packages?$filter=Id eq 'jquery' and http://proget/nuget/Default/FindPackagesById()?id='jquery' The Packages endpoint does not return remote packages because searching in this manner is case-sensitive, while it is not for FindPackagesById. The solution seems to be always use FindPackagesById, or use /Packages?$filter=tolower(Id) eq 'jquery'.

ProGet's remote connectors only apply to NuGet endpoints, and will not connect to UNC paths like Visual Studio does. You can however simply create another feed, import all the packages in the UNC path into it, then set the feed storage path to that UNC path.

We removed that simply because it was confusing having both actions like that, your best bet is to use the Execute Command Line action, or a PowerShell script in the script library that does what you need.

It's not that "tags appear to become meaningless once a newer version of a package is present", it's just that tags are part of an individual package's metadata (see the NuSpec Reference) just like name, description, authors, etc. The VS Client, nuget.org, and every other package manager UI we've worked with will only do metadata search on the most current version of a package by default; otherwise, outdated and irrelevant packages would come up in results. As you can see, it's possible to use an API to search for these things... but tags are simply not intended to solve the problem I think you're trying to solve.

I see, that's perhaps the most common usecase for ProGet, so it should just work. I suggest to attach Fiddler, or Wireshark, then compare the results between one computer and the next. Then you can see exactly what the results are. Something could be filtering it in between, redirecting to the wrong server with a hosts file, etc.

Believe me, we really wish it was feasible to provide "Integrated Windows Authentication" (i.e. 401/NTLM challenges) for some feeds, and "Anonymous" for others. The problem is that this is implemented at the HTTP.SYS stack level (a kernel-level service), which far below IIS. NTLM/Kerberos authentication is not something we can feasibly implement ourselves... even if we did, the TGS Exchange cannot really run in a protected environment (like an app pool user). This has been a known issue by Microsoft for at least 10 years, and they are planning to introduce some new libraries/options with Server 2016. There are rumors they will drop it altogether in favor of federated authentication (i.e. Azure style). But, it's not huge on their priority list I think.

I assume you can see the package when you browse the feed in ProGet? If so, then Visual Studio is filtering out your package because it's targeting a different framework than your package is configured for. For example, you may have a net45 package and are trying to make a net35 project.

There are some disk usage reports on the Manage Feed Page, but they do not break it down overtime and by month. We simply do not store disk usage statistics -- only the current space utilization. There are likely some third-party utilities that will tell you disk usage peaks, usage over time, etc; you can point those to the disk path that ProGet uses for internal storage.

At this time, the NuGet team has no plans to make the v3 API publicly consumable, and will support the v2 API indefinitely as the public API; as such, we have no intention to reverse engineer and attempt to implement a private API. Note this it is entirely a "behind the scenes" transport mechanism (JSON vs XML) and makes no difference at all from a usage perspective.

If you just either use the NuGetFeed constructor that does not take credentials, or set the credentials parameter to null, then it will attempt to use Windows Authentication for the current user.

Thanks for the additional feedback! Do keep in mind that this was simply one possible work-around for a bug in the NuGet client that they fixed more than a year ago. Also do note that, when you grant a user Feeds_AddPackage to a user, they only have access to do that task. Which in this case, is very minimal. They do not become ProGet administrators, etc. In Windows, you can actually configure all users to be "Domain Administrators" (or have "root" open in Linux). We offer the same flexibility in ProGet, and you can configure ProGet to be as secure or open as needed. This is actually a very common feature in software/vendor products and, like most software vendors, we empower users to decide how secure or open to make their instance based on their specific needs and requirements. Unfortunately we can't offer specific advice to everyone on our forums on how to decide which policies suit them, but we do have some training and certification courses which offer lots of security topics (including awareness of the "security hole" you described, as well as lots of other potential attack vectors). You seem to be quite passionate about organizational security (i.e. InfoSec), which is awesome! There's a ton of great sources out there, but I would highly recommend you follow Krebs on Security and Schneier on Security. Those are some great starting points which you can use to starting learning how to develop best practices in your own organization :)

Ah; well, that would explain it :) Your PDB files contain no links to source files, which VS and ProGet are unable o index/locate them. This means you'll need to adjust your complication process to incluse them. A quick search surfaced this article, which may be of assistance: Correctly Creating Native C++ Release Build PDBs. Please do post an update if you find the issue/setting in your project/build file that prevented this from happening.

If you don't specify the symbols option, but include everything in a src directory, then it will work. Keep in mind a NuGet package is just a zip file, so if you're having trouble using nuget.exe with nuspec files and native packages, then you might find it easier to workaround by creating the zip file. Just remember to follow the conventions.

Well, the NuGet API version is totally unrelated; and regarding the v3 API, it's still not stable/public yet, but they are planning a stable/public API at some point in the future (no ETA). Regarding SemVer v2 support for NuGet packages/feeds, tut The NuGet team reports they may support it in v3.5 or v3.6; if/when that happens, we'll add support for it in ProGet's NuGet feed.

Here are the commands/switches that would be run ... https://github.com/Inedo/bmx-nuget/blob/master/CreatePackage.cs#L83]

Upgraded to 3.7.4 and the problem is fixed. Thanks.

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

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.

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.